Static Node Reference Resolution and Initialization Ordering in Node-RED

Core Development Feature Requests
21

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

22

@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?

23

@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.