zulip/web/tests/vdom.test.js

253 lines
5.7 KiB
JavaScript
Raw Normal View History

"use strict";
const {strict: assert} = require("assert");
const {zrequire} = require("./lib/namespace");
const {run_test} = require("./lib/test");
const blueslip = require("./lib/zblueslip");
const vdom = zrequire("vdom");
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
run_test("basics", () => {
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
const opts = {
keyed_nodes: [],
attrs: [
["class", "foo"],
["title", 'cats & <"dogs">'],
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
],
};
const ul = vdom.ul(opts);
const html = vdom.render_tag(ul);
assert.equal(html, '<ul class="foo" title="cats &amp; &lt;&quot;dogs&quot;&gt;">\n\n</ul>');
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
});
run_test("attribute escaping", () => {
// So far most of the time our attributes are
2023-10-30 16:11:34 +01:00
// hard-coded classes like "dm-list",
// but we need to be defensive about future code
// that might use data from possibly malicious users.
const opts = {
keyed_nodes: [],
attrs: [
["class", '">something evil<div class="'],
["title", "apples & oranges"],
],
};
const ul = vdom.ul(opts);
const html = vdom.render_tag(ul);
assert.equal(
html,
'<ul class="&quot;&gt;something evil&lt;div class=&quot;" ' +
'title="apples &amp; oranges">\n\n</ul>',
);
});
run_test("attribute updates", () => {
const opts = {
keyed_nodes: [],
attrs: [
["class", "same"],
["color", "blue"],
["id", "101"],
],
};
const ul = vdom.ul(opts);
const html = vdom.render_tag(ul);
assert.equal(html, '<ul class="same" color="blue" id="101">\n\n</ul>');
let updated;
let removed;
function find() {
return {
children: () => [],
attr(k, v) {
assert.equal(k, "color");
assert.equal(v, "red");
updated = true;
},
removeAttr(k) {
assert.equal(k, "id");
removed = true;
},
};
}
const new_opts = {
keyed_nodes: [],
attrs: [
["class", "same"], // unchanged
["color", "red"],
],
};
const new_ul = vdom.ul(new_opts);
const replace_content = undefined;
vdom.update(replace_content, find, new_ul, ul);
assert.ok(updated);
assert.ok(removed);
});
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
function make_child(i, name) {
const render = () => "<li>" + name + "</li>";
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
const eq = (other) => name === other.name;
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
return {
key: i,
render,
name,
eq,
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
};
}
function make_children(lst) {
return lst.map((i) => make_child(i, "foo" + i));
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
}
run_test("children", () => {
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 rendered_html;
function replace_content(html) {
rendered_html = html;
}
const find = undefined;
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
const nodes = make_children([1, 2, 3]);
const opts = {
keyed_nodes: nodes,
attrs: [],
};
const ul = vdom.ul(opts);
vdom.update(replace_content, find, ul);
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.equal(rendered_html, "<ul>\n<li>foo1</li>\n<li>foo2</li>\n<li>foo3</li>\n</ul>");
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
// Force a complete redraw.
const new_nodes = make_children([4, 5]);
const new_opts = {
keyed_nodes: new_nodes,
attrs: [["class", "main"]],
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
};
const new_ul = vdom.ul(new_opts);
vdom.update(replace_content, find, new_ul, ul);
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.equal(rendered_html, '<ul class="main">\n<li>foo4</li>\n<li>foo5</li>\n</ul>');
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
});
run_test("partial updates", () => {
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 rendered_html;
let replace_content = (html) => {
rendered_html = html;
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 find;
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
const nodes = make_children([1, 2, 3]);
const opts = {
keyed_nodes: nodes,
attrs: [],
};
const ul = vdom.ul(opts);
vdom.update(replace_content, find, ul);
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.equal(rendered_html, "<ul>\n<li>foo1</li>\n<li>foo2</li>\n<li>foo3</li>\n</ul>");
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
/* istanbul ignore next */
replace_content = () => {
throw new Error("should not replace entire html");
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 $patched;
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
find = () => ({
children: () => ({
eq(i) {
assert.equal(i, 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
return {
replaceWith($element) {
$patched = $element;
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: 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
const new_nodes = make_children([1, 2, 3]);
new_nodes[0] = make_child(1, "modified1");
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
const new_opts = {
keyed_nodes: new_nodes,
attrs: [],
};
const new_ul = vdom.ul(new_opts);
vdom.update(replace_content, find, new_ul, ul);
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.equal($patched.selector, "<li>modified1</li>");
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
});
run_test("eq_array easy cases", () => {
/* istanbul ignore next */
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
const bogus_eq = () => {
throw new Error("we should not be comparing elements");
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.equal(vdom.eq_array(undefined, undefined, bogus_eq), 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
const x = [1, 2, 3];
assert.equal(vdom.eq_array(x, undefined, bogus_eq), false);
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.equal(vdom.eq_array(undefined, x, bogus_eq), false);
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.equal(vdom.eq_array(x, x, bogus_eq), true);
// length check should also short-circuit
const y = [1, 2, 3, 4, 5];
assert.equal(vdom.eq_array(x, y, bogus_eq), false);
// same length, same values, but different order
const eq = (a, b) => a === b;
const z = [3, 2, 1];
assert.equal(vdom.eq_array(x, z, eq), false);
});
run_test("eq_array element-wise", () => {
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
const a = [51, 32, 93];
const b = [31, 52, 43];
const eq = (a, b) => a % 10 === b % 10;
assert.equal(vdom.eq_array(a, b, eq), true);
});
run_test("error checking", () => {
blueslip.expect("error", "We need keyed_nodes for updates.");
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
const replace_content = "whatever";
const find = "whatever";
const ul = {opts: {attrs: []}};
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
vdom.update(replace_content, find, ul, ul);
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
});