It would be really comfortable to edit the inject value without deploying all, it will speed up the debug process. Thank you
ok, but having a way to change it without deplying at all would speed up more..
It would speed up development but doing so goes against basic Node-RED developers philosophy that the editor is not a dashboard
I normally work around this restriction by connecting a few inject nodes together with different values such as 0, 1,10,50 100 - that sort of thing
I've even done this sort of thing
On a couple of occasions, I've made a simple dashboard to have complete control
But all the workarounds have downsides
1 Like
I might be wrong, but I think there is more to it. Until you deploy, the runtime does not know about anything you have done in the editor. Changing that would mean coupling the two closer together when work is in progress to get them fully de-coupled.
3 Likes
Yes sure, it's not an easy feature to implement this. But maybe it will be possible in the future to make Node Red "listen" for browser changes and implement them on the fly. Sounds not impossible
I didn't mean to say it is impossible or even difficult, just that it goes against the direction that NR is headed. The benefits of the planned decoupling of the editor and runtime almost certainly outweigh any gain from this feature.
There is already an active comunication between Node red and web board during thr deploy, such errors reported by devices, debug, and also the inject buttons pressure. So there is actually a packet from web board to Node red flow "iject button is pressed, do your job". There will be only necessary to add value to this packet too.. I don't think this may "twist" the whole direction of NR.. which I understand what it is of course..
True, but these communications are configured when you deploy a flow and can't be changed without another deploy. For example, you can turn debug nodes on and off because the browser can control what it displays, but changing from msg.property to complete message object requires a redeploy. As you imply, hitting the button on the inject node tells the runtime that the button has been pushed, but the message this creates in the flow has been set in advance and can't be changed without a re-deploy. I think the change you want would require a pretty massive re-working of the inject node. As @cymplecy says, a simple dashboard can inject almost anything you want into a flow for testing purposes.
I'm wondering whether the feature request should be changed to allow a dashboard to be displayed as an iframe in the editor.
This feature is one that is already on the backlog and has been for some time - https://trello.com/c/SjfBYhVl/140-quick-inject-tools
When you click the button on the Inject node it sends an HTTP request to the runtime to trigger the node. Currently that is an empty request that just tells the node to inject what it is configured with.
It is not a big leap to say that request could contain the information about the message to inject. So the underlying implementation is not the hard part.
The hard part is the user experience in the editor.
The most straight-forward approach would be for the button on the Inject node to always send whatever the node is configure with - regardless of whether it has been deployed or not (assuming the node has been deployed at some point - if the node has never been deployed then the runtime won't know anything about it). That would be the smallest change needed - but equally could cause unexpected results. For example, if the deployed node is set to inject every 5 seconds, clicking the button would do a one-time-inject of the edited node config, but the 5-second inject would continue with the deployed configuration.
Doing it as a separate piece of UI away from the node then becomes hard to manage when you have dozens of Inject nodes.
So happy to let this thread develop ideas - just know the focus should be the user experience.
2 Likes
it would also have to block if any wiring changes had occurred in the editor.
I'd never dreamt that something like this would be allowed in NodeRED
For development work (which is what inject is used for - apart from people misusing editor as a dashboard ) I'd GLADLY accept the unexpected.
During my development, I'm ALWAYS experiencing the unexpected so one more is no problem at all 
(Not due to to NodeRED - due to my incompetence using it!)
Dear friends, thank you for supporting this thread!
I would suggest, let's make the things easiest!
We suppose that if for debuginng is necessay to change the Injected value, it will be the same nature of value that we used on deploy.. so, let's filter on the browser side the nature/type of values, it should be the same nature as deployed value, if it is not the browser will not allow it, and not send to Node Red the new value. For example:
I deployed an Inject node with string "Hello",, now to test my function script I would send instead the string "Hello /n 123", the browser knows that the flow was deployed with that Inject node containing a string, the browser check that I inputed a new string too, allows and sends the string to Node Red. Now if we push the button we will inject the new string instead the old one.
If in Inject I configured number but I try to send chars, the browser will return an error and don't send anything to Node Red, this will preserve Node Red. We may use the same script used now to check the values typed on Inject node before deploy.. if there is a mistake Node Red tell us it as now before deploy
We may also keep for now this feature valid for string and numbers only.. that may be enough for the majority of debugging.
If we need to change the type/nature of values we need to re-deploy as now..
I don't see from my small point of view big problems to change values of periodic inject nodes. but if you think so let's introduce the edit feature only for manual inject..
That isn't quite correct. Don't forget that inject also is a mini-scheduler. I use inject to trigger a web request every few seconds for example. This isn't development work and it isn't a misuse of the editor.
1 Like
Good point 
The problem for me is that the inject node is about the first node anyone has ever used and the way it works is pretty much as old as Node-RED itself. so making fundamental changes to it has the potential for massive impact.
What I've read in the thread so far makes me uncomfortable that it leaves things open for confusion and edge-cases and makes users have to really think carefully about what they've done and where they've got up to.
I think that this would be a good candidate for a NEW node. One that behaves in the way you say. That way, the behaviour is expected and only invoked by taking a conscious decision to insert it. Even better, it could take an input (which could, of course, be your standard inject), therefore being a lot more useful since you could dynamically change ANY thoughput which is much more likely to be useful in development.
So more like a "Dynamic Change" node than a dynamic input to inject.
1 Like
Yes of course, a new "advanced inject node" for advanced users is welcome too
1 Like
Best of both worlds - no confusion and much easier debugging for everyone
To be honest, I disagree. Adding another node to the palette that looks and smells like the Inject node, but has slightly different functionality would potentially cause more confusion.
If we decide to do anything in this area, it would have to be an incremental change to the existing Inject node that doesn't break any existing behaviour or expectation - it would be additional functionality that is clear and obvious and can just as easily be ignored. That is why getting the UX right is the first task before committing to doing anything.
