Refactoring the `RED.nodes.import()` function

[GogoVega]

• [x] Bugfix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)

Proposed changes

Refactoring the importNodes function.

Resolves also:

• Bad number of node.users for Config Node:

  • Deleting a Node inside a Subflow does not update the number of users.
  • Replacing a Config Node overwrites the user list to empty.

• A Node that has an invalid number of inputs/outputs (dynamic number) is not correctly handled.

• When copying a Subflow (tab), the name is not updated (addition of the copy count)

• When importing a Subflow:

  • If the definition is missing, the Node will be marked as unknown - which allows to double click and have dialog box and be able to export this Node.
  • When adding the definition, existing instances into the workspace are updated.
  • A Node missing into the Subflow import is now handled (to avoid create link)

• Ensure activeWorkspace can no longer be equal to 0.

Other functions modified:

• updateConfigNodeUsers - for either add or remove and either trigger the event
• RED.view.importNodes() - overwrite importMap to undefined

Checklist

• [x] I have read the contribution guidelines
• [ ] For non-bugfix PRs, I have discussed this change on the forum/slack team.
• [x] I have run npm run test to verify the unit tests pass
• [ ] I have added suitable unit tests to cover the new/changed functionality

[knolleary]

This function is so central to the editor, I am wary of anyone else doing a large refactoring of it. It contains 10 years of built up logic, and in many cases there are good reasons for the order things are done in.

We are also trying to get 4.0 shipped. I simply don't have bandwidth to give this work the attention it needs any time soon given there is no compelling reason to do it.

I will try to take a look at some point, but I can't say when.

[GogoVega]

No worries, focus on v4 and for my part I'll continue here - It's going to take me a while, then test it thoroughly.

Given all that this involves, I had not planned to bring it in for v4. So come back here as soon as you can but without pressure. Thanks 😉

[GogoVega]

Do we still have to handle the import of singleton config node? If so, the only currently unhandled case would be that multiple nodes use the same config node - this config node will need to be copied and re-associated with each node.

[knolleary]

To be absolutely direct - as I was in an earlier comment - I'm not sure how to move forward with this PR. It is massive and changes such an important part of the editor code base. The PR not only moves code around, but also changes the logic in different places due to the various fixes you've identified. So not only do I have to understand how you've moved the code around, I need to understand why you've changed any particular bits of logic - which could be a bug you've fixed or a bug you've introduced.

I simply don't know when I will have the time needed to focus on this.