i not like the sub floats because you can not start direct, they have no visible state after deploy.
the user wonder why the lines are dotted.
its better so make a segment (user node) with a entry and exit point that can be folded optional at the same flow page.
maybe take a look at construct 2 or unreal engine for inspiration, they using visual design too.
i believe my wish is some kind of node in node. i am missing also a in/out (start/end) at the flow itself.
as developer i thinking in functions blocks or tasks.
they can have much details at design but for usage its more a black box.
the designer seems to use a fix design area but it should be auto size based on contend.
Subflows let you create a node in your palette that is implemented using other nodes. You can then add as many instances of the subflow node into your flows as you want. That is the main use for subflows - which is slightly different to what you describe.
I think you're asking to be able to visually collapse a set of nodes in the editor into a single node and expand them again when needed - is that right?
I'm not sure what you mean here - can you explain a bit more?
hi @knolleary ,
i mean building a function scope.
"collapse a set of nodes" will be a node which contains other nodes inside. a node hierarchy.
this inner part can displayed like a "subflow" at any place on the flow, it have a in/out and a border around the inner part. folding / shrink / expand is not necessary.
about the start/end at the flow itself, i try to explain in text:
take a look at the "rpi-gpio in" or "inject" or "ui_switch"
in the flow i like to have a start -> rpi-gpio -> end -> goto start
that is a completely flow.
start -> wait button click -> do something -> end -> goto start
a clock example:
start -> function with playload date time -> ui_text -> wait 1 sec. -> end -> goto start
Node-RED is event driven; an event happens to trigger a flow. For example, the rpi-gpio node detects a change in state of a gpio pin - so it triggers the flow. There is no concept of a 'start' and 'end' node for a flow.
You can use the Link nodes to achieve 'goto' like semantics.
hello @knolleary
"event driven"
that means its always auto active.
if u have a start node the event would only processed between start and end.
i think its importent to make a real application flow.
the goto i mentioned only to build a loop related to start-end concept.
i believe with a start-end node the flow is more understandable.
and its essential if u think about nodes in node i described before.
the beginning would be a master node which contains other nodes or user nodes.
What you describe is a fundamental change to how a Node-RED flow works. There are plenty of 'real' applications using Node-RED as it is. I'm not sure what else to say.
A flow 'starts' when a node receives an event. It 'ends' when a node doesn't pass on a message (either because its not wired to anything, or by design, doesn't send anything).
I don't see why they are needed for the collapsible nodes idea.
If you have a flow that consists of:
[a] - [b] - [c] - [d] - [e]
And you want to collapse the middle nodes down, you'll get:
[a] - [ bcd ] - [e] - with the collapsed node having both an input and output.
You could equally do:
[ abcd ] - [e] - with the 'collapsed' node having a single output, but no input.
That works with the model we have today - its what subflows are (albeit with the additional semantics that subflows provide).
@MarkusR in a way, NR already has "start" nodes ... they are all the input nodes in the palette ... and the "end" nodes are all the output nodes ...
for one flow, you can have as many start and end nodes you want: there are multiple ways to start your flow and to end it ...
NR is not a line-by-line visual programming aid: it's not ladder, it's not grafcet, it's something else, very easy to use, flexible and yet powerful ... try playing a little bit with the core concepts and you'll see that you don't have to change much from your (classical ?) start/stop philosophy to grasp NR's philosophy ...
they are problematic because if u change one you change the meaning/usage at all flows.
that is very risky and maybe sometimes unwanted. the same idea of subflows as part in a normal flow would be fine.
i tryed to make a pic how it would look in the same flow. screenshot
the in/out at a subflow is similar a start/end.
about backward compatible and event driven, maybe make the event as input pin that can be overwritten.
then we can use click->button->do or without extern event its still button->do.
plus this will work condition->click->button->do.
@tilleul
yes thats correct but i like to have a condition before this auto runnings things.
my first project was a alarm tool with my raspberry pi, it have a motion sensor.
so the first thing in mind is a on/off switch, if the switch is off nothing is to do.
if the ui switch is on the gpio pin is watched.
now i make the condition behind because this "rpi-gpio in" node can't have a in pin and its selfrunning.
The point of using subflows is to have reusable flow logic -- so yes, in that case I want each usage to operate identically. It cuts way down on the number of times (for instance) that I have to set up http headers for calling APIs.
In your case, it sounds like you just want to have your Alarm flow on a separate tab -- that way it's not stuck in the middle of your other logic. Then, when it's time to trigger that alarm flow, send it a msg through a pair of link out/in nodes... this is a virtual "wire" that connects the two tabs and allows you to send msgs from your main flow to the alarm flow. Multiple main flows can all have a link out that connects to the same link in node that starts the alarm flow, or the alarm flow can have multiple link in "entry points" to invoke different behaviors from the alarm flow.
i understand the subflows but at my first usage i thought its only for the flow i am working on.
yes my intention was to put a block of logic apart and see it abstract as black box.
my feature request was more for generally usage.
subflows are so different from a normal flow, u can not start with inject inside,
u need switch the tab, click there inject, look what happened in debug and then continue the work in the other tab. the normal flow show a state, the subflow not, and its shared with other flows.
i tested the link out/in for what i imagined but this node show only a arrow and not a name etc.
for a small application its all ok.
this node-red is also interesting for modular business apps,
that can have a deep hierarchy and thousands of functions that working all together.
