Does node_helper know if all module instances are already started?

[sdetweil]

@Adam-2 what difference does it make?

I have one module that does graphing of data from a csv file, retrieved from an internet source.

the first request starts the get
and all others queue up behind it.
when the file is retrieved the node helper threads are woken up and each processes the file uniquely and sends that modules data back.

but the answer to your question is No
the node helper doesn’t know anything about the timing of the modules. some could be local, and some could be on remote machines, on the same network or across the internet.

treat each notification as a request/response

[Adam 2]

@sdetweil So node_helper would never know if all possible module instances are loaded. If it can be assumed that module instances are started in the order defined in config file I could set some config parameter for the first instance with number of modules that will be setup. This can be send to node_helper and then node_helper can wait until it counts proper number of started modules because each of them will notify. After that it can assume that the display is in “stable” state and it is possible to send some new data to display and know that it will be displayed for sure because proper module is already started. The drawback is that I have to count all module instances and introduce some specific config parameter for first of them.

[sdetweil]

@Adam-2 I still think that design is bad.

I can open another browser to mm tomorrow, and you will have another config.js count of modules firing requests.

why do you think that you need to know about the state of the viewers?

[MMRIZE]

• node_helper cannot know other module’s status directly. It lies on another layer of the architecture.
• It sounds somewhat weird node_helper has to interact with other modules. Generally A module has to interact with other modules. node_helper is a helper for a specific module to handle things out of MM/browser front level.
• Module notification DOM_OBJECTS_CREATED is regarded as a signal of ‘all modules are displayed’. You can deliver socketNotification to your node_helper to start your job when this notification is caught.

[Adam 2]

@MMRIZE My node_helper does not interact with other modules. It interacts only with many instances of my module, because there is only one node_helper even if module has multiple instances. It looks that DOM_OBJECTS_CREATED notification is a good way to know that each module instance is already started. However, as it is received by the module, in fact each instance will pass that info to node_helper while only one is enough. However, this is not a huge issue. After this is passed to node_helper I can be sure that module instances are ready to display data through API provided by the node_helper. Moreover, I can be sure that all individual configs for each module are already loaded.

[MMRIZE]

@Adam-2
You can assign and deliver some instanceID to distinguish which instance of your module transfers this notification.
Or you can use Promise.race()(to confirm first socketNotification coming from any instance) or Promise.allSettled()(to confirm entire socketNotifications delivered from all instances even though fail or not) in node_helper to check socketNotifications receiving. (Anyway, you need to check how many instances there exist before promise racing)

[sdetweil]

@MMRIZE and config. is accessible in node_helper, so one could count the module instances

[Adam 2]

@sdetweil Is config file accessible from the node_helper? I thought that only core module files can access it and have to send it back to node_helper if needed.

[sdetweil]

@Adam-2 see the global config var in the node_helper

its EVERYTHING in config.js

[Adam 2]

@sdetweil I’m searching the documentation and cannot find this global config var. How exactly can I access it?