Refactor new message notification and frontend updates
Create a cleaner seperation between generating notifications and updating frontend conversation views. The former is now handled by `conversation.notify` while the latter is achieved by triggering an event on the conversation model, which will only be acted on if there are any views listening for it. Additionally, instead of re-fetching the entire message history, which is overkill, just add or update the new/modified message. This will help speed up the newmessage event handler and also help avoid unnecessary re-rendering when resolving key conflicts. // FREEBIE
This commit is contained in:
parent
055fc4f685
commit
a569e34b33
5 changed files with 53 additions and 57 deletions
|
@ -319,11 +319,8 @@
|
|||
|
||||
conversation.save().then(function() {
|
||||
message.save().then(function() {
|
||||
if (message.isIncoming()) {
|
||||
notifyConversation(message);
|
||||
} else {
|
||||
conversation.trigger('newmessages');
|
||||
}
|
||||
conversation.trigger('newmessage', message);
|
||||
conversation.notify(message);
|
||||
});
|
||||
});
|
||||
});
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue