Is there a use case for controlling the order nodes are registered in the Editor?

Developing Nodes
1

Is there a use case for controlling the order node types are registered in the Editor? in the server I already know there are some, but in the client (editor) I could not find any use cases for ordering registerType calls. I need to know to define the template for this code that is going to be generated by my cli.

image
image880Ă—398 52.3 KB

2

There is no harm. Some user may have some shared singleton code that needs to be initialised by the first registered node? but if your CLI sees this flag and changes up how it scaffolds code, then I see no harm. That said, I would likely create any singleton or shared code in a way that does not have any load-order dependency.

Keep up the good work!

1 Like
3

If I'm not mistaken: there is no order importance at the registerType level but the editor during the import will sort the config nodes so that they are initialized in order. This order is important especially for users.

1 Like
4

As far as I remember, @knolleary mentioned on this forum that nodes are being initialized tab by tab, from left to right. Thus you can dedicate the first & last tabs for nodes which need to be initialized before or after the rest of the nodes.

5

Actually I thought only the 1st tab is always initialised first and all other in the order they appear in the flows file?

6

This is server side - I think the OP is asking about editor /client side...

But - the flow file is written config nodes first (as they are effectively on a "hidden" tab - then each tab in displayed order. And that is also how it is read on startup.

7

Noted, thanks for that Dave. I'll actually save that into my Obsidian notebook this time - which I should have done before.

8

EDITED: I made both client and server apis very similar to reduce cognitive burden

I decided to allow the node author to define the order nodes are registered for both client and server-side entrypoints.

For example, If the node author writes a client-side entrypoint like the one shown below, and configures the cli to use it, then the configured file will be the source of truth for controlling the order nodes are registered in the client

import remoteServer from "./nodes/remote-server/client";
import yourNode from "./nodes/your-node/client";
import { registerType } from "./core/client";

export default async function () {
  try {
    await Promise.all([
      registerType("remote-server", remoteServer),
      registerType("your-node", yourNode),
    ]);
  } catch (error) {
    console.error("Error registering node types:", error);
  }
}

The same for the server-side entrypoint

import YourNode from "./nodes/your-node/server";
import RemoteServerConfigNode from "./nodes/remote-server/server";
import { registerType } from "./core/server";

export default async function (RED: any) {
  try {
    await registerType(RED, "remote-server", RemoteServerConfigNode);
    await registerType(RED, "your-node", YourNode);
  } catch (error) {
    console.error("Error registering node types:", error);
  }
}

These entrypoints are optional, and if not provided

  • Server: By default, node types are registered sequentially , in alphabetical order
  • Client: By default, node types are registered in parallel , also following the alphabetical order

You can see the experiment in this repo GitHub - AllanOricil/node-red-vue-inputs-experiments: Write Node-RED nodes using Vue