flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guild, Jason A (DFG)" <jason.gu...@alaska.gov>
Subject Re: [FlexJS] MDL - Dynamic Child Problem
Date Wed, 22 Feb 2017 18:10:53 GMT

Replies below...

On 2/21/2017 22:20, Alex Harui wrote:
> That said, we don't want the compiler generating code.  Everything else
> is converted to data structures so the framework can interpret the data
> structures.  The reason is mostly practical. It is scary for most folks to
> change the compiler.

I agree. When you put it this way maybe it is not the compiler 
generating additional code to setup strands with this or that beads, but 
is instead generating more data to be interpreted by the framework. Data 
that says "caller referenced 'disabled' attribute" on this component or 
container and that the reference "involved a binding expression". Then 
Express could pay attention to such data while maybe Basic does not.

> Express components could instantiate beads in the setter.  That sounds
> like a pattern worth more investigation. And you plug in the DisableBead without adding
to the
> model.  The Express Button aggregates all of those things and probably
> more.

Yes. But I hope we can just say disabled="{ model.disabled }" on a 
component and have it auto-setup. And that the "disabled" attribute is 
just documented as part of the API of some component or container. When 
you use it you get it, when you don't then it's not there. That's PAYG 
in the truest sense.

I'm not for a moment debating how it is done, just that it is important 
for people new to FlexJS to be able to get productivity like the old 
Flex API gave us. Where you could look at the published docs, paste some 
code from it or Peter DeHaan's flex samples site and see that some 
feature "just works". Fairly generally, without a bunch of exceptions. 
Then you build out your app having seen how some specific feature is 
simply realized.

> In the end, all of this PAYG and beads and composition comes back to DRY.

I totally believe in DRY to the extent that it is practical. Composition 
is absolutely the right approach. But it remains to be seen whether the 
beads being developed can be made sufficiently generalized that they are 
composable without requiring leaky abstractions. For example, like a 
DisabledBead that just works for "everything". All components and 
containers no exceptions. Because it is a very basic thing to want to 
put a component or a complete hierarchy of components into a disabled 
state conveniently. Or that you just want to be able to add a child to a 
container at runtime. That's where I think the rub is compared to the 
old inheritance-based Flex API.

> One final thought:  I think of large hardware stores.  You go to the tool
> area and the number of screwdrivers or drills is overwhelming.  They are
> all slightly different, optimized for some particular scenario.  The same
> will be true for FlexJS and beads. Most of
> us manage to choose a screwdriver or drill that makes us happy.

Okay, well said.


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message