On 3/15/16, 3:47 AM, "OK" <[email protected]> wrote:
>>In FlexJS, PAYG will commonly be implemented with different beads > >Only to make sure if I got it right: >Does this concept mean that instead of having one fat component that >implements all the features that probably makes sense for this component >there're a couple of small beads that respectively implements only a >subset >of features according the special characteristic of this bead? >So that during application development we have to choose the bead that >best >fits our needs? Well, it depends. Another important principle in FlexJS is the support for multiple component sets as opposed to trying to get everyone to use just Spark or MX in the regular Flex SDK. Yet another important principle in FlexJS is increased usage of composition instead of subclassing to add new features and functions. What I think will happen is that there will be popular fat component sets that are composited from lots of beads that folks will default to using for rapid development. Then if you run into performance and size issues, you can try swapping in lightweight component sets and build back the functionality you need by compositing beads used in the fat component sets. Other folks may always want to start with the lightweight component set and build up and are ok with making a lot of decisions and pulling in beads and swapping out other beads as they go. The current component set in FlexJS is intended to be the lightweight set. I am currently investigating the practicality of developing a component set that more closely mirrors the MX and Spark component sets which will be a really fat component set. The thing I am really trying to achieve is flexibility in the "last mile". While it was really simple in the regular Flex SDK to take the Spark components and build and app, I saw plenty of examples where a customer's deadline was approaching and they were running into performance and size issues and couldn't break out code in Spark they weren't using. By trying to make sure component developers take the time to use fine-grain encapsulation of functionality into beads and build components by compositing beads, we will give application developers options on how to build and tune their apps. There is a concern that the number of choices might be overwhelming, but I believe that tools and internet articles will emerge to help you make those choices, and the cost of trying different choices will be low. This is sort of true in the HTML world today: you can grab a snippet of JS from Stack Overflow, try it, and discard it if it doesn't work for you. HTH, -Alex
