InputControl: avoid uncontrolled to controlled warning

[ciampo]

What?

Make sure that the underlying <input /> in InputControl doesn't switch inadvertently from uncontrolled to controlled mode.

Why?

While working on #45982 and on #47246, I noticed that the "uncontrolled to controlled" warning was being logged even when it shouldn't have.

After some investigation with @mirka, we realized that InputControl always passes an explicit value prop to the underlying <input /> element, because of the component's internal state reducer.

This causes the "uncontrolled to controlled" warning to be logged when value of the input goes from empty to any value.

I will also note that this error doesn't probably get logged when using the editor because in most cases a fallback to an empty string is already provided by the component using InputControl (or any related component).

How?

Since React interprets an undefined value as a sign of an uncontrolled component, the fix here is to pass an empty string to <input /> instead of undefined (this is achieved via the ?? '' code).

Testing Instructions

About the error message:

• Checkout this PR.
• Remove the fix that this PR applies to the packages/components/src/input-control/input-field.tsx file
• Load the temporary "Uncontrolled" Storybook example. Input a value in the input field.
• Observe how the "uncontrolled to controlled" error message gets logged to console
• Apply the fix from this PR to the packages/components/src/input-control/input-field.tsx file
• Try again interacting with the "Uncontrolled" Storybook example, make sure that the error is not logged to console

Check that the component behaves as expected:

• In Storybook for InputControl and its derivatives (NumberControl, UnitControl, RangeControl, ....)
• In the editor, especially in the sidebar

Screenshots or screencast

Screencast of the error message logged to console that happens without the fix from this PR:

number-control-controlled-warning.mp4

[ciampo]

The test failures don't seem related to this PR, especially since they seem to happen across many other PRs as well.

[ciampo]

Please ignore the code comment, it's a left over from a copy-paste.

The whole Storybook example will be removed before merging, I'm just leaving around for ease of testing

[mirka]

While reviewing this PR, I also briefly thought about whether there are more appropriate places to put the fallback. For example, at the prop destructure point or the useInputControlStateReducer() call point. But I still think the place we currently have it is the most appropriate, because the string fallback is only necessary where our value interfaces with React <input> 👍