zulip/static/js/fetch_status.js

85 lines
2.2 KiB
JavaScript
Raw Normal View History

const FetchStatus = function () {
const self = {};
let loading_older = false;
let loading_newer = false;
let found_oldest = false;
let found_newest = false;
let history_limited = 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
let expected_max_message_id = 0;
function max_id_for_messages(messages) {
let max_id = 0;
for (const msg of messages) {
max_id = Math.max(max_id, msg.id);
}
return max_id;
}
self.start_older_batch = function (opts) {
loading_older = true;
if (opts.update_loading_indicator) {
message_scroll.show_loading_older();
}
};
self.finish_older_batch = function (opts) {
loading_older = false;
found_oldest = opts.found_oldest;
history_limited = opts.history_limited;
if (opts.update_loading_indicator) {
message_scroll.hide_loading_older();
}
};
self.can_load_older_messages = function () {
return !loading_older && !found_oldest;
};
self.has_found_oldest = function () {
return found_oldest;
};
self.history_limited = function () {
return history_limited;
};
self.start_newer_batch = function (opts) {
loading_newer = true;
if (opts.update_loading_indicator) {
message_scroll.show_loading_newer();
}
};
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
self.finish_newer_batch = function (messages, opts) {
const found_max_message_id = max_id_for_messages(messages);
if (opts.found_newest && expected_max_message_id > found_max_message_id) {
opts.found_newest = false;
}
loading_newer = false;
found_newest = opts.found_newest;
if (opts.update_loading_indicator) {
message_scroll.hide_loading_newer();
}
};
self.can_load_newer_messages = function () {
return !loading_newer && !found_newest;
};
2018-05-03 19:44:11 +02:00
self.has_found_newest = function () {
return found_newest;
};
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
self.update_expected_max_message_id = function (messages) {
expected_max_message_id = Math.max(expected_max_message_id,
max_id_for_messages(messages));
};
return self;
};
module.exports = FetchStatus;
window.FetchStatus = FetchStatus;