Understanding the design of the List component

When you design an application with the List component, or any component that extends the List class, it is helpful to understand how the list was designed. The following are some fundamental assumptions and requirements that Adobe used when developing the List class:

Keep it small, fast, and simple.
Don't make something more complicated than absolutely necessary. This was the prime design directive. Most of the requirements listed below are based on this directive.
Lists have uniform row heights.
Every row must be the same height; the height can be set during authoring or at runtime.
Lists must scale to thousands of records.
Lists don't measure text.
This restriction has the most potential ramifications. Because a list must scale to thousands of records, any one of which could contain an unusually long string, it shouldn't grow to fit the largest string of text within it, or add a horizontal scroll bar in "auto" mode. Also, measuring thousands of strings would be too intensive. The compromise is the maxHPosition property, which, when vScrollPolicy is set to "on", gives the list extra buffer space for scrolling.

If you know you're likely to deal with long strings, turn hScrollPolicy to "on", and add a 200-pixel maxHPosition value to your List or Tree component. A user is more or less guaranteed to be able to scroll to see everything. The DataGrid component, however, does support "auto" as an hScrollPolicy value, because it measures columns (which are the same width per item), not text.

The fact that lists don't measure text also explains why lists have uniform row heights. Sizing individual rows to fit text would require intensive measuring. For example, if you wanted to accurately show the scroll bars on a list with nonuniform row height, you'd need to premeasure every row.
Lists perform worse as a function of their visible rows.
Although lists can display 5000 records, they can't render 5000 records at once. The more visible rows (specified by the rowCount property) you have on the Stage, the more work the list must to do to render. Limiting the number of visible rows, if at all possible, is the best solution.
Lists aren't tables.
For example, DataGrid components, which extend the List class, are intended to provide an interface for many records. They're not designed to display complete information; they're designed to display enough information so that users can drill down to see more. The message view in Microsoft Outlook is a prime example. You don't read the entire e-mail in the grid; the mail would be difficult to read and the client would perform terribly. Outlook displays enough information so that a user can drill into the post to see the details.

View comments on LiveDocs