Feature request, edit Inject value without deploy

Here is my proposal:

  • On the current inject node, only a checkbox "Enable advanced features".
  • All nodes with this chechkbox enabled are shown in the sidebar (like the config nodes).
  • In the sidebar it is possible to inject or edit the injection message without deployment.
  • Additionally it would be nice to have a list of the last x msgs to choose from.
    and an option on the debug messages "Add msg to injection msgs list", to easily reuse a debug msg with an injection node.

Hi Nick,

I know this is still on the trello board but there doesnt seem like much in the way of a formal spec like the mqtt-control had.

So I had a bit of play this afternoon...

With a little bit refactoring of the inject node and calling the built in RED.tray.show() I achieved this...

NOTES

  • values in the inject config are never changed (so no deploy)
  • I did at first use a popup dialog (and it looked good but editing the buffer/json was problematic)

Any good for node-red v2.0.0?

3 Likes

No - we don't want a pop-up to appear every time the user clicks the inject button - that will annoy most users.

Please talk to us before you spend time implementing features on the backlog. Especially where there is no existing discussion on the design of the feature. Given how long some of the items on the trello board have sat there, do not assume we still want to do them as written. Talk to us first.

I don't have a good answer for what the UX should be though - which is why this item has sat on the backlog for so long.

The tray is only presented if the user holds a modifier key. Otherwise the inject just occurs as before. Seemed like the obvious solution. (modifier key to modify values) and I only used existing components (tray) so nothing new.

It's not an issue if you don't want it. It was just a bit of play time.

Okay - I didn't see that mentioned in your description. That seems reasonable.

I see you say it doesn't require a deploy, but does it update the node properties locally with the updated values? I can see a case for both doing and not doing that. I wonder if having a checkbox at the bottom of the dialog that says 'update node properties' could give the user that choice.

I could imagine if they want to quickly iterate to find the right value to inject by testing different values, they want to make sure the value is stored in the node when they get it right.

No worries - just please check in with us here or on slack before you invest your time on things that may not be a good fit at the moment.

Given where you've got to, you may as well put in a PR against dev and we continue the discussion of the details there.

1 Like

Yeah, hard to convey in a gif (so I put it in the comment) - I probably should have put it in the NOTES tbf.

I did also think about whether changes should be applied back to the node but in the end, as it was just a POC, I didn't (and it can be added later if requested)

I will push a PR later after a bit more play. Make sure there are no silly mistakes or issues.

I would agree that an option to push the changed values back to the node would be really useful. Especially if the option were sticky so you can set it once for a node and it is remembered.

Would that trigger a need for a redeploy though? Be nice if it didn't.

1 Like

You cannot update the flow configuration in the runtime without a deploy.

1 Like

Based your on your comments, you gave me an idea...

  • Keep the tray open so user can Inject over and over until they are happy with the result
  • User can press Apply button to keep changes
    or
  • User can click Cancel if they want to discard the changes

I think that feels a bit more useful - any thoughts?
gqdNQMXqZ9

7 Likes

So does 'Apply' also do the Inject? Is it actually 'Apply & Inject'?

edit - reread what you said... ok, I see what you mean. Lets have a PR so we can try it out and see.
...

I would still prefer we moved over to the context of a PR for the ongoing discussion.

1 Like

No, inject only injects. Apply only applies. (Atomic actions)

Yes, my bad, that's the next thing I'll do.

I will say that have the primary button of the dialog not close it would be inconsistent with all other dialogs, so whilst there's merit in having the dialog open between multiple injects, the inject button shouldn't be in the top like that.

I'll raise that in the PR as a discussion point Nick.

1 Like

For those that like to keep following this discussion, @Steve-Mcl has created a pull request where the saga continues....

This feature will be very useful for me for experimenting while developing new nodes. But I can see lots of other use cases e.g. when using Node-RED as a mock for some system, and so on...

Really nice feature :+1:

5 Likes

thank you all!

Where can I get the code, please

@Wu-haifen this feature was release in Node-RED 2.1

Okay, thank you!