Version: 1.0.1 - Docker
Details about my project:
I'm developing a VueJS frontend, using the ws Node.js WebSocket library with reconnecting-websocket, to control/monitor the active project in node-red. I'm communicating with built-in websocket in and websocket out nodes.
node-red will be running, unattended for the most part, and controlled by an operator/technician from my front-end VueJS SPA application.
I have a requirement to dynamically load the flows that are currently being run on node-red. Since I will eventually end up with over 10,000-100,000 flow tabs, there's no way I'm willing to do this in one project, or I would. I'm using projects, and the flows in a project will only be needed depending on the present hardware.
I've been using API v2 to POST to the /flows end-point, with the flows I want as payload, and striping the "rev" property from it. I'm sending the headers Node-RED-API-Version: v2
and Node-RED-Deployment-Type: full
. This all works, as expected.
Question:
If the editor is open, on any station, I'm prompted that "The flows on the server have been updated.", and whether I want to merge or ignore the changes.
Is there a setting I can change to prevent this prompt, and have the editor automatically reload the current server state? Maybe I'm not using the API correctly, and if so, can someone please point me in the right direction?
Thank you,
Scott Page
Short answer, no, there is no way to disable this prompt.
Prompting was the safest way to alert the use that there are changes to merge - especially when there may be conflicts between what has been deployed in the background and what the user has modified locally.
This is a whole area where I want to improve the general workflow and allow for more concurrent editing without having to interrupt users each time a change is deployed.
That's what I figured, and it's probably better to be safe than sorry for the masses.
If I were to clone node-red, and modify this behavior, where would I look?
I dug around for a few minutes, but didn't find anything conclusive.
Thanks!
Just thinking, you may also have to consider the use case that "a user" already have started editing the flow on his/her side. If you force a deploy followed by automatic reload on the clients side, the work in progress will be lost. Maybe should check first if editing is ongoing "somewhere" before deploying?
Your point is valid. Thanks for that!
In my case, I'm taking full control of what's happening in the embedded server, so no second user/session is able to touch the flow until the other user/session has closed the connection (through express server). I'm using node-red as single use vs allowing multi-user access, as is the case by default. I'm working in Electron, now, so it's acting as local only. Think of a workbench in a lab using a desktop app to get data from instruments.
The reason I'm needing to ditch the merge warning is because the local app needs to switch between different procedures (different flows and Electron renderers/windows). The main express server controls the switching when the user selects a new procedure. This was a problem, previously, because I was working in a Chrome browser, and didn't have control over the tabs the user had open, so I would get this warning.
Now that I'm working in Electron, I just close the BrowserWindow(s) that have a node-red Editor UI open, and that solves my problem.
So, for me, it looks like my problem is solved. However, this is still an issue if someone wanted to stay with a browser based system that resembles what I'm doing.
Anyway, thanks everyone for the input. Moving to Electron has solved the issue, for me. It would still be nice to have a setting to bypass the warning and force a reload of the browser from the comms (socket.io) side.