Setting combobox/select value does not always select matching item/option

[nwhittaker]

Check existing issues

• I have checked for existing issues to avoid duplicates

Actual Behavior

Given a <calcite-combobox> or <calcite-select> element containing <calcite-combobox-item> or <calcite-option> children with non-string value props, setting the parent's value prop does not select the matching child.

Expected Behavior

Possible options:

1. The matching child is selected and the parent's value type matches the child's value type.
2. Typing is changed on combobox-item and option components such that their respective value props are typed as string instead of any.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/OJYzqvz

Reproduction Steps

1. Visit the repro sample
2. Click the Set number value and Set numeric string value buttons and see the corresponding item/option is not selected
3. Click the Set string value and see the corresponding item/option is selected.

Reproduction Version

2.9.0

Relevant Info

If the typing allows for it, setting a non-numeric value is an easy pit to fall into when using these components inside a templating language like JSX or Ember. If the any typing is preserved, it'll be important to verify that comparisons between falsy values don't match: false, 0, '', etc…

Regression?

No response

Priority impact

impact - p3 - not time sensitive

Impact

The issue is easily worked around, but can be hard to debug since the typing is ostensibly correct.

Calcite package

• @esri/calcite-components
• @esri/calcite-components-angular
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Field Apps

[jcfranco]

This should be fixed in the upcoming release (3.0.0) (see updated codepen).

Note: Set numeric string value will remain unmatched because the values aren't equal.

[geospatialem]

Verified with Franco's codepen mentioned above with 3.0.0-next.45. 🎉