Not sure if demand is there, but I'd like to request some sort of visual indicator (perhaps a colored border indicator like the debug node gets if you hover over one of its messages in the debug window) to let users know if a node on the canvas is currently processing a message. This would make it easier to determine whether a lack of output is a result of a flow with no actual output, or whether we're just being impatient waiting for a particularly taxing message.
We’re not going to do this for most nodes as the comma overhead really does build up if you have lots of nodes and a very high message rate.
Some nodes like the http request node and exec node do show an indicator while processing.
Which particular node(s) are you thinking sbout
The ones in particular that I was using where this came to mind was a CSV>split>switch>join chain. Before I thought better of it, I was feeding it a way too large CSV file (the resulting filtered array contains around 400,000 objects, each with 4 properties.) I cut it to something a little more manageable for prototyping (the only time any visual indicator would be a valid ask, because I have drank and fully digested the "the editor is not a dashboard" kool-aid) but it still made my brain itch in a very "I wonder if anyone else would have use for that too" sort of way.
That all said, I don't know enough about what's going on under the hood to know if it's a reasonable suggestion or something totally infeasible.
Please note that I mean the following not seriously:
One way to solve this would be the following:
You have a button somewhere to enable "process" indicators on a flow tab basis.
Then on this flow only every wire would flash in a color if a message is passed through.
It would definitely look cool
If it is turned off, no performance impact
For csv - you can use the file in node and set it to send a msg per line. This effectively reads the file as a stream and does a split (and adds the relevant msg.parts) - so it doesn't have to wait to load the complete file.
Maybe cool - once. There was a reason the
<blink> tag was deprecated. Having lived through it once I don't need to go there again.
Not a bad idea. I was trying to keep it whole on the way through so I could use an array reverse at one point (working with a log from a medical device that dumps its audit logs in what feels to be the least useful formatting imaginable for our purposes, but derp, I can just reverse the final array after the join.)
I guess my mental image was more of an "amber outline if there are any messages pending" approach.
After the file in the necessary msg.parts are in place so you should be able to use a join again at some point - maybe after having reduced some fo the fields, - and then yes reverse the array later.
There once was a fork that did flash the wires... (anyone remember Octoblu ) and we didn't accept the PR then either...
Yep, that's what I ended up doing.
That sounds awful...
I probably shoudn't have posted my post, since I really did not meant it seriously, sorry
Sometimes knowing or talking about what doesn't work is as important as knowing or talking about what does.
well it did look fine when really slow - but we don't want slow
Aww, that would have been way cool! I think that animated rainbow colours would be fab.
You can get back in your box with Timothy Leary !