Marak / buddypond

Cloud OS and Instant Messenger
https://buddypond.com
Other
153 stars 17 forks source link

Tracking: Refactor message processing and buddylist profile to event emitters #76

Closed Marak closed 2 years ago

Marak commented 2 years ago

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 2 years ago

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.