When are config nodes defined in the flow editor?

[tve]

From another thread:

@kevinGodell

I am just curious if it is related to something I recently came across in the editor trying to run code in the onpaletteadd function and realizing that RED.nodes.eachConfig can never find my config node because it is too soon to check. I am still trying to determine if that is a bug or just the expected behavior. Regardless, I have a pretty clean workaround for it by adding RED.events.on('runtime-state', handleRuntimeState) in the onpalleteadd function. After the first time it detects obj.state === 'start', I remove the event listener.

I think the question here is what do you need this for, because there may be better ways to organize things.

Waiting for the runtime-state event is not cool because you assume that the runtime will start, which is not a given. Especially if there's something wrong and Node-RED is in safe mode then the event will never trigger (I believe). The flow editor should really work without the run-time (other than of course having to be served-up).

The loading of node types is very async. There is also fun stuff where, if a config node type doesn't get registered and nodes reference it, then the flow-editor creates a place-holder type that is essentially empty. The process and ordering of hydrating the config is pretty involved, rather complex, and very difficult to follow in the codebase.

Again, your best bet may be to describe what you use eachConfig for 'cause perhaps there's a different solution.

[knolleary]

@kevinGodell

I am still trying to determine if that is a bug or just the expected behavior.

onpaletteadd is called when the node is added to the palette. That happens before the current flow configuration is loaded. So it is entirely expected that eachConfig wouldn't return anything for code called in onpaletteadd.

@tve

Again, your best bet may be to describe what you use eachConfig for 'cause perhaps there's a different solution.

Indeed. Is this really a one-time only action you want to run, or something you need to do whenever a new config node of a particular type is added/import or removed?

[kevinGodell]

@knolleary

onpaletteadd is called when the node is added to the palette. That happens before the current flow configuration is loaded. So it is entirely expected that eachConfig wouldn't return anything for code called in onpaletteadd.

Thank you for confirming that is to be expected. I was mimicking what the node-red-dashboard does when it adds a singleton config node automatically. node-red-dashboard/nodes/ui_base.html at master · node-red/node-red-dashboard · GitHub. My problem was that I was trying to add the config node a little too early.

@knolleary

Indeed. Is this really a one-time only action you want to run, or something you need to do whenever a new config node of a particular type is added/import or removed?

Well, I am in the very early stages of my experiment, so it is not fully thought out just yet. I am trying to find a good workflow for adding something that is not a standard node or plugin. A couple years ago I made my own private use (non-admin) middleware auth to give myself finer control for the node-red-dashboard access and my video streaming apis, such as user level, route access, etc. It has worked good, but it was all manually configure with json files. I am trying to utilize a config node as a place to secure the details and credentials and manage my middleware. As far as I know, a config node is usually added by a regular node, so I am taking the route of making a self initializing singleton config node. It works!

In the backend, the node checks if the middleware has been imported and called. This flags a variable that the middleware is in use. Also, I check the settings to verify that https is configured and that httpNodeAuth is not in use. Errors are logged on the server side and a friendly reminder is given to the user in the editor if they have gone through the trouble of manually adding my middleware and now are compelled to fix the configuration error in settings.js and add the config node. If the config node is not created, then the middleware is in a default state of preventing access to any route it is protecting.

Probably sounds more complicated than it is.
The middleware has been added and they have any conflict, then they see something similar to this:

If no conflict is detected, but user has not had the config node added yet, they will get something like this:

Once an instance of the config node has been saved and deployed, the middleware can now function properly.

User only receives notifications if they have manually added the middleware to the settings.js file. I am trying to be the least intrusive as possible, while also enforcing that the middleware must be configured to be functional.

[tve]

If I understand correctly, the issue you're having is to detect when the user has configured the middleware in the settings but has not added a config node to manage it. What I would do:

• in the node .js outside of the node itself check the settings to see whether the middleware is configured and set-up an API endpoint to be able to serve-up the info to the flow editor
• in the node .html outside of the call to registerType query:
  • make an API request to the API endpoint to find out what the settings situation is
  • set-up a handler for the add-node event so you find out whether a config node is created
  • set a 1-second timer and when it fires evaluate the settings/config-node combo to decide whether to pop-up a warning

