zulip/static/js/message_util.js

83 lines
2.8 KiB
JavaScript
Raw Normal View History

import $ from "jquery";
import * as loading from "./loading";
import * as message_list from "./message_list";
import * as message_store from "./message_store";
import * as resize from "./resize";
import * as unread from "./unread";
import * as unread_ui from "./unread_ui";
export function do_unread_count_updates(messages) {
2017-03-19 22:43:38 +01:00
unread.process_loaded_messages(messages);
unread_ui.update_unread_counts();
resize.resize_page_components();
}
2017-03-19 22:43:38 +01:00
function add_messages(messages, msg_list, opts) {
2017-03-19 22:43:38 +01:00
if (!messages) {
return undefined;
2017-03-19 22:43:38 +01:00
}
loading.destroy_indicator($("#page_loading_indicator"));
2017-03-19 22:43:38 +01:00
const render_info = msg_list.add_messages(messages, opts);
return render_info;
}
export function add_old_messages(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
export function add_new_messages(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 undefined;
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
}
return add_messages(messages, msg_list, {messages_are_new: true});
}
2017-03-19 22:43:38 +01:00
export function get_messages_in_topic(stream_id, topic) {
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
export function get_max_message_id_in_stream(stream_id) {
let max_message_id = 0;
for (const msg of message_list.all.all_messages()) {
if (msg.type === "stream" && msg.stream_id === stream_id && msg.id > max_message_id) {
max_message_id = msg.id;
}
}
return max_message_id;
}
export function get_topics_for_message_ids(message_ids) {
const topics = new Map(); // key = stream_id:topic
for (const msg_id of message_ids) {
// message_store still has data on deleted messages when this runs.
const message = message_store.get(msg_id);
if (message === undefined) {
// We may not have the deleted message cached locally in
// message_store; if so, we can just skip processing it.
continue;
}
if (message.type === "stream") {
// Create unique keys for stream_id and topic.
const topic_key = message.stream_id + ":" + message.topic;
topics.set(topic_key, [message.stream_id, message.topic]);
}
}
return topics;
}