Alex: 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. Jason
