On 10/27/16, 12:48 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:
>Thanks, > >I was not thinking this from that point of view. Maybe in MDL has sense to >include majority of beads since it's a concrete implementation of visuals: >Material Design Lite >But don't know if we could have a base control (ButtonBase...for example >but doesn't like too much that name) and then another (the Button *actual >class*) that instantiates ButtonEffect and Disable beads > >btw, if you notice, I remove the "Bead" ending in my beads, since I think >is less verbose and the mxml is pretty descriptive (those are parte of >js:beads). It does look fine in MXML, but I worry about how to find them in ASDoc. That's why I want to try to create a smarter doc app for FlexJS where we mark classes with @bead and @component so folks can filter better. >As well I implemented effects with boolean flags. I have to make different >beads for different controls since are effect "per-control", with some to >them common and available in an MDLEffect bead that the rest extend from. IMO, it is all a trade-off. The Basic set will have everything broken out into beads, but I fully expect the most popular first-time-user component set will have lots of beads aggregated into it to make developing your POC less verbose. So yes, you can break stuff out into pieces inside MDL as well, but realize that is another trade-off. An aggregation of beads will be heavier and slower than just baking some code into the component, but if you aggregate beads then you can factor them out later if you aren't using. -Alex
