Affects Version/s: Apache Flex 4.9.0
Fix Version/s: None
Component/s: Spark: DropDownList
Run the attached application, and press one of the two buttons on the left.
Actual behaviour: the selectedItem should represent the owner of that job, but it's now wrong because the selectedItem has been assigned before the dataProvider, so the first item in the list has been selected (and set in the model) instead, because requireSelection was "true" in the dropdownlist.
Desired behaviour: not sure, but modifying the model with invalid data because of the timing of assignments in a visual component (without any user input) feels unintended and definitely surprising. We have lots of forms in our application, and the team spent an aggregate of around two weeks chasing various bugs that all came down to the timing between assigning selectedItem and dataProvider in dropdowns.
A few suggestions:
-to keep the problem discoverable, but not mess up the model, there could be an additional property on the dropdownlist called userSelectedItem, to which the developers could safely bind two-ways, as the trigger would only fire for the "change" event - thus, when the user selects an item from the list. Please see ExtendedDropDownList in the project for an example. When we bind to userSelectedItem, the selection in the dropdown is still wrong, but the model is intact (replace DropDownList with ExtendedDropDownList in _DropDownDoubleBound.mxml and two-way bind to userSelectedItem instead of selectedItem).
-the binding trigger event could be "change" instead of "valueCommit" ("dispatchEvent(new FlexEvent(FlexEvent.VALUE_COMMIT));" in ListBase.commitSelection() seems to trigger the bindings now.)
-the DropDownList could throw an error when the selectedItem cannot be found in the dataProvider.
All the potential solutions above have benefits and drawbacks, but I guess it might be a good idea to start a discussion on what the best direction could be for this issue.