Hi @knolleary, @shrickus and @zenofmud ,
using for example the made up
output attribute of the msg object is a great idea for a per message data: 1-to-1 correspondence, same scope and lifetime.
[Disclaimer ] Despite realizing a little late that a flow was a tab in node-red and that one flow/tab can contain many "sub-processes", I still think there is substance to giving a subflow access to its containing flow context, specifically if we are dealing with per-flow logic.
My use-case in more detail: I have grouped many "sub-processes" into one flow because I have made a flow a collection of message processing actions around a same "concept". So for example in one of my flows I have three "sub-processes" starting with an http-in node that point to the same http endpoint, with a different verb (GET, POST, DELETE). In each of these "sub-processes" I have nodes that read configuration values from the flow context. I love subflows because they are great for contracting nodes together and in essence prototyping new nodes and their behaviors. Encapsulating the subflow context stops me from sharing configuration between my flow and my subflow, which would be brilliant for behavior composition.
The reason why I made this request in the first place is because the "sub-processes" in the same flow should share the same configuration as we are in a per-flow logic, however the only way to implement this behavior would be to turn to the global context or to create some pseudo private attribute at the msg level. Both alternatives could work but seem slightly inadequate to me.
@adesjardins, sorry, I did not mean to highjack your thread! I guess I actually misunderstood your question in the first place too