You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been inspecting the code and I think I figured out how it works. The _synchronize function is building up some kind of queue with promises right? Why do you use this instead of creating an actual queue that s fetches commands when the previous one is done? This would make the code way more readable.
Hi. Thank you very much for looking into node-milight-promise and your feedback!
The basic rationale behind using synchronized promises rather than a message queue is to have more flexibility with respect to setting the synchronization points in the code. Actually, _synchronize is used for the socket initialialization (am I ready to send?), the sendCommand, the Socket Closure (close if there are no pending promises), and it is optionally used to synchronize multiple Milight instances.
Needless to say the code has grown over time and things could be simplified for sure using an approach similiar to what you're suggesting. At a frist glance, I'd prefer a queue of functions (or promises), however. I need to look into this in more detail, however, to decide on the best approach. Some refactoring is on my todo list list anyway also to modernize the code with respect to the advancements of Javascript.
I've been inspecting the code and I think I figured out how it works. The
_synchronize
function is building up some kind of queue with promises right? Why do you use this instead of creating an actual queue that s fetches commands when the previous one is done? This would make the code way more readable.So something like:
Fiddle here: https://jsfiddle.net/wgogdb12/
The text was updated successfully, but these errors were encountered: