Does a sidebar node has a server side instance?

Developing Nodes
1

Hi folks,

It seems like I am somehow misinterpreting how sidebar nodes work :weary:
My server side part is never called:

function XtermSidebarNode(config) {
   RED.nodes.createNode(this, config);
   console.log("THIS TEXT NEVER APPEARS IN THE LOG ;-( ")
}
RED.nodes.registerType("xterm_sidebar", XtermSidebarNode);

I 'suppose' that is not normal (??), because when I look at the node-red-contrib-contextbrowser node, the guy has added some functionality on server-side ...

But then I don't understand where the sidebar node 'should' be created. Because a user never explicit adds such a node to it's flow (like you do with non-sidebar nodes). Instead the sidebar tabsheet is added dynamically as soon as the node is added to the pallette in the flow editor:

<script type="text/javascript">  
(function() {
    RED.nodes.registerType('xterm_sidebar',{
        category: 'config',
        exclusive: true,,
        defaults: {
            ...
        },
        onpaletteadd: function () {
            RED.sidebar.addTab({
                id: "sidebar-xterm",
                label: "terminal_xterm",
                name: "Terminal",
                content: content,
                closeable: true,
                disableOnEdit: true,
                iconClass: "fa fa-terminal",
            });
        },
        onpaletteadd: function () {
             // HERE I ALSO NEVER ARRIVE ...
        }
    });
})();
</script>

Should I create the instance by myself somehow? Or is there perhaps never an instance?
Would be nice if anybody could explain me a bit in detail how this mechanism works.

Thanks !!
Bart

2

As I've said, there is no established pattern for this and it is a whole area that hasn't been documented.

There is no such thing as a "sidebar node". There are flow nodes and config nodes. The contextbrowser module registers a config node to the palette because that is the only way to get anything loaded by the runtime and into the editor. It's a hack that is required because we don't provide any alternative. And in the contextbrowser case, the config node it registers exists only as a means to deliver code to the editor. The config node is never added to a flow, nor does it do anything in the runtime.

Your case is different. You want to use the config node in order to store settings in the flow related to your sidebar. As I mentioned, the only example I know for that is Node-RED Dashboard and its ui_base node.

That node has a function called ensureDashboardNode that does the work to add a new ui_base node if its needed. That function is then called at various points when the user interacts with the dashboard sidebar. As I mentioned before, it has to deal with various edge cases, such as the user importing a second ui_base node, or explicitly deleting it from the Config node sidebar.

3

Yes that was indeed a good pointer in our last conversation!
I have meanwhile added a similar function to my node, to register a config node & set the workspace as dirty & check every time that nobody has deleted the config node behind my back. That all works nice, although I am still 'very' aware of the fact that this is not documented and not a public API...

Ah that was my mistake. I had created both a sidebar-node (html & js file) AND a config-node (html & js file). But now I understand it works like this:

  1. I only need to register a config node
  2. As soon as the config node is added to the palette, it will add a tabsheet to the sidebar.
  3. Inside the sidebar code I create an instance of that config node (like I already do).

That would simplify things ...