input-time-zone
can lose selection on change
#11128
Labels
3 - installed
Issues that have been merged to master branch and are ready for final confirmation.
ArcGIS Field Apps
Issues logged by ArcGIS Field Apps team members.
bug
Bug reports for broken functionality. Issues should include a reproduction of the bug.
calcite-components
Issues specific to the @esri/calcite-components package.
estimate - 2
Small fix or update, may require updates to tests.
impact - p1 - need for current milestone
User set priority impact status of p1 - need for current milestone
p - high
Issue should be addressed in the current milestone, impacts component or core functionality
regression
Issues that are caused by changes in a release, but were working before that.
Milestone
Check existing issues
Actual Behavior
Given a time-zone input this is updated programmatically: If the input's
messages
,mode
, and/orreferenceDate
props are set at the same time thevalue
prop is, the matching combobox-item (if there is one) is not selected or loses its selection.Expected Behavior
The matching combobox-item, if any, is selected or remains selected.
Reproduction Sample
https://codepen.io/nwhittaker-esri/pen/XJrRgeB
Reproduction Steps
offset
passed to thesetTimeZone()
function to be different from your own.<calcite-input-time-zone>
input's value is cleared instead of matching the offset established in step 2. If it appears to work, try clicking the button a few times and/or clicking the input itself to force a repaint.referenceDate
to see the expected behavior.Reproduction Version
2.13.2
Relevant Info
I believe the issue stems from a race condition in the component's
handleTimeZoneItemPropsChange
method:calcite-design-system/packages/calcite-components/src/components/input-time-zone/input-time-zone.tsx
Lines 145 to 146 in e38e297
The time-zone selection is not waiting for the new list of time-zones. As a result it's finding itself in the old list of time zones which means it never matches a time-zone item in the
renderItems()
method.I suspect making the
handleTimeZoneItemPropsChange
method asynchronous and awaiting the call toupdateTimeZoneItems()
would be enough to clear up the issue:Regression?
2.12.2
Priority impact
impact - p1 - need for current milestone
Impact
I'm readily encountering this error in a component that constructs
<calcite-input-time-zone>
inputs in JSX following a data-down/action-up architecture. As a result, the component's rendering engine is setting/updating props on the inputs frequently and in batches. In this less contrived scenario, the inputs' are unusable as their values are almost always cleared after the user makes a selection.A workaround may be to set the
messages
,mode
, and/orreferenceDate
props separately from thevalue
prop. However, this adds a degree of complexity that's difficult to generalize.Calcite package
Esri team
ArcGIS Field Apps
The text was updated successfully, but these errors were encountered: