2020-08-01 03:43:15 +02:00
|
|
|
"use strict";
|
|
|
|
|
2020-11-30 23:46:45 +01:00
|
|
|
const {strict: assert} = require("assert");
|
|
|
|
|
2021-02-14 12:21:43 +01:00
|
|
|
const {set_global, zrequire} = require("../zjsunit/namespace");
|
2020-12-01 00:39:47 +01:00
|
|
|
const {run_test} = require("../zjsunit/test");
|
2020-12-01 00:12:33 +01:00
|
|
|
const {make_zjquery} = require("../zjsunit/zjquery");
|
2020-12-01 00:02:16 +01:00
|
|
|
|
2020-12-01 00:12:33 +01:00
|
|
|
set_global("$", make_zjquery());
|
2017-05-31 01:32:55 +02:00
|
|
|
|
2021-02-10 04:53:22 +01:00
|
|
|
const narrow_state = set_global("narrow_state", {});
|
2020-07-15 01:29:15 +02:00
|
|
|
set_global("ui", {
|
2020-07-02 01:39:34 +02:00
|
|
|
get_content_element: (element) => element,
|
2019-02-13 14:05:58 +01:00
|
|
|
});
|
2020-07-15 01:29:15 +02:00
|
|
|
set_global("stream_popover", {
|
2020-07-20 22:18:43 +02:00
|
|
|
hide_topic_popover() {},
|
2017-05-31 16:59:37 +02:00
|
|
|
});
|
2021-02-10 04:53:22 +01:00
|
|
|
const unread = set_global("unread", {});
|
|
|
|
const unread_ui = set_global("unread_ui", {});
|
|
|
|
const vdom = set_global("vdom", {
|
2020-07-15 01:29:15 +02:00
|
|
|
render: () => "fake-dom-for-pm-list",
|
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
|
|
|
});
|
2021-02-10 04:53:22 +01:00
|
|
|
const pm_list_dom = set_global("pm_list_dom", {});
|
2017-01-25 17:11:29 +01:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
zrequire("presence");
|
|
|
|
zrequire("buddy_data");
|
|
|
|
zrequire("hash_util");
|
2020-08-20 21:24:06 +02:00
|
|
|
const people = zrequire("people");
|
2020-08-18 19:53:22 +02:00
|
|
|
const pm_conversations = zrequire("pm_conversations");
|
2021-02-10 04:53:22 +01:00
|
|
|
const pm_list = zrequire("pm_list");
|
2017-01-25 17:11:29 +01:00
|
|
|
|
2019-11-02 00:06:25 +01:00
|
|
|
const alice = {
|
2020-07-15 01:29:15 +02:00
|
|
|
email: "alice@zulip.com",
|
2017-01-25 17:11:29 +01:00
|
|
|
user_id: 101,
|
2020-07-15 01:29:15 +02:00
|
|
|
full_name: "Alice",
|
2017-01-25 17:11:29 +01:00
|
|
|
};
|
2019-11-02 00:06:25 +01:00
|
|
|
const bob = {
|
2020-07-15 01:29:15 +02:00
|
|
|
email: "bob@zulip.com",
|
2017-01-25 17:11:29 +01:00
|
|
|
user_id: 102,
|
2020-07-15 01:29:15 +02:00
|
|
|
full_name: "Bob",
|
2017-01-25 17:11:29 +01:00
|
|
|
};
|
2019-11-02 00:06:25 +01:00
|
|
|
const me = {
|
2020-07-15 01:29:15 +02:00
|
|
|
email: "me@zulip.com",
|
2017-01-25 17:11:29 +01:00
|
|
|
user_id: 103,
|
2020-07-15 01:29:15 +02:00
|
|
|
full_name: "Me Myself",
|
2017-01-25 17:11:29 +01:00
|
|
|
};
|
2019-11-02 00:06:25 +01:00
|
|
|
const bot_test = {
|
2020-07-15 01:29:15 +02:00
|
|
|
email: "outgoingwebhook@zulip.com",
|
2019-09-16 23:57:18 +02:00
|
|
|
user_id: 314,
|
|
|
|
full_name: "Outgoing webhook",
|
|
|
|
is_admin: false,
|
|
|
|
is_bot: true,
|
|
|
|
};
|
2020-05-26 22:34:15 +02:00
|
|
|
people.add_active_user(alice);
|
|
|
|
people.add_active_user(bob);
|
|
|
|
people.add_active_user(me);
|
|
|
|
people.add_active_user(bot_test);
|
2020-03-21 21:54:16 +01:00
|
|
|
people.initialize_current_user(me.user_id);
|
2017-01-25 17:11:29 +01:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
run_test("close", () => {
|
2019-11-02 00:06:25 +01:00
|
|
|
let collapsed;
|
2020-07-15 01:29:15 +02:00
|
|
|
$("#private-container").empty = function () {
|
2017-06-22 16:55:56 +02:00
|
|
|
collapsed = true;
|
|
|
|
};
|
|
|
|
pm_list.close();
|
|
|
|
assert(collapsed);
|
2018-05-15 12:40:07 +02:00
|
|
|
});
|
2017-06-22 16:55:56 +02:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
run_test("build_private_messages_list", () => {
|
2019-11-02 00:06:25 +01:00
|
|
|
const timestamp = 0;
|
2020-01-01 15:42:46 +01:00
|
|
|
pm_conversations.recent.insert([101, 102], timestamp);
|
2017-01-25 17:11:29 +01:00
|
|
|
|
2020-12-01 00:57:57 +01:00
|
|
|
unread.num_unread_for_person = function () {
|
2017-01-25 17:11:29 +01:00
|
|
|
return 1;
|
|
|
|
};
|
|
|
|
|
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 pm_data;
|
2017-05-31 01:32:55 +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
|
|
|
pm_list_dom.pm_ul = (data) => {
|
|
|
|
pm_data = data;
|
|
|
|
};
|
2017-05-31 01:32:55 +02:00
|
|
|
|
2020-01-06 15:00:11 +01:00
|
|
|
narrow_state.filter = () => {};
|
2020-01-06 13:07:00 +01:00
|
|
|
pm_list._build_private_messages_list();
|
2017-05-31 01:32:55 +02:00
|
|
|
|
2020-01-11 12:59:02 +01:00
|
|
|
const expected_data = [
|
|
|
|
{
|
2020-07-15 01:29:15 +02:00
|
|
|
recipients: "Alice, Bob",
|
|
|
|
user_ids_string: "101,102",
|
2020-01-11 12:59:02 +01:00
|
|
|
unread: 1,
|
|
|
|
is_zero: false,
|
|
|
|
is_active: false,
|
2020-07-15 01:29:15 +02:00
|
|
|
url: "#narrow/pm-with/101,102-group",
|
|
|
|
user_circle_class: "user_circle_fraction",
|
2020-01-11 12:59:02 +01:00
|
|
|
fraction_present: undefined,
|
|
|
|
is_group: true,
|
|
|
|
},
|
|
|
|
];
|
|
|
|
|
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
|
|
|
assert.deepEqual(pm_data, expected_data);
|
2017-01-25 17:11:29 +01:00
|
|
|
|
2020-12-01 00:57:57 +01:00
|
|
|
unread.num_unread_for_person = function () {
|
2017-06-22 16:55:56 +02:00
|
|
|
return 0;
|
|
|
|
};
|
2020-01-06 13:07:00 +01:00
|
|
|
pm_list._build_private_messages_list();
|
2020-01-11 12:59:02 +01:00
|
|
|
expected_data[0].unread = 0;
|
|
|
|
expected_data[0].is_zero = true;
|
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
|
|
|
assert.deepEqual(pm_data, expected_data);
|
2017-06-22 16:55:56 +02:00
|
|
|
|
|
|
|
pm_list.initialize();
|
2020-01-06 13:07:00 +01:00
|
|
|
pm_list._build_private_messages_list();
|
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
|
|
|
assert.deepEqual(pm_data, expected_data);
|
2018-05-15 12:40:07 +02:00
|
|
|
});
|
2017-05-31 15:56:22 +02:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
run_test("build_private_messages_list_bot", () => {
|
2019-11-02 00:06:25 +01:00
|
|
|
const timestamp = 0;
|
2020-01-01 15:42:46 +01:00
|
|
|
pm_conversations.recent.insert([314], timestamp);
|
2019-09-16 23:57:18 +02:00
|
|
|
|
2020-12-01 00:57:57 +01:00
|
|
|
unread.num_unread_for_person = function () {
|
2019-09-16 23:57:18 +02:00
|
|
|
return 1;
|
|
|
|
};
|
|
|
|
|
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 pm_data;
|
|
|
|
pm_list_dom.pm_ul = (data) => {
|
|
|
|
pm_data = data;
|
|
|
|
};
|
|
|
|
|
|
|
|
narrow_state.active = () => true;
|
2019-09-16 23:57:18 +02:00
|
|
|
|
2020-01-06 13:07:00 +01:00
|
|
|
pm_list._build_private_messages_list();
|
2020-01-11 12:59:02 +01:00
|
|
|
const expected_data = [
|
|
|
|
{
|
2020-07-15 01:29:15 +02:00
|
|
|
recipients: "Outgoing webhook",
|
|
|
|
user_ids_string: "314",
|
2020-01-11 12:59:02 +01:00
|
|
|
unread: 1,
|
|
|
|
is_zero: false,
|
|
|
|
is_active: false,
|
2020-07-15 01:29:15 +02:00
|
|
|
url: "#narrow/pm-with/314-outgoingwebhook",
|
|
|
|
user_circle_class: "user_circle_green",
|
2020-01-11 12:59:02 +01:00
|
|
|
fraction_present: undefined,
|
|
|
|
is_group: false,
|
|
|
|
},
|
|
|
|
{
|
2020-07-15 01:29:15 +02:00
|
|
|
recipients: "Alice, Bob",
|
|
|
|
user_ids_string: "101,102",
|
2020-01-11 12:59:02 +01:00
|
|
|
unread: 1,
|
|
|
|
is_zero: false,
|
|
|
|
is_active: false,
|
2020-07-15 01:29:15 +02:00
|
|
|
url: "#narrow/pm-with/101,102-group",
|
|
|
|
user_circle_class: "user_circle_fraction",
|
2020-01-11 12:59:02 +01:00
|
|
|
fraction_present: undefined,
|
|
|
|
is_group: true,
|
|
|
|
},
|
|
|
|
];
|
|
|
|
|
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
|
|
|
assert.deepEqual(pm_data, expected_data);
|
2019-09-16 23:57:18 +02:00
|
|
|
});
|
|
|
|
|
2020-07-15 01:29:15 +02: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;
|
|
|
|
let toggle_button_set;
|
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
const total_value = $.create("total-value-stub");
|
|
|
|
const total_count = $.create("total-count-stub");
|
2019-11-02 00:06:25 +01:00
|
|
|
const private_li = $(".top_left_private_messages");
|
2020-07-15 01:29:15 +02:00
|
|
|
private_li.set_find_results(".count", total_count);
|
|
|
|
total_count.set_find_results(".value", total_value);
|
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 = {
|
2017-05-31 15:56:22 +02:00
|
|
|
private_message_count: 10,
|
|
|
|
};
|
|
|
|
|
|
|
|
unread_ui.set_count_toggle_button = function (elt, count) {
|
|
|
|
toggle_button_set = true;
|
|
|
|
assert.equal(count, 10);
|
|
|
|
};
|
|
|
|
|
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
|
|
|
toggle_button_set = false;
|
2017-05-31 15:56:22 +02:00
|
|
|
pm_list.update_dom_with_unread_counts(counts);
|
|
|
|
assert(toggle_button_set);
|
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
|
|
|
|
2017-06-22 16:55:56 +02:00
|
|
|
unread_ui.set_count_toggle_button = function (elt, count) {
|
|
|
|
toggle_button_set = true;
|
|
|
|
assert.equal(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
|
|
|
toggle_button_set = false;
|
2017-06-22 16:55:56 +02:00
|
|
|
pm_list.update_dom_with_unread_counts(counts);
|
|
|
|
assert(toggle_button_set);
|
2018-05-15 12:40:07 +02:00
|
|
|
});
|
2020-01-06 15:00:11 +01:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
run_test("get_active_user_ids_string", () => {
|
2020-01-06 15:00:11 +01:00
|
|
|
narrow_state.filter = () => {};
|
|
|
|
|
2020-07-15 00:34:28 +02:00
|
|
|
assert.equal(pm_list.get_active_user_ids_string(), undefined);
|
2020-01-06 15:00:11 +01:00
|
|
|
|
|
|
|
function set_filter_result(emails) {
|
2020-07-02 01:41:40 +02:00
|
|
|
narrow_state.filter = () => ({
|
|
|
|
operands: (operand) => {
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(operand, "pm-with");
|
2020-07-02 01:41:40 +02:00
|
|
|
return emails;
|
|
|
|
},
|
|
|
|
});
|
2020-01-06 15:00:11 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
set_filter_result([]);
|
2020-07-15 00:34:28 +02:00
|
|
|
assert.equal(pm_list.get_active_user_ids_string(), undefined);
|
2020-01-06 15:00:11 +01:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
set_filter_result(["bob@zulip.com,alice@zulip.com"]);
|
2020-07-15 00:34:28 +02:00
|
|
|
assert.equal(pm_list.get_active_user_ids_string(), "101,102");
|
2020-01-06 15:00:11 +01:00
|
|
|
});
|
2020-01-06 16:18:20 +01:00
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
run_test("is_all_privates", () => {
|
2020-01-06 16:18:20 +01:00
|
|
|
narrow_state.filter = () => {};
|
|
|
|
|
2020-07-15 00:34:28 +02:00
|
|
|
assert.equal(pm_list.is_all_privates(), false);
|
2020-01-06 16:18:20 +01:00
|
|
|
|
2020-07-02 01:41:40 +02:00
|
|
|
narrow_state.filter = () => ({
|
|
|
|
operands: (operand) => {
|
2020-07-15 01:29:15 +02:00
|
|
|
assert.equal(operand, "is");
|
|
|
|
return ["private", "starred"];
|
2020-07-02 01:41:40 +02:00
|
|
|
},
|
|
|
|
});
|
2020-01-06 16:18:20 +01:00
|
|
|
|
2020-07-15 00:34:28 +02:00
|
|
|
assert.equal(pm_list.is_all_privates(), true);
|
2020-01-06 16:18:20 +01:00
|
|
|
});
|
2020-01-06 16:49:53 +01:00
|
|
|
|
2021-02-14 08:44:04 +01:00
|
|
|
run_test("expand", (override) => {
|
|
|
|
override(pm_list, "_build_private_messages_list", () => "PM_LIST_CONTENTS");
|
|
|
|
let html_updated;
|
|
|
|
vdom.update = () => {
|
|
|
|
html_updated = true;
|
|
|
|
};
|
2020-01-06 16:49:53 +01:00
|
|
|
|
2021-02-14 08:44:04 +01:00
|
|
|
pm_list.expand();
|
|
|
|
assert(html_updated);
|
2020-01-06 16:49:53 +01:00
|
|
|
});
|
|
|
|
|
2021-02-14 08:44:04 +01:00
|
|
|
run_test("update_private_messages", (override) => {
|
2020-01-06 16:49:53 +01:00
|
|
|
narrow_state.active = () => true;
|
2020-07-15 01:29:15 +02:00
|
|
|
$("#private-container").find = (sel) => {
|
|
|
|
assert.equal(sel, "ul");
|
2020-01-31 21:58:28 +01:00
|
|
|
};
|
2021-02-14 08:44:04 +01:00
|
|
|
override(pm_list, "_build_private_messages_list", () => "PM_LIST_CONTENTS");
|
2020-01-31 21:58:28 +01:00
|
|
|
|
2021-02-14 08:44:04 +01:00
|
|
|
let html_updated;
|
|
|
|
vdom.update = (replace_content, find) => {
|
|
|
|
html_updated = true;
|
2020-01-06 16:49:53 +01:00
|
|
|
|
2021-02-14 08:44:04 +01:00
|
|
|
// get line coverage for simple one-liners
|
|
|
|
replace_content();
|
|
|
|
find();
|
|
|
|
};
|
2020-01-06 16:49:53 +01:00
|
|
|
|
2021-02-14 12:21:43 +01:00
|
|
|
pm_list.update_private_messages();
|
2021-02-14 08:44:04 +01:00
|
|
|
assert(html_updated);
|
|
|
|
assert($(".top_left_private_messages").hasClass("active-filter"));
|
2020-01-06 16:49:53 +01:00
|
|
|
});
|
|
|
|
|
2020-07-15 01:29:15 +02:00
|
|
|
run_test("ensure coverage", () => {
|
2020-01-06 16:49:53 +01:00
|
|
|
// These aren't rigorous; they just cover cases
|
|
|
|
// where functions early exit.
|
|
|
|
narrow_state.active = () => false;
|
|
|
|
pm_list.rebuild_recent = () => {
|
2020-10-07 09:58:04 +02:00
|
|
|
throw new Error("we should not call rebuild_recent");
|
2020-01-06 16:49:53 +01:00
|
|
|
};
|
|
|
|
pm_list.update_private_messages();
|
|
|
|
});
|