Summary
After upgrading react-aria-components (we observed this around v1.16), ComboBox appears to call onSelectionChange(null) when the field loses focus (e.g. user tabs or clicks away) without the user having cleared the selection through an explicit action (e.g. a dedicated clear control).
In earlier versions we used, blur did not surface a null selection to onSelectionChange in this situation.
Why this matters
For controlled usage, we were using:
onSelectionChange={(key) => setSelectedKey(key)}
If null is reported on blur while the user still “has” a logical selection, parent state is cleared unintentionally.
Guards such as “only update if key !== previousKey” are not sufficient because null !== 'some-key' is true, so the spurious null still updates the state.
We worked around this by only forwarding null when the user explicitly clears (e.g. our clear button sets a flag before setSelectedKey(null)), and ignoring null from other sources (including blur). That restores prior semantics for our product, but is easy to get wrong.
Questions for the React Aria team
-
Is onSelectionChange(null) on blur intentional in v1.16+? If yes, what’s the recommended pattern for apps that want “blur must not clear selectedKey”?
-
If intentional, could this be called out in release notes/migration docs so controlled ComboBox users can adjust without silent regressions?
-
If unintentional, is a fix planned?
Expected behavior (from our perspective)
- onSelectionChange(null) should mean the selection was cleared by user action or API, not that focus left the combobox.
Actual behavior
onSelectionChange(null) fires when the user blurs without selecting an item / without using clear (exact conditions we see: focus out after interaction, with an existing selection still intended by the app).
Environment
Library: react-aria-components (~1.16 when we noticed the change; previously on an earlier 1.x)
Component: ComboBox
React: (18/19)
References
Our downstream workaround: ignore null unless the clear path set an “explicit clear” flag before setSelectedKey(null).
🔦 Context
No response
💻 Code Sample
No response
Version
No response
What browsers are you seeing the problem on?
No response
If other, please specify
No response
What operating system are you using?
No response
Summary
After upgrading react-aria-components (we observed this around v1.16), ComboBox appears to call onSelectionChange(null) when the field loses focus (e.g. user tabs or clicks away) without the user having cleared the selection through an explicit action (e.g. a dedicated clear control).
In earlier versions we used, blur did not surface a null selection to onSelectionChange in this situation.
Why this matters
For controlled usage, we were using:
onSelectionChange={(key) => setSelectedKey(key)}
If null is reported on blur while the user still “has” a logical selection, parent state is cleared unintentionally.
Guards such as “only update if key !== previousKey” are not sufficient because null !== 'some-key' is true, so the spurious null still updates the state.
We worked around this by only forwarding null when the user explicitly clears (e.g. our clear button sets a flag before setSelectedKey(null)), and ignoring null from other sources (including blur). That restores prior semantics for our product, but is easy to get wrong.
Questions for the React Aria team
Is onSelectionChange(null) on blur intentional in v1.16+? If yes, what’s the recommended pattern for apps that want “blur must not clear selectedKey”?
If intentional, could this be called out in release notes/migration docs so controlled ComboBox users can adjust without silent regressions?
If unintentional, is a fix planned?
Expected behavior (from our perspective)
Actual behavior
onSelectionChange(null) fires when the user blurs without selecting an item / without using clear (exact conditions we see: focus out after interaction, with an existing selection still intended by the app).
Environment
Library: react-aria-components (~1.16 when we noticed the change; previously on an earlier 1.x)
Component: ComboBox
React: (18/19)
References
Our downstream workaround: ignore null unless the clear path set an “explicit clear” flag before setSelectedKey(null).
🔦 Context
No response
💻 Code Sample
No response
Version
No response
What browsers are you seeing the problem on?
No response
If other, please specify
No response
What operating system are you using?
No response