Lately we''ve been getting a lot of questions about the proper way to use the methods in the Flex 3 Component LifeCycle. I wrote about this in the December Flextras newsletter and thought I'd turn it into a post here too.
The Flex Component Lifecycle is a set of methods and events that Flex uses to setup, size, and position the components that make up your Flex Application. There four lifecycle methods that you'll use when creating Flex Components: createChildren(), commitProperties(), measure(), and updateDisplayList(). I'll discuss each one individually.
createChildren()
The createChildren() method is aptly named. It is intended to create the children of the component. This is run as part of the initial component setup and is never run again. In our Calendar component's MonthDisplay class we use createChildren() to create the day name headers to display the day of the week and the month header which displays forward / next buttons, the month name and the year.
commitProperties()
I consider the commitProperties() method is a wild card method. You'll use commitProperties() to
coordinate component changes all at once. However, the exact use of this is a bit of a gray area. It depends what properties have changed and how they affect the component.
In many of the custom components I've built I find that I'm using commitProperties() as an alternative for createChildren(). In our Calendar component, I use it to create the month's days from a dayRenderer. This can't be done in createChildren() because we may not know the displayedMonth or displayedYear yet, and therefore can't determine the number of days in the week.
measure()
The measure() method will determine the ideal size of this component. Its' purpose is the most concretely defined of all the component lifecycle methods. This will set the measuredWidth, measuredHeight, measuredMinWidth, and measuredMinHeight properties on your component.
A component is always sized by its' parent; but if these properties are suggestions to that parent.
How you calculate the meauredWidth and measuredHeight is open to interpretation and depends on your component. In most cases, you'll examine each of the component's children and keeping some type of running tally. For our Calendar component's 'month display, we set measuredWidth to the width of the longest week. MeasuredHeight is calculated using sum of the heights of the largest day in each week.
The calculations take into account localization features, such as the first day of week.
I've experienced a few gotchas with the measure() method. First, if you specify an explicit height and width, the measure method will not be run. This is done for performance reasons. If you already know the height and width, why does the parent need suggestions from the
child? It doesn't!
Second, the documentation states that measuredMinWidth and measuredMinHeight are optional, but I have found this not to be the case. If these values are not set I've experienced situations where the width or height ended up being set to NaN, which interferes with sizing calculations up the component chain.
updateDisplayList()
The updateDisplayList() method is intended for changing the visual pieces of the component. It is great for setting the height and width of your children and positioning those children with the x and y coordinates. In the Calendar's MonthDisplay this will size and position all the days. Even though the measure() method assumes that individual days can contain have different height or widths,
updateDisplayList() forces all days to the same size. You may also use updateDisplayList for changing styles.
Final Words
So, in summary:
- createChildre(): Creates the component's children
- commitProperties(): Coordinates property changes
- measure(): Determines the ideal size of a component's children
- updateDisplayList(): Positions and sizes the children
Most of the work I do when building components for Flextras relates to use of one of these component lifecycle methods. The Flex 4 framework does bring quite a few changes along with a new component architecture. Perhaps I'll write about that another time.