@drmibell Agree; in no way should we make it more difficult. Whatever we do should be backwards-compatible. To be clear, in no way am I suggesting that we impose a different workflow upon Node developers. I’m proposing we open the door to different workflows, and we do that by supporting optional configuration properties.
1 Like
Yes. In addition to backward compatibility, I think a key point is we would like to make it easier to organise node front end code & templates in separate files, and include additional files like libraries and css, without the need to introduce new tools. That’s the reason for paths in the package.json file in @knolleary sketch. That said, if you want to use new tools, like a compiler/transpiler and bundler, for example to use newer versions of JS or improve performance, you should be welcome to. Just point the paths to the bundles.
I think that’s what I’m suggesting…
1 Like
Another point I’d like to raise, as it’s relevant to the discussion: it’s not so easy to share code between Nodes.
On the backend, you’re welcome to subclass Nodes (though this is not documented anywhere), but on the frontend, how can we keep it DRY?
Essentially, the frontend is just providing a configuration object (containing some functions), and some markup. How can we share the config object (in whole or in part)? How can we share the templates?
(Since all templates are present in the editor’s DOM, we should be able to reference them, anyway…)
Somewhat related…
In a recent project I needed to get the ‘schema’ of a Node, that is, its properties and defaults, as well as the icon and how the label was generated. I used this to create a flow programmatically with my own UI, and display nodes and their status myself. I didn’t need to display the configuration dialogs, so the onEditPrepare and other methods for dialogs were not needed from what I recall.
To do this, I had to ‘borrow’ some interesting code from the flow library that executes front end code located in an html <script> tag in a sandbox that supplied stubs for front end registerType, node, and $ functions. It works, sort of, but struck me as something we might want to make easier for API clients to do.
