[Input] Setting .value before render() throws an error

[maxpatiiuk]

Check existing issues

• [X] I have checked for existing issues to avoid duplicates

Actual Behavior

calcite-input has a watcher on value property. When watcher triggers, it updates the HTML element:

https://github.com/Esri/calcite-design-system/blob/c99be674d3bb3b721ce0e8d39b0cb266b5aac840/packages/calcite-components/src/components/input/input.tsx#L976-L984

If .value property is set after component's constructor() (because Stencil watchers are disabled before that), but before render() (because .childEl ref is set after render()), the above watcher will fail with this exception:

TypeError: Cannot set properties of undefined (setting 'value')

The issue is that while the watcher checks for this.childEl being undefined, it only does so when input type is text. This might be an artifact back from when this input only support number and input types?

Expected Behavior

Setting value should not produce an exception

Reproduction Sample

https://codepen.io/maxpatiiuk/pen/ZEgGWod?editors=1010

Reproduction Steps

1. Set .value property or a calcite-input with a type not equal to text and not equal to number after component's constructor() triggered but before render()
2. See exception in the console

Reproduction Version

2.13.0

Relevant Info

No response

Regression?

No response

Priority impact

impact - p3 - not time sensitive

Impact

No response

Calcite package

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

Esri team

N/A

[maxpatiiuk]

Side node:

this line in the watcher has several issues:

this[child${this.type === "number" ? "Number" : ""}El].value = newInputValue;

• Dynamic property access has worse performance - since there are only two possible properties, it's better to explicitly write out the two branches in an if/else
• This is less readable
• TypeScript is not as good at reporting type errors for such dynamic property accesses (especially on HTMLElement prototype)
• IDE go-to-definition and go-to-usages features don't work
• IDE "refactor -> rename" feature doesn't work
• Minification of private properties would break such dynamic reference.

[maxpatiiuk]

Changing the setInputValue like this seems to fix the issue:

  private setInputValue(newInputValue: string): void {
    if (this.type === "number" && this.childNumberEl) {
      this.childNumberEl.value = newInputValue;
    } else if (this.childEl) {
      this.childEl.value = newInputValue;
    }
  }