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

I think Polymer folks will answer the use case of re-distribution.

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> wrote:

> On 04/25/2015 01:58 PM, Ryosuke Niwa wrote:
> >
> >> On Apr 25, 2015, at 1:17 PM, Olli Pettay <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>
> 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
> >
>
>
>