Re: [w3c/webcomponents] Bulk property updates (#718)

Thanks to both of your feedback.

@caridy The motivation behind trying to unify such disparate concepts is that, in practice, we're often faced with a single conceptual task: to update a tree of elements in response to a user interaction or new data.

In our case, we're trying to create web components that update elements within their shadow tree. We find ourselves calculating a set of updates we want to apply to those elements, and a JavaScript object along the lines proposed here is a convenient way to represent the result of those calculations. We then interpret that object to figure out the exact `setAttribute`, `classList.toggle`, `appendChild`, etc., calls we need to make. While those calls involve different concepts (attributes, classes, styles, etc.), in practice, we end up treating them each of them as just another thing that needs to be updated to reflect the latest component state.

We assume other frameworks and libraries have a similar need, and so floated this proposal to discuss that. That is, we assume others have the same need to represent a set of changes that should be applied to an element or tree of elements. While the underlying concepts are distinct, the overall goal — apply a batch of changes — may be fairly consistent.

> I'm also concern about having more security issues by exposing a new way to mutate those element

My hope had been that, by expressing the API in terms of existing APIs, the number of new issues would be minimized.

> this time also relying on Object.prototype enumerable properties.

I'm not sure I understand this point.

@domenic I'd actually assumed that the code I'd written above was quite naive. E.g., in cases where the set of elements being added overlapped with the set of existing childNodes, it'd be desirable to avoid removing a child and then immediately adding it back. In any event, the `replaceAll()` proposal would be great. But the core of this proposal isn't about a better way to updating childNodes, it's looking for a better way to updating multiple aspects or an element or a tree of elements.

As I mentioned above, this is really more comparable to the template instantiation proposal. That proposal doesn't introduce any new capabilities, it just gives a dev syntax for updating a bunch of elements when state changes. This is similar. And, as I noted on a separate issue thread (linked above), this would be more useful to us; the template proposal doesn't meet our needs.

-- 
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-352602552