zulip/frontend_tests/node_tests/fetch_status.js

184 lines
4.0 KiB
JavaScript
Raw Normal View History

"use strict";
const {strict: assert} = require("assert");
const rewiremock = require("rewiremock/node");
const {zrequire} = require("../zjsunit/namespace");
const {run_test} = require("../zjsunit/test");
rewiremock("../../static/js/message_scroll").with({
hide_loading_older: () => {},
show_loading_older: () => {},
hide_loading_newer: () => {},
show_loading_newer: () => {},
});
rewiremock.enable();
const {FetchStatus} = zrequire("fetch_status");
let fetch_status = new FetchStatus();
function reset() {
fetch_status = new FetchStatus();
}
function can_load_newer() {
assert.equal(fetch_status.can_load_newer_messages(), true);
}
function blocked_newer() {
assert.equal(fetch_status.can_load_newer_messages(), false);
}
function can_load_older() {
assert.equal(fetch_status.can_load_older_messages(), true);
}
function blocked_older() {
assert.equal(fetch_status.can_load_older_messages(), false);
}
function has_found_oldest() {
assert.equal(fetch_status.has_found_oldest(), true);
}
function has_not_found_oldest() {
assert.equal(fetch_status.has_found_oldest(), false);
}
2018-05-03 19:44:11 +02:00
function has_found_newest() {
assert.equal(fetch_status.has_found_newest(), true);
}
function has_not_found_newest() {
assert.equal(fetch_status.has_found_newest(), false);
}
function can_load_history() {
assert.equal(fetch_status.history_limited(), false);
}
function blocked_history() {
assert.equal(fetch_status.history_limited(), true);
}
run_test("basics", () => {
reset();
fetch_status.start_newer_batch({update_loading_indicator: false});
fetch_status.start_older_batch({update_loading_indicator: false});
2018-03-16 14:15:30 +01:00
blocked_newer();
blocked_older();
can_load_history();
has_not_found_oldest();
2018-05-03 19:44:11 +02:00
has_not_found_newest();
2018-03-16 14:15:30 +01:00
let data = {
update_loading_indicator: false,
2018-03-16 14:15:30 +01:00
found_oldest: true,
found_newest: true,
history_limited: true,
};
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
fetch_status.finish_newer_batch([], data);
fetch_status.finish_older_batch(data);
2018-03-16 14:15:30 +01:00
has_found_oldest();
2018-05-03 19:44:11 +02:00
has_found_newest();
2018-03-16 14:15:30 +01:00
blocked_newer();
blocked_older();
blocked_history();
2018-03-16 14:15:30 +01:00
reset();
fetch_status.start_newer_batch({update_loading_indicator: true});
fetch_status.start_older_batch({update_loading_indicator: true});
2018-03-16 14:15:30 +01:00
blocked_newer();
blocked_older();
can_load_history();
2018-03-16 14:15:30 +01:00
data = {
update_loading_indicator: false,
2018-03-16 14:15:30 +01:00
found_oldest: false,
found_newest: false,
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
fetch_status.finish_newer_batch([], data);
fetch_status.finish_older_batch(data);
2018-03-16 14:15:30 +01:00
can_load_older();
can_load_newer();
can_load_history();
2018-03-16 14:15:30 +01:00
reset();
can_load_older();
fetch_status.start_older_batch({update_loading_indicator: false});
blocked_older();
can_load_newer();
can_load_history();
fetch_status.finish_older_batch({
update_loading_indicator: true,
found_oldest: false,
history_limited: false,
});
can_load_older();
can_load_newer();
can_load_history();
fetch_status.start_older_batch({update_loading_indicator: true});
blocked_older();
can_load_newer();
can_load_history();
fetch_status.finish_older_batch({
update_loading_indicator: true,
found_oldest: true,
history_limited: true,
});
blocked_older();
can_load_newer();
blocked_history();
reset();
can_load_older();
can_load_newer();
fetch_status.start_newer_batch({update_loading_indicator: false});
can_load_older();
blocked_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
fetch_status.finish_newer_batch([], {
update_loading_indicator: true,
found_newest: false,
});
can_load_older();
can_load_newer();
fetch_status.start_newer_batch({update_loading_indicator: true});
can_load_older();
blocked_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
fetch_status.finish_newer_batch([], {
update_loading_indicator: true,
found_newest: true,
});
can_load_older();
blocked_newer();
});
rewiremock.disable();