Been thinking about component architecture. Ok, so it’s a regular topic of discussion with Tyler. There’s a lot that goes into it, but at a high-level there seems to be two trains of thought, at least for me, that I’m trying to decide between: building for the component creator, or building for the component user. I’d like to discuss these two and round it up with the pros and cons. Maybe I’ll settle on one by that point.
The component creator wants legos. He wants the pieces he can build components with easily (when I say “he” I mean me). He is frustrated with extending, building, and wrestling with components in Flex. So, we’re looking at splitting out the component into a skin (view), one or more behaviors (controller), and then perhaps some reusable model objects (um…model). The component creator wants an interface that describes the relationship between the component and the behaviors. Between the behaviors and the skin. It would be easy to assemble these into a component. Just drag-n-drop, right? You could create new and inventive and creative components all day! Beautiful.
The component user wants a shiny gadget. He wants to have a finished product that will do what he needs, out-of-the-box. He was very happy with Flex (until he needed a custom component, but that gets back to the creator). He is happy with solid components that are easy to use. He doesn’t want to know what the guts look like, and he doesn’t care, as long as it works well. This guy (me too by the way) would have an interface for each type of component: IButton, ICombo, IList. And though he might not even know those interfaces exist, he would know what each component could do and would be pleased with it. The component might be made up of reusable models, behaviors, etc. behind the shiny API, but he wouldn’t know or care.
Which way is best?
So, is one better than the other? Or are we just hitting two different types of users? The pro
for the first model is that it would be easy to create new components. The con would be the steeper learning curve for people using the components. If you’re a component creator you’re probably thinking “yeah whatever, that’s not a learning curve, not more than anything else,” but it really is. You have to understand how the components work. It’s so easy to just drop a component down and read that it supports a “label” property. Learning a front-facing API is easier than learning interactions. The pro for the second model would then be that it is easier to learn and use. The con, it could be implemented poorly underneath that nice interface, and would thus be hard to extend, modify, reuse. Here we have Flex (no offense Flex team). It’s getting better, especially with Flex 4, but backwards compatibility always has costs, and there is still a lot of cobwebs in there. So, I suppose we could have reusable pieces in the implementation, but have the interfaces stay out of that and simply give us good API. If we made it easy for component users with
shiny front-facing interfaces, and used behaviors and all that complex stuff under-the-hood so to speak, we could end up with easy components that were still extendable and reusable.