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.

Component Creator

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.

Component User

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

Share this:

3 Responses to “Component Architecture, Two Approaches”

I think this begs the question “are the two approaches really mutually exclusive?” I don’t think they are. I believe that in most cases, there’s nothing but lazyness (which to be honest is usually better described as shortcomings in the toolset) that keeps developers going for inheritance rather than composition, and few rather than many composable interfaces.

I guess by stating my preference for composition I’m just declaring myself a component creator. But I agree with Josh.

Realistically you could create all the Legos, and then also build a component out of them. This would allow the “component user” to use the polished component, and allow the “component creators” to use the individual Legos to build his own component.

If you just build entire components then you’re recreating Flex (to a certain extent) and there’s nothing interesting about that. But if you were to build the Legos, I could see myself giving up Flex altogether to get in on that action!

I love OpenFlux, and I haven’t used Stealth but I’ve looked at the source code and it looks pretty good to me. I’m looking forward to what you guys come up with.

And for the record, my favorite names I’ve heard for the framework are Phoenix and Zoe/Zoey … not sure why.