Customization/Developer mode on Nodes

[hgill]

Hi Team

I have a design suggestion which may help make contrib node development faster. I've developed 1 and customized 2 node-red-contrib nodes so far, the experience is good and structured but I wish there was a way to make changes without needing to redeploy all of node-red.

Apart from actually registering a new node in the palette using RED.nodes.registerType, perhaps much of other code dev happens to be about on-init, on-input or on-close blocks.

Design Idea: Have a toggle button on nodes, called "Customize" or "Developer Mode" button similar to and next to Enabled/Disabled button, but this one will be disabled by default.

Working: I could think of 2 ways to implement this. Essentially, when you enable this mode,

1. the node could give you a new customization edit box where you could write a 'customization' function which would be run with a simple event handler at the end of node definition, like so:

if(node.customize && typeof node.customFunction=="function"){
    node.customFunction();
}

2. else, it could give a 'customization' input on the top of the node, to which you can wire-input a function on a 'customize' event and execute it immediately after ingesting it.

node.on('customize',(customFunction)=>{
    customFunction();
});

In the first approach, node-red server won't have to be restarted as the customize event can be called on node init rather than node registration. So, changes should work after re-deploying the current flow, and should functionally not be any different from changing a config param.

In the second approach, even the node won't have to be restarted, and minor customizations can potentially be done without changing node code or registering completely new node types, etc.

Use cases:

1. I could use this to add features to node.on('input') for dev purposes, or may even choose to completely override functionality.
2. Another use case could be changing static properties in the node object, for example I may use it to redirect flow messages to a different database temporarily.

Caveat:
One would of course have to understand the original node's source code to know what to change, as completely overriding functionality is a useless capability - it's of course much better to create new nodes. Also, I haven't tested if this method works, and there may be more elegant ways to customize node functionalities.

[knolleary]

Hi @hgill , we prefer suggestions to be discussed in the forum or slack first. This discussion list is for items we're already working on or being considered.

I'm not convinced this is addressing an problem that justifies the amount of work needed to realise it.

I could see having a specific custom node type that lets you edit more of its fundamental code via the editor might be interesting. That could then be exported as a set of 'real' node files. Although the Function node does let you do most of that today (just not the export as .js/.html bit).

I also don't see how this would work for existing node types - unless you mean it would expose the existing source code? Even then, given all the different ways a node could be written, I don't see how this would be practical to do.

[hgill]

Understood - will ensure to post ideas in slack first.

So my angle here is that the contrib library is rich, so far my use case has at most required adding a small feature to an existing lib or node to get the behaviour I want.

Also, I think the custom node type you mentioned would work perfect. It's definitely much easier to understand than the function ingestion idea I mentioned. It would also handle js & html both - which I had ignored.

In my view, the function node does allow experimentation, but makes editing existing contrib libs difficult, as the fusing of config/html params & the node registration and definition takes some time to set up, requiring deep understanding of the implementation, defaults, underlying libs etc and then rolling it back again is time consuming as well.

So overall, +1 for the custom node type covering html/js.

[hgill]

Publishing these custom nodes as contrib library to NPM & to Node-red website straight from the editor would be very cool as well.

[lgrkvst]

My $0.02... I develop nodes extensively at the moment, restarting Node Red at least 100 times per day. I found developing inside function nodes is way too sandboxy, especially if you involve events, communicating with config nodes and auth on top.

My solution to speed up iterations was to create a "code injector node", i.e. a node that has its logic in a separate file that is re-require'd upon each invokation. Super simple, full access to RED, and you can hot swap the logic at will.

The html lets you enter the filename (path) of the file to run relative to the runtime.

The js:

module.exports = function (RED) {
  "use strict";

  function FluidlyAdminCodeInjector(config) {
    RED.nodes.createNode(this, config);
    var node = this;
    node.filename = config.filename;
    node.on("input", function (msg, send, done) {
      var _module, filepath;
      try {
        filepath = require.resolve(node.filename);
        require.cache[filepath] && delete require.cache[filepath];
        _module = require(node.filename);
        _module(RED)(node, msg, send, done);
      } catch (err) {
        node.error(err);
        msg.payload = err;
        send(msg);
      }
    });
  }
  RED.nodes.registerType("fluidly-admin-code-injector", FluidlyAdminCodeInjector);
};