On Dec 9, 2013, at 11:13 AM, Scott Miles <sjmi...@google.com> wrote:
> I'm not wont to try to summarize it here, since he said it already better
> there. Perhaps the short version is: nobody knows what the 'standard use
> case' is yet.
How is that possible given we've already spent 2+ years on the whole web
components effort?
> In previous adjudications, the straw that broke that camel's back was with
> respect to handling auto-generation with inheritance. Shadow-roots may need
> to be generated for each entry in the inheritance chain.
The problem with that approach is that it mixes inheritance with composition.
> Having the system perform this task takes it out of the control of the user's
> code, which otherwise has ability to modulate calls to super-class methods
> and manage this process.
>
> class XFoo {
> constructor_or_createdCallback: function() {
> // my shadowRoot was auto-generated
> this.doUsefulStuffLikeDatabinding(this.shadowRoot);
> }
> }
>
> class XBar extends XFoo {
> constructor_or_createdCallback: function() {
> super(); // uh-oh, super call operates on wrong shadowRoot
> }
> }
This example doesn't work because the kind of encapsulation provided by shadow
insertion point is not suitable for inheritance amongst UI components nor is
available in other prominent GUI frameworks for the purpose of inheritance.
When subclassing a UI component, one has to either know what the superclass
draws on the screen (so that you can modify them as needed or draw more stuff
above or beneath it) or completely replace what's displayed. Putting the
superclass' content on some bounding box is a composition. Let us not mix the
two.
There are primarily two major use cases of inheritance in building UI "views":
Adding some non-GUI API for convenience - You don't need to touch the view at
all. Let the superclass draw/paint its view, and call its public API to modify
the internal states as needed.
Provide a new UI but use the underlying data model - You don't need to use
superclass' view. Just draw/paint your own stuff.
Modifying what its superclass paints/draws to tweak the UI - You need to know
exactly what superclass does. Either superclass needs to provide a hook to do
this or you need to know how superclass does its work so that you can intercept
by overriding methods and callbacks as needed.
None of that involves putting superclass' view into some subregion in the
subclass. (We also argue that the first two use cases are better addressed by
compositions on the Web for reasons I've stated elsewhere.)
- R. Niwa