The 1-second timer ought to work OK 'cause the type you're registering isn't going to be delayed (since it happens in the same JS module). But yeah, you're looking for the same notification that everything loadable has been loaded... It's that absence-of-a-node check that is not otherwise possible... I need it for garbage collection, you need it for a 'hey dude, you're missing something' pop-up.

[ralphwetzel]

@kevinGodell

something that is not a standard node or plugin

Why don't you like to implement this as a plugin?
Defining the UI is almost the same effort as for a dedicated config node & you will be able to manage (save / load) your settings on your own behalf?!
There's an additional benefit from my perspective: Plugins are loaded very early in the process of setting up the client side - thus you can get things under control quite easy!

[knolleary]

You are also going to have handle the case where a user imports an existing flow and ends up with two instances of your config node.

This is where I would use the nodes:add event to listen for anything being added, start a timer so you can debounce the multiple events you get when importing lots of nodes (including the initial load) and then run your processing.

[tve]

Couple of points:

• 'til the next release you can't safely have a plugin and a node in the same NPM module due to a potential race condition
• plugins don't have config saved in the flow file, so he'd have to come up with a different way to save state
• a plugin doesn't eliminate the "is a config node configured or not?" issue

[ralphwetzel]

@tve

'til the next release you can't safely have a plugin and a node in the same NPM module due to a potential race condition

I know! What I wasn't aware of is the indication that this should / could be fixed with the next release; that's good news!

@tve

plugins don't have config saved in the flow file, so he'd have to come up with a different way to save state

That's what I said:

@ralphwetzel

you will be able to manage (save / load) your settings on your own behalf?!

@tve

a plugin doesn't eliminate the "is a config node configured or not?" issue

It does, as there's then no need anymore to use a config node - when the plugins panel is used to manage the settings.

BTW, it eliminates in addition the issue raised by Nick ... to ensure that only one config node is present. I wonder how to decide which one to utilize, when there is a choice...

[kevinGodell]

@tve

in the node .js outside of the node itself check the settings to see whether the middleware is configured and set-up an API endpoint to be able to serve-up the info to the flow editor

How did you know? i did that exact thing.

RED.httpAdmin.get('/middleware', RED.auth.needsPermission('middleware.read'), (req, res) => {
        res.type('json').send(JSON.stringify({ usingMiddleware, usingHttpNodeAuth, usingHttps, errors }));
    });

@tve

in the node .html outside of the call to registerType query

I was calling fetch to that endpoint in onpaletteadd. I had not tried doing it before registerType. I will experiment with that.

@ralphwetzel

Why don't you like to implement this as a plugin?

I was a bit lazy. And I really wanted to easily use the credentials and did not see an easy way to do that from a plugin. That was my first failed attempt. Maybe I would have gotten further had I not gotten stumped when checking the existence of the config node during the plugin's onadd function.

@knolleary

You are also going to have handle the case where a user imports an existing flow and ends up with two instances of your config node.

I hadn't considered the importing. Currently, I was planning on mostly using only credentials in the config node. I didn't think credentials could be exported. Also, I do it similar to how node-red-dashboard does and only keep the first node found and remove any extras to ensure only 1 exists.

@ralphwetzel

It does, as there's then no need anymore to use a config node - when the plugins panel is used to manage the settings.

BTW, it eliminates in addition the issue raised by Nick ... to ensure that only one config node is present. I wonder how to decide which one to utilize, when there is a choice...

That would be my preferred way if it saved the details outside of the regular flows and used something like the credentials. Do you have a link to any repo that does that?

[ralphwetzel]

@kevinGodell

saved the details outside of the regular flows

I know, that these two packages (I'm the author of the second) store data outside of flows:

GitHub - zwave-js/node-red-contrib-zwave-js: The most powerful, high...

GitHub - ralphwetzel/node-red-mcu-plugin: Plugin to support the Node-RED...

I haven't checked, if you can re-route the Node-RED Credentials API to utilize a non-standard storage location. It yet doesn't seem to be a lot of effort to refactor the relevant parts...

[kevinGodell]

Thanks. I will read through the code and see what I can do.

[TotallyInformation]

@ralphwetzel

I know, that these two packages (I'm the author of the second) store data outside of flows

uibuilder has extensive data outside flows. But you do then have a lot of details you need to manage such as dealing with environments that don't have a full OS (e.g the IBM cloud), clashing folder names, people accidentally deleting things - or adding/renaming, and user desire to move things to more convenient locations.