Fix nodes that aren't broken?

Developing Nodes
1

I am doing some maintenance and renovation work on nodes I published long ago, about the time of NR version 0.17. I wonder whether it would be worthwhile to update the JS file to use the features introduced in version 1.0, in particular, the new input listener with send and done functions. I obviously would have to avoid breaking compatibility with earlier versions of NR. Are there other changes worth making?

1 Like
2

Maybe nothing that needs doing but things I do when I go back and update old nodes...

  • Add example flows for CTRL+I examples import
  • Improve built in docs & add reference to there being built in examples
  • Ensure elements in the edit form expand correctly as the edit form expands using style "width: calc(100% - 120px)"
  • If you have an ACE editor on the edit form, make sure you call the correct API instead of accessing ACE directly
  • Change any override-able inputs with typedInputs
  • Add a "Returns to msg.____" so that the user can avoid having to add change nodes after you node to move the payload into a different area of the msg when performing several serial actions.

Note, none of the above are necessary but I have found they make for very useful user enhancements.

4 Likes
3

Quite a few of the the extra nodes we ship do now have done and complete added in a non breaking way so it is good if you can add those as you go forwards.

4 Likes
4

Obviously update any dependent packages, I do this as a matter of course before publishing a new version of my nodes. I also use an add-in action on GitHub that lets me know (and even creates an automatic PR) if there are dependencies that should be updated.

1 Like
5

Thanks. All good suggestions -- most already part of my practice.

I sometimes think that my example flows may be too large/many. I have started omitting their JSON strings from the README, because they fill up the library page and force the reader to keep scrolling to find the end. Of course, that makes it all the more important to point the user to the import menu.

I confess to failing totally when it comes to using the style guide for help text. Most of my text was written before the guide, and there just has not been enough spare time, even during COVID, to invest in re-working it.

6

On the job queue, completion date unknown.

7

Regarding your question about backward compatibility for the new features of the input listener (a.k.a. support for the complete node):

This is what I'm doing:

  • change the signature from (msg) to (msg, send, done)
  • declare send and done locally with fall-backs (see below)
  • replace your node.send() and node.error() calls with them
  • add the done() call in all non-error code paths once you're code is done

Should be it, hope I didn't forget anything. :nerd_face:

this.on('input', function (msg, send, done) {

    send = send || function () { node.send.apply(node, arguments) };
    done = done || function () { if (arguments.length > 0) { node.error.apply(node, [arguments[0], msg]); } };
    
    send(msg);

    done();

});
3 Likes
8

As uibuilder now requires Node-RED v1.3 as a minimum, I don't bother with that now. But I use it on other nodes.

9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.