- 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