Static Node Reference Resolution and Initialization Ordering in Node-RED

I found a reason why ordering the creation of nodes using topological sorting isnt good. Like in js objects, cyclic references are allowed A -> B -> C -> A. Constructing static references using topological order would not let us create cycles. Storing just the id of the reference allows it.

I will see if i can create a proxy to remove boilerplate code when accessing references

@AllanOricil to help frame the discussion, can you share details of the scenario where you want two flow nodes to have a dependency on each other that exists beyond the wiring between them?

@knolleary I can't really think of an example where cyclic references would be useful. My previous comment was based on the fact that programming languages like Java and JavaScript allow runtime cyclic references.

Maybe if we agree that cyclic references are not allowed, then this enhacement could be implemented. It is up to you.

I googled a little bit more and found that cyclic references are allowed in programming languages but it is not a good practice since it can lead to memory leaks, or take longer for the garbage collector to clean memory. Based on this I think I would also block cyclic references between nodes used as configs of other nodes

An example of a node referencing another node outside its own flow can be found in certain visual use cases. For instance, a dependency node could act as a counter on the canvas. While the main flow runs, one of its nodes—depending on the status reporter node—might send a message to that dependency to increment a variable, which is then displayed via the status feature. Another example is using a node as a data or state store, allowing its context values to be viewed in the context tab—unlike a config node.

UIBUILDER does have nodes that reference other nodes. But it does not have any cyclic issues because those links are only ever used at runtime after flows have started, there is no cross-reference before than. Also, the reference is created in the Editor and deployed from there. UIBUILDER builds its own reference tables of uibuilder nodes both deployed and those in-memory in the editor that have not yet been deployed. It firstly uses that to help prevent people from creating duplicate URL's. But there are also other nodes that link to a parent uibuilder node such as the uib-save node. I've never had any timing or cyclic issues. However, it may also hlep that UIBUILDER uses enforced single-instance class libraries and has a shared base config.