- From: Jan Miksovsky <notifications@github.com>
- Date: Tue, 19 Dec 2017 11:13:17 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/718/352857786@github.com>
> I will argue that such API should not be focus on updating a node, but multiple nodes in one go.
Our proposal included a means to apply properties to multiple elements in a document or document fragment (including a shadow root):
```html
<div id="foo">
<div id="bar"></div>
</div>
```
```js
document.applyPropertiesById({
foo: {
style: {
color: 'red'
}
},
bar: {
textContent: 'Hello, world.'
}
});
```
Result:
```html
<div id="foo" style="color: red;">
<div id="bar">Hello, world.</div>
</div>
```
> That proposal isn't about performance either.
To be clear, the words "that proposal" refer to the template instantiation proposal. Both that proposal and this are addressing a similar need: updating the DOM to reflect new state. In both cases, I don't view performance as the driving interest for me, but rather better ergonomics. In both cases, of course, I'm hoping performance also gets better.
I think a means to batch mutations via the DOMChangeList proposal or something similar would be great. Wouldn't it dovetail well with a simple means to update an element or tree of elements with data? That is, having created a `new DOMChangeList()`, it'd be nice to have the option to pass it a dictionary of updates to add (using the same format as above), instead of having manually translate state data into the appropriate change list calls.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/718#issuecomment-352857786
Received on Tuesday, 19 December 2017 19:13:39 UTC