Improve migration/stability when code changes are hot reloaded.
Areas to be improved:
Renaming nodes - Issue #9 goes into detail on this
Renaming fields - Essentially resolved via #17 since we don't track the field names any longer - but there needs to be some form of "previously known as" for the label
Removing fields - Currently the port does not automatically remove itself when an [Input] or [Output] attribute is removed.
Adding fields - Like removal, nodes don't automatically add a port in the editor for existing nodes on a Graph. They will if you manually add a new instance of a node after the change.
Changing field types - If a [Input] public float foo; is changed to [Input] public bool foo; the port remains a float. It needs to change, and also remove connections that are no longer compatible (with plenty of reporting to the developer that this just happened).
If we can't magically resolve changes to a node - it'd be nice to insert an "Error Node" placeholder into the graph to indicate what the old node was, what the errors are, and solutions on how to solve it. I can see situations where someone accidentally changes a field type - the "magic" migration code fixes it by deleting all the edges - and then that developer has a hell of a time trying to reconnect everything. And with sufficiently complex graphs, that would be a nightmare.
I think it'd be nice to start off with a graph scanning / validator on hot reload, and then swapping broken nodes for this error node and reporting back the errors for the developer to fix. Once that's in place, we can then identify what errors should be automatically resolved, if any.
Improve migration/stability when code changes are hot reloaded.
Areas to be improved:
[Input] public float foo;is changed to[Input] public bool foo;the port remains a float. It needs to change, and also remove connections that are no longer compatible (with plenty of reporting to the developer that this just happened).If we can't magically resolve changes to a node - it'd be nice to insert an "Error Node" placeholder into the graph to indicate what the old node was, what the errors are, and solutions on how to solve it. I can see situations where someone accidentally changes a field type - the "magic" migration code fixes it by deleting all the edges - and then that developer has a hell of a time trying to reconnect everything. And with sufficiently complex graphs, that would be a nightmare.
I think it'd be nice to start off with a graph scanning / validator on hot reload, and then swapping broken nodes for this error node and reporting back the errors for the developer to fix. Once that's in place, we can then identify what errors should be automatically resolved, if any.