How can a node update its own config/params?

I'm trying to persist the FlexDash configuration in the flow, similar to what the current dashboard does. The problem I'm having is how to modify the config from within the runtime. The problem statement is fairly simple:

  • Suppose a node gets an input message and in response it wants to change its own configuration such that the value for its config param color becomes red instead of what it's now. The node should then be marked as "needing a deploy" if one looks in the flow editor but the altering of the in-memory configuration must be independent of whether the flow editor happens to be open or not.

Something similar happens when one enables/disables a debug node, except that that happens from within the flow editor, not the runtime.

I would appreciate any tips on how to accomplish this. I know there's the admin API but it would be pretty perverse for a node running in the runtime to make an HTTP request to the admin API, and the finest granularity it exposes is a flow, which is pretty unwieldy.

If the change is intended to be permanent then the only way to make it so is to re-save the flow file. IE deploy, which as you know is via the admin API. If temporary then yes all parameters can potentially be changed dynamically.

I'm looking at permanent changes. I'm aware of the Admin API, but to use from within a node I'd have to do the following:

  • read the settings to get the port, path, and some creds for the admin API
  • make an http request to the admin API using that info
  • retrieve the flow in json, patch it
  • make another http request to the admin API to update the flow

(all this from within a node!!!)

If this is not completely byzantine, I don't know what is... Plus in the end if someone has the flow editor open they get the dreaded "the config has changed, do you want to merge?" pop-up.

HI @tve

I'm sure we had this exact conversation recently.

There is currently no way for a node to modify its own configuration. The is no concept of a node having 'unsaved' changes in the runtime. The only place a node can have unsaved changes is in the editor where a user is modifying the flows and hasn't hit deploy yet.

The lack of this ability comes from the simple fact there has been virtually no demand to be able to do this in the 9 years of the project. The one place where a slightly related requirement exists is with nodes that do oauth with 3rd party sevices, and are required to periodically refresh their tokens. As I'm sure I replied before, that is something we need to think about for the new Storage API that was potentially going to be part of Node-RED 3.0 - to provide a way for nodes to persist changes themselves without triggering a full redeploy.

However it is unlikely that storage API will arrive in 3.0 - because no-one has been working on it and time is running short. So it remains an item on the backlog.

1 Like

Sorry, my bad, I searched for it and couldn't find it. I thought it was a slightly different slant, but couldn't remember.

I guess then I will queue up all changes in the runtime and when a flow editor is open send the changes over, apply them there, and then the user gets to press the deploy button...

But the user may never open the editor ?

The user will see something akin to the red deploy button as a reminder.

I'm doing my best to work with NR :crazy_face:.

So far the only other workable suggestion I've gotten was from Bart, which is to open an iframe to show flexdash inside the flow editor, let the user adjust layout there, and then when closing the iframe transfer the layout back into the layout editor so it can be saved. I could do this, but it's quite some work and the whole window sizing could be quite unworkable, e.g., typically I like to try different sizes so I can test mobile, wide-screen, etc. Doing that when everything is inside an iframe inside some panel in the flow editor doesn't sound appealing.

Ah. So this is when the user edits the ā€œliveā€ dashboard in situ ? So yes I guess they would expect to see something like undeployed. Makes sense now. (I was thinking the changes were coming from events in the flow)

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.