zulip/static/js/message_util.js

58 lines
2.0 KiB
JavaScript
Raw Normal View History

2017-03-19 22:43:38 +01:00
exports.do_unread_count_updates = function do_unread_count_updates(messages) {
unread.process_loaded_messages(messages);
unread_ui.update_unread_counts();
resize.resize_page_components();
};
function add_messages(messages, msg_list, opts) {
2017-03-19 22:43:38 +01:00
if (!messages) {
return;
}
loading.destroy_indicator($('#page_loading_indicator'));
const render_info = msg_list.add_messages(messages, opts);
return render_info;
}
exports.message_has_link = function (message) {
return $(message.content).find(`a`).length > 0;
};
exports.message_has_image = function (message) {
return $(message.content).find(`.message_inline_image`).length > 0;
};
exports.message_has_attachment = function (message) {
return $(message.content).find(`a[href^='/user_uploads']`).length > 0;
};
exports.add_old_messages = function (messages, msg_list) {
return add_messages(messages, msg_list, {messages_are_new: false});
};
message list: Render new messages only after "newest" is found. If a user sends a message while the latest batch of messages are being fetched, the new message recieved from `server_events` gets displayed temporarily out of order (just after the the current batch of messages) for the current narrow. We could just discard the new message events if we havent recieved the last message i.e. when `found_newest` = False, since we would recieve them on furthur fetching of that narrow. But this would create another bug where the new messages sent while fetching the last batch of messages would not get rendered. Because, `found_newest` = True and we would no longer fetch messages for that narrow, thus the new messages would not get fetched and are also discarded from the events codepath. Thus to resolve both these bugs we use the following approach: * We do not add the new batch of messages for the current narrow while `has_found_newest` = False. * We store the latest message id which should be displayed at the bottom of the narrow in `fetch_status`. * Ideally `expected_max_message_id`'s value should be equal to the last item's id in `MessageListData`. * So the messages received while `has_found_newest` = False, will be fetched later and also the `expected_max_message_id` value gets updated. * And after fetching the last batch where `has_found_newest` = True, we would again fetch messages if the `expected_max_message_id` is greater than the last message's id found on fetching by refusing to update the server provided `has_found_newest` = True in `fetch_status`. Another benefit of not discarding the events is that the message gets processed not rendered i.e. we still get desktop notifications and unread count updates. Fixes #14017
2020-05-30 17:34:07 +02:00
exports.add_new_messages = function (messages, msg_list) {
message list: Render new messages only after "newest" is found. If a user sends a message while the latest batch of messages are being fetched, the new message recieved from `server_events` gets displayed temporarily out of order (just after the the current batch of messages) for the current narrow. We could just discard the new message events if we havent recieved the last message i.e. when `found_newest` = False, since we would recieve them on furthur fetching of that narrow. But this would create another bug where the new messages sent while fetching the last batch of messages would not get rendered. Because, `found_newest` = True and we would no longer fetch messages for that narrow, thus the new messages would not get fetched and are also discarded from the events codepath. Thus to resolve both these bugs we use the following approach: * We do not add the new batch of messages for the current narrow while `has_found_newest` = False. * We store the latest message id which should be displayed at the bottom of the narrow in `fetch_status`. * Ideally `expected_max_message_id`'s value should be equal to the last item's id in `MessageListData`. * So the messages received while `has_found_newest` = False, will be fetched later and also the `expected_max_message_id` value gets updated. * And after fetching the last batch where `has_found_newest` = True, we would again fetch messages if the `expected_max_message_id` is greater than the last message's id found on fetching by refusing to update the server provided `has_found_newest` = True in `fetch_status`. Another benefit of not discarding the events is that the message gets processed not rendered i.e. we still get desktop notifications and unread count updates. Fixes #14017
2020-05-30 17:34:07 +02:00
if (!msg_list.data.fetch_status.has_found_newest()) {
// We don't render newly received messages for the message list,
// if we haven't found the latest messages to be displayed in the
// narrow. Otherwise the new message would be rendered just after
// the previously fetched messages when that's inaccurate.
msg_list.data.fetch_status.update_expected_max_message_id(messages);
return;
}
return add_messages(messages, msg_list, {messages_are_new: true});
2017-03-19 22:43:38 +01:00
};
exports.get_messages_in_topic = function (stream_id, topic) {
// This function is very expensive since it searches
// all the messages. Please only use it in case of
// very rare events like topic edits. Its primary
// use case is the new experimental Recent Topics UI.
return message_list.all.all_messages().filter((x) => x.type === 'stream' &&
x.stream_id === stream_id &&
x.topic.toLowerCase() === topic.toLowerCase());
};
2017-03-19 22:43:38 +01:00
window.message_util = exports;