Add Input Widget Type / Decrease repeat code in HTML file

I have a set of node types which share editor config functionality. As such, I have a large amount of repeated code in each node type's HTML file, primarily residing in OnEditPrepare.

I'd like these nodes to share the functionality from a common source. The functionality is complex and deals directly with the local node-input fields within that node therefore I cannot use simply getJson to call remote functions.

I had the idea of creating a new input widget that could be used between many node types with self-contained functionality, in the same manner is the current searchBox or TypedInput widget. I've been looking at the node-RED source and it seems this is not likely to be possible so therefore am open to alternative solutions.

Any suggestions are appreciated.

Well the first step would be to move as much as possible out of the oneditprepare function into their own functions. As in node-red-contrib-uibuilder/uibuilder.html at vNext · TotallyInformation/node-red-contrib-uibuilder (github.com).

The next step might be to move the common functions into a separate libary and reference that as a link in your node's html files. However, that has the downside of needing you to be careful about name clashes since you would effectively be creating functions in the window context. You would want to choose a sensible prefix unlikely to clash with anyone else's.

Alternatively, you could use a build step when creating your node. You can see an example of this in the vNext branch of uibuilder. TotallyInformation/node-red-contrib-uibuilder at vNext (github.com). Check out the src folder and the scripts defined in package.json. In that way, you could have your common code in a separate file that you insert into the main js section for each node's html file. The build step would do that for you and you can use a watch function to continuously rebuild as you make changes.

Oh, and of course, you can use API's defined in your node's .js file, passing in the appropriate data. That way, you have common code at the back-end. That works well as long as you aren't trying to handle massive data which is unlikely in an editor panel.