Hi @citkane
The repackaging in 0.20 is just the first step to get the components of node-red separated. Making the editor-client code more reusable is a longer term goal but we're not there yet. One of the challenges we have is keeping the client reasonable agnostic of any particular toolkit; I know there is interest from some in embedding Node-RED as an Ember component as well. Also, I lack the in depth experience of these toolkits to instinctively know what we need to provide in the project to best support their use. So this is certainly an area I'm keen to get more feedback on.
The index.msi template gives you the basic structure the code expects to exist - including what JavaScript needs loading in. You'll note it contains some very generic ID's such as header. One task prior to 1.0 will be to tidy up and namespace lots of those ids. Doing that will break anyone who has created a custom node-red theme, so it needs doing with care, but it is the sort of breaking change we can only make prior to 1.0.
Aside from the 3rd party libs we use (all the vendor/... stuff), the Node-RED editor is provided by two JavaScript files.
public/red/red.min.js is the bulk of the editor code. It defines a global called RED and everything hangs under that.
public/red/main.min.js is the code that bootstraps the editor in the page by calling:
RED.init({
apiRootUrl: ""
});
By default, the editor makes all requests relative to the url the editor has been loaded from, because that's how it has always been with the tight coupling of the editor and runtime.
When we started the split work, one use case was to be able to host the editor files on a static file server, such as Amazon S3. In that scenario, the editor needed to know where to send its admin api calls.
As a step towards satisfying that use case, I added the apiRootUrl option above. It defines the root url the editor uses to access the runtime api. Setting it to something like https://example.com/red would cause the editor to load the current flow definition from https://example.com/red/flows. I need to emphasise the in theory bit here - it hasn't been fully tested to verify it works across the board; I suspect the way some custom nodes have been written could mean they trip up on this. As I said, this was just one step in that direction to see how much closer it got us.
There are other potential use cases that need more consideration. For example, where the S3 hosted editor gets pointed at one apiRootUrl to log the user in - and once logged in, the editor is automatically redirected to a different apiRootUrl for that user's own instance.
Bit of a digression there... but the point is, if you load in red.min.js (and the other vendor prereqs) then you can call RED.init({}) however you want.
And there may well be other things we could do to make this easier. For example, what if the RED.init() call also let you pass in the id of an element on the page into which the editor should be built. If it did that, we'd be able to strip out much of the content from index.msi and have it generated by the code. Getting that to work would be a big step towards enabling the editor to be embedded more arbitrarily in the page. This is where it would be good to get feedback.
So, bit of a ramble there, and probably not the answer you were hoping for. It's an area I'm keen to do more on - albeit alongside all the other high priority roadmap items I'm splitting my time between.
If you have an ideas or suggestions - then please do let us know. The dev channel on slack is a good place if you (or anyone reading) want to chat around these topics.
