Multiple instance module. Scope for a noob.

[birdabirda]

First up, I’m new to both javascript and MM, so if you find yourself thinking, “well, surely he’s taken care of X” or “having tried X already…” —no, please assume the worst about my knowledge base. ••• There’s nothing like looking at a Magic Mirror with an empty edge to fire the imagination. Thanks in advance for your patience.

Q1:
I need my module to be able to handle multiple instances. I have read its possible to duplicate and rename everything, but I’d like it to work… “natively”. If my module’s programming is designed for it, a module can have multiple instances running from the same Module directory, just with different entries and options in config.js, yes?

Q2:
My node_helper.js really runs the show. I read in the docs that I only get one helper, so it now registers socket communication by module identifier. When it has content ready, it sends the corresponding id back with it, so other instances can ignore it. Does this sound like the right approach?

So I’ll only have one helper. Will I also “only have one module_name_here.js”? I naïvely just added a few global variables outside Module.register and they seem to be colliding between instances. I don’t really understand the MM magic and Module.register functionality under the hood.
Q3: If I use the js ‘this’ keyword inside that .register, what does ‘this’ refer to, precisely?
Q4: Where should I declare variables for one-instance scope?
Q5: Or should I store them all together, and explicitly associate returning helper payloads to an instance identifier inside module.js just like I do to module payloads inside node_helper.js?

[MMRIZE]

@birdabirda
A1:
Yes, you can. but pay heed to these;

• Be careful when your modules(instances) access the resource(e.g. HTML Element, sounds, sensors,…_ The competes for the same resources would make trouble.
• You need to manage the communications with node_helper from your instances. Instances will share the node_helper at same time, so your socketNotfication or resources of node_helper might have to be controlled by the session per instance.

A2:
Right. 1:M messaging channel tricks might be needed.

A3:
Your module object itself. it has many methods and members. It would be created by MM framework with the definition from your code. Then it would play its role in the MM framework.

A4:
All variables in the `Module.register(“YOURMODULE”,{ … }) will be scoped. They will not be shared unless you refer or link them to global/window scope.

A5:
You might need instance id as payload member on using socketNotification to catch which instance sends this socketNotification to node_helper. Vice versa, instance id might be also needed when node_helper sends socketNotification, to explicit which instance should be aware. Between module and node_helper unlike among modules, only simple basic data type would be transferrable, so you cannot use callback or ‘complex’ class object to make the communication easy.

[MMRIZE]

@birdabirda
ADD to A5.

However, there are some tricks that can be used between node_helper and your instance to make dedicated communication.

• HTTP connection : your node_helper can serve its own web server that can provide URL endpoints for request/response methods. Your front-end module instance could access the dedicated URL.
• websocket or similar technics.

[sdetweil]

@birdabirda the config.js info is provided to the modulename.js instance. this is object oriented programming

each unique instance is pointed to by ‘this’.

think of node_helper as a server. .
but it’s responses are broadcast to ALL instances.

so each instance needs to pass it’s
identifier as part of the data on each sendsocketNotifocation

then the node helper has to keep track of that and send that back as part of the response

then each modulename instance has to check to see if the response is for them.

you can store the data in a hash by
instance id.