Skip to content

Moving GetMatchingNodes API to search view model #11146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
QilongTang merged 4 commits into from
Sep 24, 2020
Merged

Moving GetMatchingNodes API to search view model #11146

QilongTang merged 4 commits into from
Sep 24, 2020

Conversation

@QilongTang
Copy link
Contributor

@QilongTang QilongTang commented Sep 24, 2020 •
edited
Loading

Please Note:

  1. Before submitting the PR, please review How to Contribute to Dynamo
  2. Dynamo Team will meet 1x a month to review PRs found on Github (Issues will be handled separately)
  3. PRs will be reviewed from oldest to newest
  4. If a reviewed PR requires changes by the owner, the owner of the PR has 30 days to respond. If the PR has seen no activity by the next session, it will be either closed by the team or depending on its utility will be taken over by someone on the team
  5. PRs should use either Dynamo's default PR template or one of these other template options in order to be considered for review.
  6. PRs that do not have one of the Dynamo PR templates completely filled out with all declarations satisfied will not be reviewed by the Dynamo team.
  7. PRs made to the DynamoRevit repo will need to be cherry-picked into all the DynamoRevit Release branches that Dynamo supports. Contributors will be responsible for cherry-picking their reviewed commits to the other branches after a LGTM label is added to the PR.

Purpose

Proposed changes to move GetMatchingNodes API to NodeAutoCompleteSearchViewModel

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated

Reviewers

@DynamoDS/dynamo

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

QilongTang
QilongTang commented Sep 24, 2020
View reviewed changes
test/DynamoCoreWpfTests/NodeViewTests.cs Outdated
var suggestions = inPorts[1].GetMatchingNodes();
var searchViewMode = (ViewModel.CurrentSpaceViewModel.NodeAutoCompleteSearchViewModel as NodeAutoCompleteSearchViewModel);
searchViewMode.PortViewModel = inPorts[1];
var suggestions = searchViewMode.GetMatchingNodes();
Copy link
Contributor Author

@QilongTang QilongTang Sep 24, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aparajit-pratap And team, curious about your thoughts here. IMHO, the reasons I would like to move this API are below

  1. The API is about PortView logic.
  2. The API is getting NodeSearchElement which is more tightly connected to search view model.
  3. We may even want to rename the API based on the reason above.
  4. Still unit testable this way.

Copy link
Contributor

@aparajit-pratap aparajit-pratap Sep 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay either way. I don't feel strongly about moving it if it's mainly for the reason that it returns NodeSearchElement. We could also make it return plain strings or something else and wrap them into NodeSearchElements inside of PopulateAutocomplateCandidates if that's the concern :)

Copy link
Contributor

@aparajit-pratap aparajit-pratap Sep 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the latter statement I made is not so straightforward; it's easier to just return NodeSearchElement from the API so I'm okay with this change.

Copy link
Contributor Author

@QilongTang QilongTang Sep 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the opposite I think the current implementation is quite clean, but in the future since we may introduce ML module dependencies, I would rather not put this API under PortViewModel :)

aparajit-pratap
aparajit-pratap reviewed Sep 24, 2020
View reviewed changes
@QilongTang QilongTang merged commit 127d6ad into NodeAutoComplete Sep 24, 2020
@QilongTang QilongTang deleted the MovingAPI branch September 24, 2020 21:40
QilongTang added a commit that referenced this pull request Sep 29, 2020
@QilongTang @aparajit-pratap
Introduce NodeAutoComplete Feature (#11120)
672f94f 
* Initial Commit of NodeAutoComplete MVP

* Clean Up

* Fix a bug that left over search term was kept for next trigger

* Changed to use alt + mouse left key down and change cursor to adapt to connection mode

* Fix the in canvas node auto complete glitching issue with a click suppress

* Comments

* preference setting test

* Add test

* New Node AutoComplete

* Comments

* Comments

* Use node suggestion API in node autocomplete UI (#11132)

* update code comment

* add APIs to return matching nodes for input ports

* revert temporary changes made for testing

* cleanup

* merge api with UI

* revert unwanted changes

* Add null-check (#11144)

* add null-check

* Clean Up

* Moving GetMatchingNodes API to search view model (#11146)

* Moving GetMatchingNodes API to search view model

* Clean Up

* Comments

* Create a dedicated test file to prepare for more unit tests

* Comments

* Comments

* Comments

* Comments

Co-authored-by: aparajit-pratap <aparajit.pratap@autodesk.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@aparajit-pratap aparajit-pratap aparajit-pratap approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@QilongTang @aparajit-pratap