- It has server side validation for configs and messages using json schemas
- node forms can be written using vue
And a lot more...
3 Likes
Node-RED core team can adapt my design ideas to the core. I only want the recognition.
Happy to recognise you, but currently we do not use typescript nor Vue in the core - so are unlikely to pull it in directly. Happy for it to exist as part of the eco-system.
I wanted to make node-red popular among developers making its dx closer to what people are used to nowadays. Also wanted to get recognized in the community for doing something nobody dared to do yet. Im an attention seeker 
3 Likes
Happy Cake day 
1 Like
Thanks @Sean-McG
Always remember that there are two distinct Node-RED communities:
- developers that create nodes for a ...
- ... community of users who develop flows based on the nodes developed by "developers"
These two are largely distinct with minimal overlap.
Developers of nodes use Node-RED - of course - but for their purposes. The larger community of "users" who enjoy the drag-drop-link-deploy-rinse-repeat interface of Node-RED to solve their problems don't tend to develop nodes to solve their problems. They might develop sub-flows to encapsulate certain repeated functionality but that's about it.
My aim is to empower the latter community to develop their own node solutions for their problems. Therefore within Node-RED as a flow --> ta'da --> NodeDev --> and it's not the best solution nor the only possible solution however it is an attempt to address - IMHO - the correct audience for a new concept of node development.
And why is this differentiation important? Because having non-paid developers create solutions for problems they don't have is a dead-end. The "user" community wants everything for "nothing" (in the sense of money) while developers just want to solve their problems. Sure certain things will be done because developers find them interesting or they have a similar problem but they won't be 100% solutions.
Here comes the next issue: hardware - developers mostly don't have access to the hardware for which Node-RED solutions are missing. So then you will need to give developers access to hardware for them to develop node solutions.
Giving developers that are fine with the current method of developing nodes - no matter how inefficient it might seem - new tooling is an uphill battle of convincing folks who already know and more importantly are comfortable with their setup.
There other approaches, for example @BartButenaers brilliant Blockly node that allows code development inside Node-RED using blockly.
4 Likes
I agree with you. Maybe my creation is useful mostly by conpanies that offer products using Node-RED and that care for code quality (hello Flowforge 
). Since they make money with it, enforcing code quality and best practices is valuable because developers can fix bugs or release new features faster. New developers can also be onboarded to projects way faster when its source code is modular and organized.
I just wanted to be reminded for improving something. No way I will die without contributing to our evolution, and been noticed by other peers.
Really creative indeed!
A company that I discovered recently was strato automation (Canada based). I discovered them because one of their nodes was downloaded 6000 times - last week! They have incorporated node red into their hardware products.
If you take a look into their node package (there is no source code online) then you’ll see that all their JS code is minified and obfuscated - another requirement for company node code.
EDIT: This package node-red-contrib-strato-apps-beta-test but only 5k and this company - they even reference Node-RED.
1 Like
I fit pretty firmly within @gregorius' second category of users - seems I'm not entitled to self-identify as a developer 
Will your tool help me to extend a pre-existing node?
For example I would like to add an additional action category for the change node: "OS command" which would pass the payload to an OS one-liner.
Checkout the sidebar of the nodedev package. There you'll find a package importer (factory symbol) where existing packages can be imported - as flows and then can be extended/modified in NodeRed - no editor required!
EDIT: added link to anime gif
I didn't mean to say people who write nodes using node-red aren't developers. Sorry if it sounded like that.
Does this work with node-red core nodes?
They aren't packages so no.
The first rule of programming is .... There are no rules! Except when there are. Maybe.
1 Like
err - isn’t that what the exec node does ? and no we don’t want to extend other nodes to include OS calls - as that is one of the things some organisations don’t like - (executing arbitrary code) - so being able to block the exec node is good… having to extend that to block (parts of) other nodes as well somehow would be a real pain.
1 Like
There's many ways of doing it, the exec node is only one.
An organisation that thinks blocking exec is sufficient protection is deluded.
I'm well aware of that Dave.
I have no intention of attempting to modify core nodes except possibly a local copy for my own use.
I value consistency and modularity. However, because I know most people dont like following patterns, I started to pretend I don't like either, depending on the environment.
I think it’s more like music… some people like some patterns, others prefer other types, and some listen to their own patterns 
3 Likes
An exec node also has spawn mode which is non-blocking.
But totally agree with @dceejay here: if there is something missing then that the exec node should do then perhaps add it there and not in a change node ... having said that ....
what about an $exec(..) or $shell(...) command in JSONata? That would then allow commands to be executed in inject change and switch .... but psssss I didn't say anything! 
