Idea: init onStateChange() in onReady() and not in class contructor
Acgua opened this issue · 6 comments
Currently, onStateChange() is initialized in the adapter class constructor:
this.on('stateChange', this.onStateChange.bind(this));
Suggestion to discuss for the adapter template:
Initialize onStateChange() in onReady() as a code line, and not in the class constructor.
Use Case: onStateChange() should only be active once adapter settings have been successfully verified in onReady(), and/or other stuff happened before.
Also, I cannot think of any use case where onStateChange() should be ready already without having (partly) processed onReady().
But I am rather a beginner of adapter development, and I guess there were very good reasons why onStateChange() is initialized in the class already, so would like to discuss if my idea makes sense at all.
@Apollon77 @foxriver76 are state changes even emitted before "ready"?
If not, I'd prefer to keep it as is for consistency.
The registration of the state change handler is not the topic. By just registering the handler nothing will happen so it is not needed to move this into the ready.
What should be in the ready handler after anything is initialized is the subscribeState command ;-)
Ps: formally only autosubscribes are relevant for the above case but these are not widely used ;-)
But when I remember correctly also state cha he's should not be emitted before ready is called but I would need to check controller code for that when on a computer.
What should be in the ready handler after anything is initialized is the subscribeState command ;-)
Ahhh, my fault, sorry :-) For some unknown reason I forgot about subscribeState, so all is good.
Thank you very much for your such swift responses @AlCalzone and @Apollon77
I will close this issue.
OK, Is was involved into discussion too. I too missed the subscribe. Of course as long as nothing is subscribed, nothing should be signalled.
For autosubscribes it would also be relevant that they are NOT submitted while onReady has not yet completed. I'm not sure biut because of asynchronity a parallel delivery would be possible unless blocked within adapter core code.
In worst case for auto subscribes you can have a code flag set in on ready on the "right" timepoint and is checked in the state change handler and ignore anything before it is set. That would be an easy way to work around if there might be edge cases.