Here is another bit of writing from me, this time refactoring Node-RED flows. I was thinking that refactoring seems to be a non-topic when it comes to flows or rather a design patterns for flows discussion.
I'd love to get input and thoughts about this - I would like to do series aimed at beginners and non-Node-RED users.
Another novel feature is the use of the flow viewer - all images (except for the screenshots!) are generated on-the-fly from codeblocks.
Nice to see people writing blog posts for node-red
Refactoring IS quite often discussed but rarely, if ever, is it called that because that is a techie developer phrase.
I think, though that you missed possibly the most important tool for refactoring - the link nodes.
Refactoring flows often starts with tidying the layout and then realising just how much duplication or redundancy you ended up with. Link nodes can help both with the tidying and with de-duplication.
Many of us much prefer linked flows to sub-flows in any case because the use of sub-flows actually DOES introduce duplication (each instance of the subflow being a duplicate of course).
As with traditional code, flow designers are likely to read flows far more than they ever amend them and so layout is critical to rapid understanding and memory of what the flow does. The use of groups (with titles) and comment nodes further enhances (when you do it right!) the comprehension. Personally, I would include all of this under the topic of refactoring.
And using Node-RED as software for the blog - dogfooding all the way down with the turtles! Sorry have to plug the flexibility of Node-RED here!
Yes! I did that on purpose since a) the text would have gotten far too long and b) this is aimed at beginners as intro to Node-RED - I don't want to overwhelm readers right off the bat!
#metoo, I rarely use them but when, then with a specific and fixed purpose that isn't going to change.
Agree, hence my procrastination trap critic of Node-RED: the feeling of having done something by fixing the layout but that is a form of refactoring when visually coding. The number of times I ended up replacing or removing nodes because a layout didn't look "right".
I guess any boss when told (in the daily scrum meeting) "I fixed the layout of the flows" would roll their eyes and wonder how that could possibly be useful!
I see this also but boss' might not therefore one should make it clear how important layout becomes in visual coding.
