Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> One major drawback of this API is computing insertionList is expensive
> because we'd have to either (where n is the number of nodes in the shadow
> DOM):
>
> Maintain an ordered list of insertion points, which results in O(n)
> algorithm to run whenever a content element is inserted or removed.
> Lazily compute the ordered list of insertion points when `distribute`
> callback is about to get called in O(n).

The alternative is not exposing it and letting developers get hold of
the slots. The rationale for letting the browser do it is because you
need the slots either way and the browser should be able to optimize
better.


> If we wanted to allow non-direct child descendent (e.g. grand child node) of
> the host to be distributed, then we'd also need O(m) algorithm where m is
> the number of under the host element.  It might be okay to carry on the
> current restraint that only direct child of shadow host can be distributed
> into insertion points but I can't think of a good reason as to why such a
> restriction is desirable.

So you mean that we'd turn distributionList into a subtree? I.e. you
can pass all descendants of a host element to add()? I remember Yehuda
making the point that this was desirable to him.

The other thing I would like to explore is what an API would look like
that does the subclassing as well. Even though we deferred that to v2
I got the impression talking to some folks after the meeting that
there might be more common ground than I thought.


As for the points before about mutation observers. I kind of like just
having distribute() for v1 since it allows maximum flexibility. I
would be okay with having an option that is either optin or optout
that does the observing automatically, though I guess if we move from
children to descendants that gets more expensive.


-- 
https://annevankesteren.nl/

Received on Monday, 27 April 2015 06:06:13 UTC