input-time-zone
can lose selection on change
#11128
Labels
2 - in development
Issues that are actively being worked on.
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: