for me, a good guide are all the Unix tools and their command lines. using shell coding and then you have subflows --> for n in $(...) ; do .... ; done
This is just for the default set of nodes and with the aim of 'lowering programming language's steep learning curve', not necessarily a problem. Especially as more nodes can be imported from NPM catalogue to introduce capabilities instead (Discord, Telegram, PixiJS, etc).
Some of the rough edges can be fixed with further development and I don't how I feel about being able to edit node source code within the graph editor. That feels more in line with the game engine that inspired Blackprint than the no-code UI might suggest - possibly just a difference in intention for the project, targeting low-code instead of no-code.
I'm impressed with this one, thanks for sharing @gregorius.
1 Like
I was only commenting, not necessarily criticising. However, if you want an easier entry-point, then focusing on capability and not function is a much better UX. This is one of Node-RED's strengths in my view. It has a very low starting friction. Better than any of the other flow and visual tools that I've looked at (and I've looked at a LOT over the years both professionally and at a hobby level).
Having a long list of individual functions and no obvious entry and display points is not conducive to people getting started.
This is, of course, always true.
No, I couldn't really care much about that, anything even remotely complex would need a proper IDE anyway. My comment was more that I was impressed by the fact that a lot of the node code complexity was nicely hidden by using a parent class that you extend. This is, in my view, an area of some weakness for Node-RED. Code complexity for writing nodes is relatively high. Not impossibly so but there are a lot of complex parts that you have to provide boilerplate for.
It has actually started me thinking about whether there would be a way to do something similar in Node-RED. At least for the runtime component. I'll be giving it some more thought. I already use a number of singleton classes in UIBUILDER (which, I freely admit, is at the upper end of complexity for a node). I also use an refactored approach to the main runtime for all my nodes which I personally find a lot easier to follow and extend. But if I could embody the runtime boilerplate in a class and then extend that for each node, I think that might be very powerful.
Time to dust off my test nodes again. 
Indeed, personally, I always appreciate being able to look at potential alternatives.
12 posts were split to a new topic: Options for simplifying custom node runtime code?
Likewise, but my comment reads poorly. Sorry!
Iād be interested in seeing this once you have the time to share
I only have one question, does the showLabel: false flag work outside of the link nodes?
I was playing around with it and nothing happened for the nodes I applied it to 
Sorry, that's the single only question I have 
Given that has nothing to do with Noisecraft please start a new topic. Sorry for taking a hard line, but if random questions are added to unrelated topics they won't get seen by those best placed to respond. I stopped following this topic a few dozen replies ago - it is only be chance I opened it up to find lots of discussion about creating nodes and without re-reading through another few dozen posts I don't have the context of how it has got here.
It also makes it hard for others who may have the same question to find the answer if its buried in an unrelated thread.
You're quite right because that will probably interests others too and no they won't find it here - moved the question to core development.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
