Drying Node definitions - avoiding code repetition

Developing Nodes
1

Hi There!

When I was creating my first nodes, I wanted to avoid repeating my code especially in the frontend definition of nodes. So what I did was create a "base" node that defined a JS hash. I then went on to use that hash in three other nodes: one, two and three nodes. In the package.json I ensured that the base node was initialised first and bobs your uncle, it works well enough in Node-RED.

Where it does not work is on the flows page for the package, those three nodes aren't shown:

Screen Shot 2023-04-10 at 10.35.17

I assume that complex JS code isn't executed by the flows site but what is the alternative? How can I avoid repetition and yet have all my nodes displayed on the flow page?

Cheers,
Gregorius

2

The flows documented in the catalogue, get index using Node JS - not in a Browser window.

What you see at https://flows.nodered.org is the result of a Node JS scheduled task - not a browser.
The website is just showing the indexed data.

Therefore, during index - its likely window is undefined.

This is just my guess of the problem - so could be way off the mark :sweat_smile:

Honestly, I'm not sure what benefit there is, in having a 'blueprint' - but then I don't know your project, so it maybe beneficial in your circumstance - most nodes I know of, don't have this approach for the definition :man_shrugging:

3

Indeed, I also noticed that :slight_smile: But since the labelStyle and the oneditXXX callbacks are all the same for all three nodes, I didn't want to repeat the code. I was simply avoiding repetition. If there is another way to do it, then I would do that.

For the JS part of the nodes, I did define a lib to avoid code repetition (and also to have a common memory store). Is there an equivalent approach for the HTML parts of the nodes?

I guess that would be my question: is there an approach for avoiding code repetition when defining the HTML parts of a collection of nodes?

4

Something like this

In your base node (and as long as its initialised first)
move any function that is used by all your nodes outside the definition block - but reference them

Base Node

<script type="text/javascript">
 
  function nnb_lableStyle(){
     ...
  }
  
  function nnb_oneditPrepare(){
     ...
  }
</script>

Other Nodes


<script type="text/javascript">
  RED.nodes.registerType('nnb-input-node',{
    oneditprepare: nnb_oneditPrepare
});
</script>

this will remove the need to store things in the window object

1 Like
5

Thank you :slight_smile:

That looks really cool, I'll give it a try and report back!

6

Ok I've updated the package and codebase to remove the window object, I wonder whether there needs to be an update on flows.nr.org to update the node list since the other three nodes are still not shown :thinking:

7

The site does fairly naive static parsing of the html files to try to extract the node definitions. It does not run any of the code to avoid any chance of code injection into the site.

That does mean it can fail to identify nodes that are 'generated' in the way you are doing.

1 Like
8

Was about to say.

You're calling a function to obtain the definition nnb_defaults_hash - that wont work, as Nick says. it's parsing the content, not executing it.

it will work in Node RED - but not the flow library as per above.

it must remain.

<script type="text/javascript">
  RED.nodes.registerType('nnb-input-node',{...})
</script>

you can still reference functions for the events as I have exampled - but you need to remove the need to call a function to obtain the definition - as it wont work on the flows website.

9

Ok, understand and can also understand that it won't execute the content - that would open doors to too much hassle.

I'll change it so that nnb_defaults_hash disappears but keep the common function definitions.

Thanks for the help & explanations :+1:

10

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