Using class properties on custom components to reduce the size of Flex applications
When you build a custom component inheriting from UIComponent and you want to provide the ability for the end user to configure your component using different modes, you have to provide a property that will let him choose which mode to use.
This property can be a string that will describe the mode. An example of that is the type property on the ColumnChart class of the Flex framework that let you choose between the clustered, overlaid, stacked and 100% modes. Let’s call that way of configuring the component the “string configuration”.
But the property can also be a class that will be in charge of configuring the component by having the component delegate some task to it. An example of that is the itemRenderer property on the ListBase class of the Flex framework that let you choose how you want each item to be rendered. Let’s call that way of configuring the component the “class configuration”.
From the description above it sounds obvious that when you have a predefined set of modes and that the modes are not extensible you want to go with the “string configuration” and conversely if you want to let the user provide his own delegate for a particular task you use the “class configuration”.
That’s indeed how most of the time you will proceed. However even when using a predefined set of modes, the “class configuration” can still be useful. Indeed if the code dealing with a particular mode is quite heavy you might not want to include all the possible modes code into the end-user final application? You can pretty easily prevent this by relying both on the fact the Flex compiler is by default including only the classes that are referenced by an application and on the “class configuration” methodology.
Let’s imagine that the different types of ColumnChart layouts can be extracted in four classes: ClusteredLayout, OverlaidLayout, StackedLayout and OneHundredLayout. And that the code involved in each layout is big enough for us to try to not include all of them in our users applications. Instead of doing:
<mx:ColumnChart type="stacked"/>
You would do:
<mx:ColumChart type="StackedLayout"/>
The type setter code corresponding to the first snippet would be something like:
switch (value) {
case "clustered":
_delegate = new ClusteredLayout();
break;
case "stacked":
_delegate = new StackedLayout();
break;
// and so on
}
With the consequence of referencing by default all the heavy classes in our component and thus including them in our final SWF.
The type setter code corresponding to the second snippet would just be something like:
_delegate = new value();
Which would have as consequence of including just the class used in the MXML (here the StackedLayout class) and thus reducing the size of the application SWF file.
Reading this, you might believe you should always use “class configuration” instead of “string configuration” even for predefined set of modes. However this is not as simple as this, indeed once you have done that you will not get anymore the nice code hinting and property view editing you get in Flex Builder with a “string configuration” using metadata such as:
[Inspectable(category="General",
enumeration="stacked,100%,clustered,overlaid",
defaultValue="clustered")]
That metadata prevents the user of the custom component from typing a meaningless value and provides him with the possible choices.
So as usual it is a matter of trade-off, if you think you can save significant SWF size with using “class configuration”. go for it. But don’t forget that then the user experience of configuring the component will be harder than when relying on “string configuration”.
Ideally Flex metadata and Flex Builder should support a way to provide code hinting and/or string short cuts while still using the “class configuration” methodology. That would give us the best of both worlds 
Tags: custom components, Flex, SWF size
