I was wondering if it was possible to extend existing nodes with new functionality, where forking a node and sending a pull request for added functionality is not always a preferred option, nor would forking and keeping your own updated version of the node be. While this is quite generic and might sound vague, I've use cases where currently I'm just writing custom nodes for every situation, every specific website... And it's not very efficient as most of the interaction I need I can do through existing nodes. For example, when parsing HTML or XML, most of the time I only need a specific part of it. An often given suggestion on the forums is to convert it to a js object through the XML node (internally through xml2js), then call a JSONata expression on it to get the information you need out again.
Coming from a (black box) test engineering background, I'm not exactly looking too forward to that solution. In my automations, I often deal(t) with sites under third party control where I don't have access to the source code as half of it is generated and every new iteration attributes or order of elements change around (including up and down the tree). For me when dealing with these situations, XPath is my preferred solution. I've (had) to deal with web applications so unstable that to create a stable test automation (that will survive a couple iterations of development/rolling out to production without having to change the code over and over), a text search on the page had to be run to find connected elements and go up and down through descendants/ascendants to find the correct elements/information. For one in particular, I wrote the automation 3 years ago, and with the client rolling out updates every 2 weeks, that particular test (a very detailed search form where running the test manually takes 2-3 hours) is still working without any changes to my code.
One of my use cases involves getting information from specific webpages of grocery stores in my area. Each of these stores use their own kind of website setup. Some use (internal) JSON based APIs that populate the page, and thus getting info out is as easy as connecting to that JSON API instead. Others add everything on the server level into the webpage, so parsing the entire page is needed. This use case is based on my worsening mobility, and the difficulty to get my needed groceries every day. Since most of the stores in the area support delivery above minimum amounts ordered, it's a viable solution. Because of my worsening health in general, I won't be able to fiddle with flows on the bad days, and that's exactly when things always go wrong. So a solution that is as-stable-as-possible is preferred.
Instead of writing custom nodes for all these specific cases, there are a couple options for me, including 1-liner function nodes connected to switch and change nodes, with the code from those function nodes calling libraries made available through settings.js, or executing local scripts that send the output back to Node-RED. If something needs to be changed to a flow like that, the result is quickly becoming maintainability hell. At this point the best solution feels like being able to add rule types/formatting to the core switch and change nodes.
This might not be the best thing to ask in general considering that Node-RED is of course coming from an (older) javascript background, and the newer class written format (ES6 and newer) is still far from the OOP based languages, but I was wondering if it would be possible to extend existing nodes, in a (similar-to-)OOP style. Since my own additions are aimed at use cases like the above, writing PRs for the core nodes would only make the core more convoluted. A different option would be to fork the core libraries and keep my own maintained version of these nodes and support them through every update, which I'm pretty sure I'm not able to do with my health. Yet another option would be to create custom nodes for the core switch/change functionality, where the code is just copied from the core library with a couple lines added, which again I'm very much not looking forward to. One of the reasons I'm hoping to port most of my home-grown solutions to NR flows is to ease maintainability, and have them be as stable as possible; not having to touch a finished (block of a) flow for months would be preferred.
Coming from an OOP background, the ability to have custom nodes being an extension of an existing node with specific functionality added/changed to it sounds, frankly, amazing. But looking at the core design of NR and nodes, I have not a clue if this can even be implemented at all, let alone without becoming a huge breaking change for existing nodes.
