Granted, I've only been using NR a few days and I've got a ton to learn but it seems a glaring omission that there is little control over a flow's operation. What I expected to find (and I suggest right-clicking on the flow's tab) is a menu with Save, Revert, Delete, Start, Stop, Enable, Disable, and Pause. NR has amazing capabilities and I'm already planning on making it my center for processing and display but I feel it's archaic to have to get into the flow's properties to dis/enable it and that a Deploy button starts everything. How about removing Deploy altogether in favor of the items I'm suggesting in a menu?
I've searched the topics here and found no rationale for the current way it operates but I have seen a few frustrated users over the way it now works.
The fundamental model of Node-RED is that everything that is deployed is running unless it is disabled.
You make a change, you deploy the change.
The deploy button is how updates are made to the running flow configuration.
The ability to disable a flow (or node) is a relatively new feature in the project's 7 years of working like this. Some of the UI around it can continue to evolve as we get feedback. You say you have seen lots of frustrated users ... I can't say that's feedback I'm particularly aware of. There has been the very occasional question about it, but nothing to warrant throwing away the fundamental model of the deploy button.
So thanks for your feedback after a few days of using it. It's clear that the model you expected is different to how Node-RED actually works. I'm sorry you find it archaic.
Thanks for the reply, @knolleary. To set the record straight, I didn't say
I said
Please don't misunderstand because I also said
I sincerely hope my suggestion will be implemented at some point. Meanwhile I'll conform because I have no other choice At least not short of diving in and making the changes myself which I would gladly do if I were familiar with Node... and 40 years younger.
What would the difference be between start/stop and enable/disable and the difference between pause and stop?
Is there a difference between Save and Deploy, as far as the current tab is concerned?
The other thing to bear in mind is that currently we also have a "few" tablet/mobile users - and right click is not really an option for something as fundamental as deploy.
Hello and next time please leave the pin in on your hand grenade when you lob one into here
But, you raise some interesting issues
Leaving aside ergonomic diff between double-clicking/right-clicking on the tab to do stuff like enabling/disabling etc as that's just cosmetics
I (and many others) use NR to run long-running tasks (24/7 ones) and we've grown to like the concept of editing and then using the one simple button (Deploy) to stop the background program running - reload current flows and then restart again.
[EDIT] When you hit Deploy - you have several options to restart everything or just the bit you've just editied[/EDIT]
That's actually quite a good feature usually not available in other programming IDEs
So I think having to do separate Save then Stop then Start isn't an improvement over that in terms of whole running system
BUT....
Just being able to stop/start/pause one flow (while all others carry on running) could be useful. (See note below)
I'm not sure how easy (or important) this would be able to acheive
NOTE:
If you stick gate nodes in your flows - then you can effectively do this
As an example, this Alexa flow of mine has them in so I can test out stuff without the final result messages leaving the flow.
Let's use systemd services as an analog. Start/Stop does so immediately whereas Enable/Disable controls what happens on startup.
Save would just update the backend with the current flow changes whereas Deploy does this AND starts not only the flow you're working on but ALL flows that are not disabled.
Doesn't the "hamburger" menu fit this? I'm an Android guy and don't know what IOS uses for the purpose.
Being new to NR has both advantages and disadvantages and I understand that long-time users just know how to work in it. We humans have a built-in resistance to change even when we can see the benefit.
@cymplecy, thanks for the laugh and edification. I, too, will have most everything running 24/7 and wouldn't want running flows to be affected in any way while I'm tinkering with a new, or old, one.
If the background were like systemd, or whatever it's analog is on Windows (Service Manager?), it wouldn't be necessary to stop any flows to start/restart the one currently being edited. But I see where changing the architecture from a "run everybody at once" to managing each individually is like a very large change.
I'm familiar with Netbeans and there you can have several projects in the editor and edit/start/stop/debug them individually. However, you do have to stop them all to exit the IDE and would then run them however you normally do outside the IDE. In many cases it's feasible to leave the project running in the system environment and run another instance of it while working in the IDE.
Before anyone swoons at the changes needed to make NR the same as Netbeans understand that I'm not advocating for that big of an overhaul. I don't see a need for, or benefit of, it in the much more focused environment of NR.
I've worked around, and just a tiny bit on, industrial process control systems enough to know that one can stop/edit/start one PLC and not affect the others unless there is a dependency between them. Is a NR flow not analogous to a PLC?
I apologize if I came off as disparaging the designers or users of NR. My thoughts were of my frustration (and of at least some others) and the desire to improve this fabulous tool/system.
No - but a nice big deploy button does - the hamburger menu is only one per page - you are talking about right clicking on each tab of which there may be many.
I'm glad of that - for a minute I thought you were wanting to completely change the existing runtime lifecyle model of Node-RED... oh....
As node.js is single threaded then yes the whole runtime is analogous to one plc (which includes all the tabs). It may be better to think of the whole runtime as one exe file... as you also said, once it is running you don't generally get to turn on and off parts of it. The whole point is that it runs headless most of the time - I don't run most of my apps from an IDE. Even when in an IDE I don't generally get to disable methods and calls without going into them and commenting them out.
One of the reasons we resisted even disabling tabs for so long was exactly the reason @cymplecy mentioned... that it is all to easy to disable something then forget you have done that... even worse in a multi user environment where some else may do that for you. If it's always running yo know where you are. If you don't need it - disconnect or delete it... OK we softened on that, and indeed we may still have further to go - but it will be small steps to ensure we bring everyone with us... whatever that direction is.
From a UX perspective, we already have the Flow Outliner design which will give a better overview of your workspace contents. That will be a place for in context actions to be made available. Being able to more readily enable/disable things is one of the uses for it.
It would still work on the assumption that you have to click deploy for any changes to take effect, because that's the model we have.
At least not short of diving in and making the changes myself which I would gladly do if I were familiar with Node... and 40 years younger.
- the hamburger menu is only one per page - you are talking about right clicking on each tab of which there may be many.