zulip/static/js/message_flags.js

136 lines
3.6 KiB
JavaScript
Raw Normal View History

var message_flags = (function () {
var exports = {};
Simplify/unify starring messages from the frontend. We now do all of the main logic for starring/unstarring a message in `message_flags.toggle_starred`: * mark the message as read (just in case) * update the UI (i.e. the green star in the message) * update the server The calling code in both the click handler and the hotkey handler remains simple--they just handle minor details like finding the message and clearing popovers. For updating the server, we now call the new `send_flag_update` helper. And we continue to delegate some of the logic to `ui.update_starred`, but we remove some code there that's now pushed up to `message_flags.toggle_starred`. This change should be mostly transparent to users, but it does remove some inconsistent behaviors between the click handler and the hotkey handler. Before this change, the click handler was more aggressive about updating the UI and marking the message as read. For people using the "*" key to star/unstar, they probably would only have noticed different behavior on a slow connection or in an edge case scenario where only half of the message was onscreen. More importantly, by simplifying how we talk to the server, this eliminated up to a one-second lag due to the debounce logic in the batch_updater code. The complicated debounce logic is only really needed for batch-updating "read" messages, and it was overkill and sluggish for starring messages. Last but not least, we add defensive code for the local echo case. (Users have to wait till the message gets acked to star it.)
2017-12-16 13:33:54 +01:00
function send_flag_update(message, flag, op) {
channel.post({
url: '/json/messages/flags',
idempotent: true,
data: {
messages: JSON.stringify([message.id]),
flag: flag,
op: op,
},
});
}
exports.send_read = (function () {
var queue = [];
var on_success;
var start;
function server_request() {
// Wait for server IDs before sending flags
var real_msgs = _.filter(queue, function (msg) {
return !msg.locally_echoed;
});
var real_msg_ids = _.map(real_msgs, function (msg) {
return msg.id;
});
if (real_msg_ids.length === 0) {
setTimeout(start, 100);
return;
}
// We have some real IDs. If there are any left in the queue when this
// call finishes, they will be handled in the success callback.
channel.post({
url: '/json/messages/flags',
idempotent: true,
data: {messages: JSON.stringify(real_msg_ids),
op: 'add',
flag: 'read'},
success: on_success,
});
}
start = _.throttle(server_request, 1000);
on_success = function on_success(data) {
if (data === undefined || data.messages === undefined) {
return;
}
queue = _.filter(queue, function (message) {
return data.messages.indexOf(message.id) === -1;
});
if (queue.length > 0) {
start();
}
};
function add(messages) {
queue = queue.concat(messages);
start();
}
return add;
}());
exports.save_collapsed = function (message) {
send_flag_update(message, 'collapsed', 'add');
};
exports.save_uncollapsed = function (message) {
send_flag_update(message, 'collapsed', 'remove');
};
// This updates the state of the starred flag in local data
// structures, and triggers a UI rerender.
exports.update_starred_flag = function (message_id, new_value) {
var message = message_store.get(message_id);
if (message === undefined) {
// If we don't have the message locally, do nothing; if later
// we fetch it, it'll come with the correct `starred` state.
return;
}
message.starred = new_value;
ui.update_starred_view(message_id, new_value);
};
exports.toggle_starred_and_update_server = function (message) {
Simplify/unify starring messages from the frontend. We now do all of the main logic for starring/unstarring a message in `message_flags.toggle_starred`: * mark the message as read (just in case) * update the UI (i.e. the green star in the message) * update the server The calling code in both the click handler and the hotkey handler remains simple--they just handle minor details like finding the message and clearing popovers. For updating the server, we now call the new `send_flag_update` helper. And we continue to delegate some of the logic to `ui.update_starred`, but we remove some code there that's now pushed up to `message_flags.toggle_starred`. This change should be mostly transparent to users, but it does remove some inconsistent behaviors between the click handler and the hotkey handler. Before this change, the click handler was more aggressive about updating the UI and marking the message as read. For people using the "*" key to star/unstar, they probably would only have noticed different behavior on a slow connection or in an edge case scenario where only half of the message was onscreen. More importantly, by simplifying how we talk to the server, this eliminated up to a one-second lag due to the debounce logic in the batch_updater code. The complicated debounce logic is only really needed for batch-updating "read" messages, and it was overkill and sluggish for starring messages. Last but not least, we add defensive code for the local echo case. (Users have to wait till the message gets acked to star it.)
2017-12-16 13:33:54 +01:00
if (message.locally_echoed) {
// This is defensive code for when you hit the "*" key
// before we get a server ack. It's rare that somebody
// can star this quickly, and we don't have a good way
// to tell the server which message was starred.
return;
}
message.starred = !message.starred;
unread_ops.notify_server_message_read(message);
ui.update_starred_view(message.id, message.starred);
Simplify/unify starring messages from the frontend. We now do all of the main logic for starring/unstarring a message in `message_flags.toggle_starred`: * mark the message as read (just in case) * update the UI (i.e. the green star in the message) * update the server The calling code in both the click handler and the hotkey handler remains simple--they just handle minor details like finding the message and clearing popovers. For updating the server, we now call the new `send_flag_update` helper. And we continue to delegate some of the logic to `ui.update_starred`, but we remove some code there that's now pushed up to `message_flags.toggle_starred`. This change should be mostly transparent to users, but it does remove some inconsistent behaviors between the click handler and the hotkey handler. Before this change, the click handler was more aggressive about updating the UI and marking the message as read. For people using the "*" key to star/unstar, they probably would only have noticed different behavior on a slow connection or in an edge case scenario where only half of the message was onscreen. More importantly, by simplifying how we talk to the server, this eliminated up to a one-second lag due to the debounce logic in the batch_updater code. The complicated debounce logic is only really needed for batch-updating "read" messages, and it was overkill and sluggish for starring messages. Last but not least, we add defensive code for the local echo case. (Users have to wait till the message gets acked to star it.)
2017-12-16 13:33:54 +01:00
if (message.starred) {
send_flag_update(message, 'starred', 'add');
starred_messages.add([message.id]);
} else {
Simplify/unify starring messages from the frontend. We now do all of the main logic for starring/unstarring a message in `message_flags.toggle_starred`: * mark the message as read (just in case) * update the UI (i.e. the green star in the message) * update the server The calling code in both the click handler and the hotkey handler remains simple--they just handle minor details like finding the message and clearing popovers. For updating the server, we now call the new `send_flag_update` helper. And we continue to delegate some of the logic to `ui.update_starred`, but we remove some code there that's now pushed up to `message_flags.toggle_starred`. This change should be mostly transparent to users, but it does remove some inconsistent behaviors between the click handler and the hotkey handler. Before this change, the click handler was more aggressive about updating the UI and marking the message as read. For people using the "*" key to star/unstar, they probably would only have noticed different behavior on a slow connection or in an edge case scenario where only half of the message was onscreen. More importantly, by simplifying how we talk to the server, this eliminated up to a one-second lag due to the debounce logic in the batch_updater code. The complicated debounce logic is only really needed for batch-updating "read" messages, and it was overkill and sluggish for starring messages. Last but not least, we add defensive code for the local echo case. (Users have to wait till the message gets acked to star it.)
2017-12-16 13:33:54 +01:00
send_flag_update(message, 'starred', 'remove');
starred_messages.remove([message.id]);
}
};
exports.unstar_all_messages = function () {
var starred_msg_ids = starred_messages.get_starred_msg_ids();
channel.post({
url: '/json/messages/flags',
idempotent: true,
data: {
messages: JSON.stringify(starred_msg_ids),
flag: 'starred',
op: 'remove',
},
});
};
return exports;
}());
if (typeof module !== 'undefined') {
module.exports = message_flags;
}
window.message_flags = message_flags;