Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/web/tests/pm_list.test.js

41 lines
1.1 KiB
JavaScript
Raw Normal View History

js: Add "use strict" directive to CommonJS files. ES and TypeScript modules are strict by default and don’t need this directive. ESLint will remind us to add it to new CommonJS files and remove it from ES and TypeScript modules. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-08-01 03:43:15 +02:00
"use strict";
zjsunit: Deglobalize assert. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-11-30 23:46:45 +01:00
const {strict: assert} = require("assert");
node_tests: Move to web/tests. This lets us simplify the long-ish ‘../../static/js’ paths, and will remove the need for the ‘zrequire’ wrapper. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2023-02-22 23:04:10 +01:00
const {zrequire} = require("./lib/namespace");
const {run_test} = require("./lib/test");
const $ = require("./lib/zjquery");
Use zjquery to test pm_list.js. We now stub templates.render() to see what data gets passed in to the template, rather than using jQuery to inspect the DOM that gets created. This changes the nature of the test to be less about integration with the templating layer and more about how we pass data into the template. To compensate, we add more assertions to the relevant test in templates.js.
2017-05-31 01:32:55 +02:00
node tests: Avoid narrow_state mocking in pm_list* tests. We now use narrow_state directly in pm_list and pm_list_data tests, rather than mocking it with our `override*` helpers. In some places I use an actual Filter() object, but in places where the only testing concern is that the active is narrow, I use a stub value. We will continue to mock narrow_state in most places. In addition to avoiding test-setup complications, we want to avoid incidental line coverage on narrow_state that only indirectly validates its behavior. Part of the trickiness in avoiding narrow_state mocking is that you often would have to introduce "real" Filter objects, and the API for Filter objects is somewhat less than ideal, and its wordiness can distract from the main point of the tests. Hopefully the changes here reflect the correct tradeoffs.
2022-03-16 13:53:34 +01:00
const narrow_state = zrequire("narrow_state");
node_tests: Don’t read from most deprecated global variables. We still need to write to these globals with set_global because the code being tested reads from them, but the tests themselves should never need to read from them. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-10 04:53:22 +01:00
const pm_list = zrequire("pm_list");
Extract frontend_tests/node_tests/pm_list.js. This code used to live in node_tests/stream_list.js.
2017-01-25 17:11:29 +01:00
node tests: Avoid narrow_state mocking in pm_list* tests. We now use narrow_state directly in pm_list and pm_list_data tests, rather than mocking it with our `override*` helpers. In some places I use an actual Filter() object, but in places where the only testing concern is that the active is narrow, I use a stub value. We will continue to mock narrow_state in most places. In addition to avoiding test-setup complications, we want to avoid incidental line coverage on narrow_state that only indirectly validates its behavior. Part of the trickiness in avoiding narrow_state mocking is that you often would have to introduce "real" Filter objects, and the API for Filter objects is somewhat less than ideal, and its wordiness can distract from the main point of the tests. Hopefully the changes here reflect the correct tradeoffs.
2022-03-16 13:53:34 +01:00
run_test("update_dom_with_unread_counts", () => {
pm_list: Simplify redraws for Private Messages. We now use vdom-ish techniques to track the list items for the pm list. When we go to update the list, we only re-render nodes whose data has changed, with two exceptions: - Obviously, the first time we do a full render. - If the keys for the items have changed (i.e. a new node has come in or the order has changed), we just re-render the whole list. If the keys are the same since the last re-render, we only re-render individual items if their data has changed. Most of the new code is in these two modules: - pm_list_dom.js - vdom.js We remove all of the code in pm_list.js that is related to updating DOM with unread counts. For presence updates, we are now *never* re-rendering the whole list, since presence updates only change individual line items and don't affect the keys. Instead, we just update any changed elements in place. The main thing that makes this all work is the `update` method in `vdom`, which is totally generic and essentially does a few simple jobs: - detect if keys are different - just render the whole ul as needed - for items that change, do the appropriate jQuery to update the item in place Note that this code seems to play nice with simplebar. Also, this code continues to use templates to render the individual list items. FWIW this code isn't radically different than list_render, but it's got some key differences: - There are fewer bells and whistles in this code. Some of the stuff that list_render does is overkill for the PM list. - This code detects data changes. Note that the vdom scheme is agnostic about templates; it simply requires the child nodes to provide a render method. (This is similar to list_render, which is also technically agnostic about rendering, but which also does use templates in most cases.) These fixes are somewhat related to #13605, but we haven't gotten a solid repro on that issue, and the scrolling issues there may be orthogonal to the redraws. But having fewer moving parts here should help, and we won't get the rug pulled out from under us on every presence update. There are two possible extensions to this that are somewhat overlapping in nature, but can be done one a time. * We can do a deeper vdom approach here that gets us away from templates, and just have nodes write to an AST. I have this on another branch, but it might be overkill. * We can avoid some redraws by detecting where keys are moving up and down. I'm not completely sure we need it for the PM list. If this gets merged, we may want to try similar things for the stream list, which also does a fairly complicated mixture of big-hammer re-renders and surgical updates-in-place (with custom code). BTW we have 100% line coverage for vdom.js.
2020-01-04 17:17:44 +01:00
let counts;
node tests: Use override/with_field in pm_list.
2021-02-20 13:14:49 +01:00
node tests: Avoid narrow_state mocking in pm_list* tests. We now use narrow_state directly in pm_list and pm_list_data tests, rather than mocking it with our `override*` helpers. In some places I use an actual Filter() object, but in places where the only testing concern is that the active is narrow, I use a stub value. We will continue to mock narrow_state in most places. In addition to avoiding test-setup complications, we want to avoid incidental line coverage on narrow_state that only indirectly validates its behavior. Part of the trickiness in avoiding narrow_state mocking is that you often would have to introduce "real" Filter objects, and the API for Filter objects is somewhat less than ideal, and its wordiness can distract from the main point of the tests. Hopefully the changes here reflect the correct tradeoffs.
2022-03-16 13:53:34 +01:00
// simulate an active narrow
narrow_state.set_current_filter("stub");
assert.equal(narrow_state.active(), true);
node tests: Use override/with_field in pm_list.
2021-02-20 13:14:49 +01:00
js: Prefix jQuery object variable names with $. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-01-25 11:36:19 +01:00
const $total_count = $.create("total-count-stub");
pm_section: Create collapsible private messages section. This commit introduces the change of rendering private messages section as collapsible, whose data-fetching logic came with zulip#21357. We now have separated out `Private messages` from `top_left_corner` section and shifted it below the `global_filters` in a different separate section along with stream list with common scroll bar in left-sidebar. The new PM section will be opened by-default on loading the page and will have a toggle-icon in its header, clicking on which makes the section collapse/expand accordingly. In default view, only recent 5 PM threads would be shown and would append the active conversation as the 6th one at last if not present in those 5, similar to how topics list work. In PM section with unreads, a maximum of 8 conversations would be shown and rest of them would be hidden behind the 'more conversations' li-item, clicking on which takes to the zoomedIn view of PM section where all the present PM threads would be visible and rest of the sections of left-sidebar will get collapsed. Fixes #20870. Co-authored-by: Aman Agrawal <amanagr@zulip.com>
2022-09-13 13:15:57 +02:00
const $private_li = $(
".private_messages_container #private_messages_section #private_messages_section_header",
);
js: Prefix jQuery object variable names with $. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-01-25 11:36:19 +01:00
$private_li.set_find_results(".unread_count", $total_count);
Add test_update_dom_with_unread_counts().
2017-05-31 15:56:22 +02:00
pm_list: Simplify redraws for Private Messages. We now use vdom-ish techniques to track the list items for the pm list. When we go to update the list, we only re-render nodes whose data has changed, with two exceptions: - Obviously, the first time we do a full render. - If the keys for the items have changed (i.e. a new node has come in or the order has changed), we just re-render the whole list. If the keys are the same since the last re-render, we only re-render individual items if their data has changed. Most of the new code is in these two modules: - pm_list_dom.js - vdom.js We remove all of the code in pm_list.js that is related to updating DOM with unread counts. For presence updates, we are now *never* re-rendering the whole list, since presence updates only change individual line items and don't affect the keys. Instead, we just update any changed elements in place. The main thing that makes this all work is the `update` method in `vdom`, which is totally generic and essentially does a few simple jobs: - detect if keys are different - just render the whole ul as needed - for items that change, do the appropriate jQuery to update the item in place Note that this code seems to play nice with simplebar. Also, this code continues to use templates to render the individual list items. FWIW this code isn't radically different than list_render, but it's got some key differences: - There are fewer bells and whistles in this code. Some of the stuff that list_render does is overkill for the PM list. - This code detects data changes. Note that the vdom scheme is agnostic about templates; it simply requires the child nodes to provide a render method. (This is similar to list_render, which is also technically agnostic about rendering, but which also does use templates in most cases.) These fixes are somewhat related to #13605, but we haven't gotten a solid repro on that issue, and the scrolling issues there may be orthogonal to the redraws. But having fewer moving parts here should help, and we won't get the rug pulled out from under us on every presence update. There are two possible extensions to this that are somewhat overlapping in nature, but can be done one a time. * We can do a deeper vdom approach here that gets us away from templates, and just have nodes write to an AST. I have this on another branch, but it might be overkill. * We can avoid some redraws by detecting where keys are moving up and down. I'm not completely sure we need it for the PM list. If this gets merged, we may want to try similar things for the stream list, which also does a fairly complicated mixture of big-hammer re-renders and surgical updates-in-place (with custom code). BTW we have 100% line coverage for vdom.js.
2020-01-04 17:17:44 +01:00
counts = {
Add test_update_dom_with_unread_counts().
2017-05-31 15:56:22 +02:00
private_message_count: 10,
};
pm_section: Create collapsible private messages section. This commit introduces the change of rendering private messages section as collapsible, whose data-fetching logic came with zulip#21357. We now have separated out `Private messages` from `top_left_corner` section and shifted it below the `global_filters` in a different separate section along with stream list with common scroll bar in left-sidebar. The new PM section will be opened by-default on loading the page and will have a toggle-icon in its header, clicking on which makes the section collapse/expand accordingly. In default view, only recent 5 PM threads would be shown and would append the active conversation as the 6th one at last if not present in those 5, similar to how topics list work. In PM section with unreads, a maximum of 8 conversations would be shown and rest of them would be hidden behind the 'more conversations' li-item, clicking on which takes to the zoomedIn view of PM section where all the present PM threads would be visible and rest of the sections of left-sidebar will get collapsed. Fixes #20870. Co-authored-by: Aman Agrawal <amanagr@zulip.com>
2022-09-13 13:15:57 +02:00
pm_list.set_count(counts.private_message_count);
js: Prefix jQuery object variable names with $. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-01-25 11:36:19 +01:00
assert.equal($total_count.text(), "10");
ui_util: Use `.show` and `.hide` classes for unread counts visibility. This is a prep commit for introducing new "Show unread counts for" user display setting. We should use css classes like `.hide` to hide the unread count from the DOM as opposed to using `$unread_count_span.hide()` because this injects inline styles and hence we won't be able to change the `display` style on hovering for unread counts.
2023-04-25 13:03:05 +02:00
assert.equal($total_count.hasClass("hide"), false);
pm_lists.js: Reach 100% node test coverage.
2017-06-22 16:55:56 +02:00
counts = {
private_message_count: 0,
};
pm_list: Simplify redraws for Private Messages. We now use vdom-ish techniques to track the list items for the pm list. When we go to update the list, we only re-render nodes whose data has changed, with two exceptions: - Obviously, the first time we do a full render. - If the keys for the items have changed (i.e. a new node has come in or the order has changed), we just re-render the whole list. If the keys are the same since the last re-render, we only re-render individual items if their data has changed. Most of the new code is in these two modules: - pm_list_dom.js - vdom.js We remove all of the code in pm_list.js that is related to updating DOM with unread counts. For presence updates, we are now *never* re-rendering the whole list, since presence updates only change individual line items and don't affect the keys. Instead, we just update any changed elements in place. The main thing that makes this all work is the `update` method in `vdom`, which is totally generic and essentially does a few simple jobs: - detect if keys are different - just render the whole ul as needed - for items that change, do the appropriate jQuery to update the item in place Note that this code seems to play nice with simplebar. Also, this code continues to use templates to render the individual list items. FWIW this code isn't radically different than list_render, but it's got some key differences: - There are fewer bells and whistles in this code. Some of the stuff that list_render does is overkill for the PM list. - This code detects data changes. Note that the vdom scheme is agnostic about templates; it simply requires the child nodes to provide a render method. (This is similar to list_render, which is also technically agnostic about rendering, but which also does use templates in most cases.) These fixes are somewhat related to #13605, but we haven't gotten a solid repro on that issue, and the scrolling issues there may be orthogonal to the redraws. But having fewer moving parts here should help, and we won't get the rug pulled out from under us on every presence update. There are two possible extensions to this that are somewhat overlapping in nature, but can be done one a time. * We can do a deeper vdom approach here that gets us away from templates, and just have nodes write to an AST. I have this on another branch, but it might be overkill. * We can avoid some redraws by detecting where keys are moving up and down. I'm not completely sure we need it for the PM list. If this gets merged, we may want to try similar things for the stream list, which also does a fairly complicated mixture of big-hammer re-renders and surgical updates-in-place (with custom code). BTW we have 100% line coverage for vdom.js.
2020-01-04 17:17:44 +01:00
pm_section: Create collapsible private messages section. This commit introduces the change of rendering private messages section as collapsible, whose data-fetching logic came with zulip#21357. We now have separated out `Private messages` from `top_left_corner` section and shifted it below the `global_filters` in a different separate section along with stream list with common scroll bar in left-sidebar. The new PM section will be opened by-default on loading the page and will have a toggle-icon in its header, clicking on which makes the section collapse/expand accordingly. In default view, only recent 5 PM threads would be shown and would append the active conversation as the 6th one at last if not present in those 5, similar to how topics list work. In PM section with unreads, a maximum of 8 conversations would be shown and rest of them would be hidden behind the 'more conversations' li-item, clicking on which takes to the zoomedIn view of PM section where all the present PM threads would be visible and rest of the sections of left-sidebar will get collapsed. Fixes #20870. Co-authored-by: Aman Agrawal <amanagr@zulip.com>
2022-09-13 13:15:57 +02:00
pm_list.set_count(counts.private_message_count);
js: Prefix jQuery object variable names with $. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2022-01-25 11:36:19 +01:00
assert.equal($total_count.text(), "");
ui_util: Use `.show` and `.hide` classes for unread counts visibility. This is a prep commit for introducing new "Show unread counts for" user display setting. We should use css classes like `.hide` to hide the unread count from the DOM as opposed to using `$unread_count_span.hide()` because this injects inline styles and hence we won't be able to change the `display` style on hovering for unread counts.
2023-04-25 13:03:05 +02:00
assert.equal($total_count.hasClass("hide"), true);
Add run_test helper for individual tests. This run_test helper sets up a convention that allows us to give really short tracebacks for errors, and eventually we can have more control over running individual tests. (The latter goal has some complications, since we often intentionally leak setup in tests.)
2018-05-15 12:40:07 +02:00
});