flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] List Structure
Date Wed, 23 Nov 2016 17:38:01 GMT

On 11/23/16, 8:58 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:

>> In fact, for every Basic component, we should try to prove that you can
>use composition to create the very same component from a UIBase.
>This explanation and the UIBase example code that follows it is probably
>good to bring up more frequently. I think it's better than a simple
>reminder that Basic components should be pay-as-you-go. By seeing that a
>generic UIBase can become the more complex component with the right beads,
>it really cements what pay-as-you-go truly means.

Thanks. IMO, it is more about composition vs. inheritance than PAYG
because PAYG also applies to the beads themselves.  In the basic set we
don't want to require folks to use fat, multipurpose beads, otherwise we'd
just have one SelectionBead that could handle all sorts of selection.

In fact, I think some beads are also strands or have slots in them for
subcomponents that are also composed. Consider Panel, for example:

<js:Panel title="Foo" />

Expands to:

  <js:PanelModel title="foo" />

Which further expands to:

  <js:PanelModel title="foo" />
  <js:PanelView />
    <js:titleBar />
      <js:TitleBar />
    </js:titleBar />
  </js:PanelView />

Which further expands to:

  <js:PanelModel title="foo" />
  <js:PanelView />
    <js:titleBar />
      <js:UIBase />
       <js:TitleBarModel />
       <js:TitleBarView />
    </js:titleBar />
  </js:PanelView />

And so on.  And as you see it "explode" or "decompose" you can see where
you can start to replace the parts with custom parts.  If the default
PanelView doesn't support a status bar, control bar or menu bar, you would
replace the PanelView with one that does.
The default TitleBarView doesn't support a close button or min/max buttons
so you could replace it with a version that does.  And as long as the code
is using interfaces and events and doesn't assume a particular concrete
class, you can re-compose with exactly the code and strongly-typed API
surfaces you need.  Essentially, this pattern enables PAYG, but doesn't
enforce it.

Of course, nobody wants to do this much typing of all of those tags all of
the time, so that's when you re-compose common patterns into high-level
components and proxy bead APIs to the component surface and bake a few
things in.  This puts the PAYG decision-making in the hands of the
component users, not the component developers, which is what we want.

And the other benefit of all of these loosely-coupled pieces is the
greater potential for re-use, which is part of the "composition vs
inheritance" trade-off.  It turns out that the concept of item renderers
and factories can apply in lots of other places than the List/Menu we
normally associate with.  Charts is leveraging the same code, and the
non-selectable, data-driven OL/UL lists can leverage these beads as well.


View raw message