InputControl: remove default value argument from Storybook

[ciampo]

What?

Fixes a bug in InputControl's Storybook example, where currently it's not possible to interact with the component and enter a custom value

Why?

This is probably an unwanted side-effect introduced in #40119

How?

This PR removes value: '' from the list of default arguments for each Storybook example.

Testing Instructions

Open Storybook, make sure that it's possible to enter a custom value in the InputControl component and that the value is persisted after the input loses focus.

Make sure that any text manually set as the value via Storybook controls overrides every other text entered by the user.

Screenshots or screencast

Before:

input-control-value-before.mp4

After:

input-control-value-after.mp4

[mirka]

Ah interesting!

The reason I added a value was so that the code snippets would show a stub value prop, which is one of the main props that the consumer will need to use.

I think the underlying tension is between wanting to showcase it simply as an uncontrolled component vs. showcasing it as a controlled component, the latter of which is how almost every consumer would use it.

I can think of two ways to somewhat reconcile this tension:

1. Show the "complete" manual code snippet as defined in the main JSDoc comment a23ae2b. This is my preferred approach. It's low maintenance for us, and friendly for consumers. The stories themselves can remain simple (uncontrolled).

   

2. Switch stories to the controlled usage, and disable the Control for the controlled prop (as suggested in this article) 409b688. This would at least give us stubbed props for onChange and value in the code snippets, acting as a
   "minimum viable" code sample for the time being.

   

What do you think?

[ciampo]

I also prefer option 1, but I also pushed a commit that introduces the "controlled" version as a separate story — maybe this could be the best compromise overall, what do you think?

I'm also happy to revert my changes and only include what we called "option 1"

[mirka]

I also prefer option 1, but I also pushed a commit that introduces the "controlled" version as a separate story — maybe this could be the best compromise overall, what do you think?

At the moment I don't have a strong opinion either way, but I'm curious what you think the purpose of the controlled story is. My worry is that it could be confusing to be there in the Docs view with no explanation, and with an "incomplete" autogenerated code snippet.

I noticed one benefit of having it, which is to have the use case be type checked. Like I noticed that this code sample in the JSDoc throws a type error for the onChange:

gutenberg/packages/components/src/input-control/index.tsx

Lines 100 to 107 in 4cc6042

	* const [ value, setValue ] = useState( '' );
	*
	* return (
	* <InputControl
	* value={ value }
	* onChange={ ( nextValue ) => setValue( nextValue ) }
	* />
	* );

Though if it's just for type checking we could move it to a unit test.

[ciampo]

My worry is that it could be confusing to be there in the Docs view with no explanation, and with an "incomplete" autogenerated code snippet.

You make a good point, let's not have a controlled story at least for now (it's always something that we can add later if we feel like we need it).

I went ahead and removed the controlled story, and then fixed the JSDoc snippets by adding a fallback empty string value in the onChange callback

[mirka]

Let's go with that! 🚢

[mirka]

Just noticed it's under the wrong version heading 🧹