DynamoCore Modularization #3449
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Big Idea
The architecture of Dynamo was previously a tangled mess of dependencies. This PR refactors
DynamoCoreinto a modular, layered architecture, where the boundaries of the various components of the application are clearly defined.Or, in a nutshell, we are no longer accessing
DynamoModelfrom remote parts of the application. This means that:What's been changed?
NodeGraphNodeFactoryhas been overhauled; previously we were doing weird string parsing to determine how to create new nodes. Nothing was consistent, the API was cumbersome to use, and there was a ton of duplicate code.NodeFactory. Different types of nodes registerINodeLoaderinstances with theNodeFactory. For special kinds of nodes (Custom Nodes and Zero Touch Nodes), there are specialINodeLoadersthat handle the necessary extra logic for creating instances. This means thatNodeFactoryno longer needs to know about theFunctionandDSFunctionclasses.NodeModelare now instantiated using a pre-compiledExpression, as opposed to relying on anActivator. This means that instantiating large numbers of new nodes should be significantly faster (copy/paste, undo/redo, loading files).CustomNodeManagerhas become the primary interface for dealing with Custom Nodes.CustomNodeWorkspaces, instead of justCustomNodeDefinitions.CustomNodeWorkspacenow emits events when theCustomNodeDefinitionandCustomNodeInfohas changed.CustomNodeWorkspacedefines what theCustomNodeDefinitionandCustomNodeInfoare.CustomNodeManager, which then forwards them toDynamoModel, which then propagates them to theEngineController, Search Library, and Custom Node Instances.Function) Instances are now created fromCustomNodeManager, in order to ensure that they are kept in sync with theirCustomNodeDefinition.HomeWorkspaceModelsare the only kind of Workspaces that can be evaluated,EngineControllerhas been moved toHomeWorkspaceModelConsequentially, all logic originally onUnfortunately,DynamoModelassociated withEngineControllerhas now been moved toHomeWorkspaceModelCodeBlockNodeModelshave a dependency onEngineControllerfor Auto-complete. Further work can be done to decouple Auto-complete fromEngineController, which would allow for total removal ofEngineControllerfromDynamoModel.HomeWorkspaceModelsactive at once.Reviewers: