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

On 04/27/2015 02:11 AM, Hayato Ito wrote:
> I think Polymer folks will answer the use case of re-distribution.
>

I wasn't questioning the need for re-distribution. I was questioning the need to distribute grandchildren etc -
and even more, I was wondering what kind of algorithm would be sane in that case.

And passing random not-in-document, nor in-shadow-DOM elements to be distributed would be hard too.



> So let me just show a good analogy so that every one can understand intuitively what re-distribution *means*.
> Let me use a pseudo language and define XComponent's constructor as follows:
>
> XComponents::XComponents(Title text, Icon icon) {
>    this.text = text;
>    this.button = new XButton(icon);
>    ...
> }
>
> Here, |icon| is *re-distributed*.
>
> In HTML world, this corresponds the followings:
>
> The usage of <x-component> element:
>    <x-components>
>      <x-text>Hello World</x-text>
>      <x-icon>My Icon</x-icon>
>    </x-component>
>
> XComponent's shadow tree is:
>
>    <shadow-root>
>      <h1><content select="x-text"></content></h1>
>      <x-button><content select="x-icon"></content></x-button>
>    </shadow-root>
>
> Re-distribution enables the constructor of X-Component to pass the given parameter to other component's constructor, XButton's constructor.
> If we don't have a re-distribution, XComponents can't create X-Button using the dynamic information.
>
> XComponents::XCompoennts(Title text, Icon icon) {
>    this.text = text;
>    // this.button = new xbutton(icon);  // We can't!  We don't have redistribution!
>    this.button = new xbutton("icon.png");  // XComponet have to do "hard-coding". Please allow me to pass |icon| to x-button!
>    ...
> }
>
>
> On Sun, Apr 26, 2015 at 12:23 PM Olli Pettay <olli@pettay.fi <mailto:olli@pettay.fi>> wrote:
>
>     On 04/25/2015 01:58 PM, Ryosuke Niwa wrote:
>      >
>      >> On Apr 25, 2015, at 1:17 PM, Olli Pettay <olli@pettay.fi <mailto:olli@pettay.fi>> wrote:
>      >>
>      >> On 04/25/2015 09:28 AM, Anne van Kesteren wrote:
>      >>> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
>      >>>> In today's F2F, I've got an action item to come up with a concrete workable proposal for imperative API.  I had a great chat about this
>      >>>> afterwards with various people who attended F2F and here's a summary.  I'll continue to work with Dimitri & Erik to work out details in the
>      >>>> coming months (our deadline is July 13th).
>      >>>>
>      >>>> https://gist.github.com/rniwa/2f14588926e1a11c65d3
>      >>>
>      >>> I thought we came up with something somewhat simpler that didn't require adding an event or adding remove() for that matter:
>      >>>
>      >>> https://gist.github.com/annevk/e9e61801fcfb251389ef
>      >>
>      >>
>      >> That is pretty much exactly how I was thinking the imperative API to work. (well, assuming errors in the example fixed)
>      >>
>      >> An example explaining how this all works in case of nested shadow trees would be good. I assume the more nested shadow tree just may get some
>      >> nodes, which were already distributed, in the distributionList.
>      >
>      > Right, that was the design we discussed.
>      >
>      >> How does the distribute() behave? Does it end up invoking distribution in all the nested shadow roots or only in the callee?
>      >
>      > Yes, that's the only reason we need distribute() in the first place.  If we didn't have to care about redistribution, simply exposing methods to
>      > insert/remove distributed nodes on content element is sufficient.
>      >
>      >> Should distribute callback be called automatically at the end of the microtask if there has been relevant[1] DOM mutations since the last manual
>      >> call to distribute()? That would make the API a bit simpler to use, if one wouldn't have to use MutationObservers.
>      >
>      > That's a possibility.  It could be an option to specify as well.  But there might be components that are not interested in updating distributed
>      > nodes for the sake of performance for example.  I'm not certain forcing everyone to always update distributed nodes is necessarily desirable given
>      > the lack of experience with an imperative API for distributing nodes.
>      >
>      >> [1] Assuming we want to distribute only direct children, then any child list change or any attribute change in the children might cause
>      >> distribution() automatically.
>      >
>      > I think that's a big if now that we've gotten rid of "select" attribute and multiple generations of shadow DOM.
>
>     It is not clear to me at all how you would handle the case when a node has several ancestors with shadow trees, and each of those want to distribute
>     the node to some insertion point.
>     Also, what is the use case to distribute non-direct descendants?
>
>
>
>
>      >  As far as I could recall, one of
>      > the reasons we only supported distributing direct children was so that we could implement "select" attribute and multiple generations of shadow
>      > DOM.   If we wanted, we could always impose such a restriction in a declarative syntax and inheritance mechanism we add in v2 since those v2 APIs
>      > are supposed to build on top of this imperative API.
>      >
>      > Another big if is whether we even need to let each shadow DOM select nodes to redistribute.  If we don't need to support filtering distributed
>      > nodes in insertion points for re-distribution (i.e. we either distribute everything under a given content element or nothing), then we don't need
>      > all of this redistribution mechanism baked into the browser and the model where we just have insert/remove on content element will work.
>      >
>      > - R. Niwa
>      >
>
>

Received on Monday, 27 April 2015 16:43:14 UTC