Instead of having to set msg properties
and then having to convert them to flow properties
Could we have option to set all the contexts (msg/flow/global) in the inject node please?
Do you mean have the Inject node write directly to context, rather than send a message?
Yes please - that's what I was after
+1 for this, although I think the inject node should always send a msg object even if its an empty one (if only flow/global is set) just for consistency.
Yes what I mean was if only setting flow/global contexts it should continue to do that rather than not sending a message
2 Likes
I would also like to see that option in the inject node.
That would clean up some of my flows, but I'm quite used now to have a change node right after the inject node.
In this particular case I would personally use the contrib-credentials node instead of the change node, to prevent storing a password in plain text in the flow.json.
2 Likes
I am in two minds about this. I can see the advantage where context needs to be initialised, but I don't like nodes with side effects not visible from the flows image. If one sees an Inject node with nothing connected one would likely assume that it is doing nothing, which would not be the case.
Of course I am biased in that I think global and flow context are often overused and should be discouraged except for the few occasions where there is a clear advantage to using context.
3 Likes
If ever then it needs to be somehow configurable to override/not override possibly existing thing in context.
This ^
I too am not keen on this request TBH.
It is somewhat anti pattern and veers off the (usual goal of) do one thing and do it well.
To play devil advocate for a moment, something I often do is setup an inject node, get everything working nicely, then have to recreate it as a change node when I want to "wire it up in an automation". For me, a far better FR would be the ability to convert an inject node to change node or the ability to copy rows from the inject and paste them into a change node.
6 Likes
Me neither, what happens if the inject node is repetitive and continual updates the context? Try debugging that ...
If you don't have a debug hanging from the inject and without explicitly opening the inject node, you won't know what was updating your context.
Do one thing and one thing only, with every new thing, there is an exponential increase in errors ==> (all present features) x (in combination with new feature).
2 Likes
or simply put an input port to the inject node and wire it from behind ?
like a cronplus node has an inject button as well as can be triggered from behind
best of both worlds?
unless there is a strong reason for NOT PUTTING an input port on an inject node
While I obviously agree (I wrote cron-plus), it doesnt look pretty.
Something I've been swishing around my brain for some time is a redesign of the nodes and button placement that would permit both an input and a button without making Nick an Dave gag 
1 Like
Or put an button on a change node ... perhaps this is a case of merging the change and inject nodes into a injange node!
2 Likes
Good luck with that ! (but will keep an open mind)
2 Likes
Normally I've always placed a function node after an inject to set context vars, but I could see this being useful for me as well if it saves time/editor-space.
@HaroldPetersInskipp I'm just wondering, why did you use a function node and not a change node to set the context variable?
Isn't that just using flow and global objects in the function node?
With the change node you can set multiple items so you could set multiple flow and or global variables, You can do the same in a function node but you have to create the code and the function node has a little overhead.
So if all you are doing is setting some flow and/or global variables I would choose the change node over the function node.
