account for node configuration in graph editor

[rlidwka]

The objective of this commit is to correctly render graphs like these: https://github.com/bhouston/behave-graph/blob/3e6568caa9a46a6f6aee27b0192a478f30c9c541/graphs/core/flow/WaitAll.json

This is how that graph is displayed now (you can copy-paste it to verify that this PR is not useless):

When loading JSON, a node may have arbitrary configuration parameters, that previously got ignored (such as number of sequence outputs).

This commit tracks configuration for each rendered node, and accounts for it in all calculations (such as adding new edge).

In order to do this, instead of NodeSpecJSON (object) we now pass a NodeSpecGenerator (class) which generates node specs on demand based on passed configuration (and also memoizes, not sure if that's necessary). Note: instead of it, we can pass IRegistry around, and run createNode() whenever we need to access inputs. I don't know why I decided that memoization of node creation is a good idea.

New nodes will still be created from UI with no configuration, and no UI work to support any configuration editing has been done.

---

edit:

I've also added Unreal-like "Add socket" button in the second commit, that is intended to be a demonstration of how you can configure these nodes in UI:

This is not a comprehensive solution by any means, this is just a starting point for someone who wants to actually implement UI.

[SYBIOTE]

so in theory , if one makes a config editor UI, then the nodes will reactively update as the config changes ,
can this also be extended to reactively change a node when we pull in a specific input to it?

[SYBIOTE]

the PR breaks node addition, as the data value in the new node added is null

[SYBIOTE]

I propose adding code responsible for filling the configuration when adding a new node with the default values in the handle add node method

[rlidwka]

the PR breaks node addition, as the data value in the new node added is null

I fixed it in the last force-push, please check again:
https://github.com/bhouston/behave-graph/compare/8c6deaae5461393b7f5d1c6c60bea426f7ac1a7c..3d2383d23869871bfea0f78f2fc61aa55427d263

[SYBIOTE]

Ok i will

[rlidwka]

here's all existing custom configurations:

• customEvent/onTriggered: customEventId (string)
• customEvent/trigger: customEventId (string)
• flow/sequence: numOutputs (number)
• flow/switch/integer: numCases (number)
• flow/switch/string: numCases (number)
• flow/waitAll: numInputs (number)
• variable/get: variableId (number)
• variable/set: variableId (number)

so still need some UI for variableId and customEventId

[rlidwka]

I've renamed flow configuration (numInputs/numOutputs/numCases) to a single numSockets in order to avoid "hardcodedness" a little bit.

Now every node that has "numSockets" configuration of a "number" type gets a plus button.

There's still no custom UI for events and variables.

[SYBIOTE]

Hmm that's good, but then again, now we cannot distinguish between nodes which only need multiple input sockets, ones which need only multiple output sockets and ones which need both

[rlidwka]

Hmm that's good, but then again, now we cannot distinguish between nodes which only need multiple input sockets

We don't need to distinguish between those now. The UI is the same for both.

Yes, it's a bad practice to tune data structures to UI needs, so better ideas are certainly welcome, especially if they come with corresponding pull requests.