Marak/buddypond

Tracking: Refactor message processing and buddylist profile to event emitters

Marak opened this issue · 1 comments

Marak commented

In order to reduce complexity of code and make message and buddylist easier to work with, we will refactor message processing and buddylist profile into Event Emitter.

desktop.on() and desktop.emit() both already exist, so we will utilize these. This shouldn't be too much effort, the majority of the code is already decoupled and prepped for this.

The syntax looks something like:

// all messages
desktop.on('messages::message', 'do-stuff', fn)

// new messages that the desktop hasn't seen yet
desktop.on('messages::newmessage', 'do-stuff', fn)

// new incoming message from buddy
desktop.on('profile::buddy::newmessage', 'do-stuff', fn)

// buddy signs online
desktop.on('profile::buddy::in', 'do-stuff', fn)

// buddy signs offline
desktop.on('profile::buddy::out', 'do-stuff', fn)

// buddy has no status update
desktop.on('profile::buddy::status', 'do-stuff', fn)

// buddy is starting incoming voice call
desktop.on('profile::buddy::calling', 'do-stuff', fn)
Marak commented

Was able to implement all above profile::buddy::* events.

Combined pond and buddy message rendering into common App.Messages

Choose to not implement message::* events at this time. Is currently not required and there is benefit in keeping main message processing as async with callback vs EE with no callback. Can revisit if needed.

Overall looking very good. Code is much cleaner and we were able to remove duplicate message rendering code.

Closing for now. Can re-open to track regressions from refactor.