Skip to content

Conversation

@mjkkirschner
Copy link
Member

@mjkkirschner mjkkirschner commented May 9, 2024

Purpose

relies on:
DynamoDS/librarie.js#228

Dynamo now informs librarieJS of the workspace context, when loadedTypes that have hiddenInWorkspaceContext == true are rendered and the context is home - they are simply not rendered on the JS side.

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
  • This PR contains no files larger than 50 MB

Release Notes

fix a legacy issue where input and output symbol nodes were shown in the HomeWorkspace context even though they are only useful in CustomNodeWorkspaces.

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

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

@github-actions github-actions bot changed the title DYN-6956 symbol nodes should not show in HomeWorkspace context. 6893: DYN-6956 symbol nodes should not show in HomeWorkspace context. May 9, 2024
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-6893

@github-actions
Copy link

github-actions bot commented May 9, 2024

UI Smoke Tests

Test: success. 2 passed, 0 failed.
TestComplete Test Result
Workflow Run: UI Smoke Tests
Check: UI Smoke Tests - net8.0

Copy link
Contributor

@RobertGlobant20 RobertGlobant20 left a comment

Choose a reason for hiding this comment

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

LGTM

refreshLibraryView(libController);

//initial state
libController.setHostContext("home")
Copy link
Contributor

Choose a reason for hiding this comment

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

@Enzo707 think this line needs to be moved to librarie.js->library.html file once you consume the npm package inside Dynamo.

{
var type = workspace switch
{
HomeWorkspaceModel _ => "home",
Copy link
Contributor

Choose a reason for hiding this comment

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

I see you defined the next line in librarie.js
export type HostingContextType = "home"|"custom"|"none"
What happens if is set to "none"?

Copy link
Member Author

Choose a reason for hiding this comment

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

custom and none do nothing special at the moment - library is rendered as before my prs.

/// <param name="type"></param>
internal void UpdateContext(string type)
{
ExecuteScriptFunctionAsync(browser,"libController.setHostContext", type);
Copy link
Contributor

Choose a reason for hiding this comment

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

Usually we were defining the function in the library.html (like an interface of Dynamo and librarie.js), for example:
function SetContext(type){
libController.setHostContext(type)
}
But I guess this way is better if now everything will be inside the librarie.js component.

Copy link
Member Author

@mjkkirschner mjkkirschner May 10, 2024

Choose a reason for hiding this comment

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

I actually had trouble with that pattern where I found libController was not set correctly, I guess I could figure out how to pass it as a arg to make sure.

Copy link
Contributor

@pinzart90 pinzart90 May 10, 2024

Choose a reason for hiding this comment

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

I don't like that we're using ExecuteScriptFunctionAsync for so many interops between c# and javascript. ExecuteScriptFunctionAsync forces you to write the javascript code on the c# side (prone to errors)
There are other ways to interop (post simple messages or hostObjects) We should review the interop approach in a separate task

@mjkkirschner
Copy link
Member Author

the test failure exists on master already, merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants