Feature request: ability to inject node templates dynamically

Core Development Feature Requests
1

I'd like to be able to write "node templates", i.e., the code for a node that lives in the flow editor, using Vue. I have it all working pretty nicely and rather simply and cleanly. The one stumbling block is that there is no clean way to inject the node template that I generate into the process that collects all the templates and preps them for sending to the flow editor. (And this path is the only clean way to get that stuff to the flow editor.)

I'm not 100% sure on the best way to provide an API call for this. Right now, by hook & crook, I call RED.registry.getFullNodeInfo and set the config and help fields. Having some call to set these cleanly would do the trick. (But I've been focused on how to work around this, not on exactly what and how to cleanly expose.)

Is there any appetite to facilitate this?

2

It occurred to me today that a clean way to integrate this from an API point of view would be to add an options parameter to RED.nodes.registerType. E.g., to inject script, template, and help one would use something like:

RED.nodes.registerType("my node", myNode, { script, template, help })

I haven't looked at what it would take to propagate the option values within Node-RED, but it seems like a pretty clean addition to the existing API.

1 Like
3

Hi @tve

I think you're on the right track here:

RED.nodes.registerType("my node", myNode, { script, template, help })

The devil will be in the detail, but this would be the cleanest API to start with.

As you know from digging through the code, the node loading logic has evolved over time and its a bit tangled, but this ought to be the right way to inject pieces into the node definition.

4

That might be quite limiting if you ever wanted to do further extensions later. Would it be better to do something like:

RED.nodes.registerType("my node", myNode, { nodeTemplate: { script, template, help } })

That way, you could further enhance the options in the future without fear of backwards compatibility. It also makes it clearer in the code what the data is for.

5

As I said, the devil will be in the detail.

The principle of using the existing options object to provide the additional details is good. What we call those additional properties can be bike shedded all day long :slight_smile:

6

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