fix: support controlled and uncontrolled states in form components

[chrispulsinelli-okta]

Supporting controlled and uncontrolled usage of form elements

Tip

I highly recommend reviewing this PR commit by commit as I have logically broken down the changes into pieces that belong together. This is recommended as there are a lot of file changes related to the upgrade to Storybook. Fixes, features and tests are logically split by commits.

Changes summary

• Adding controlled and uncontrolled support for Select, NativeSelect, SearchField, PasswordField and TextField
• Updated stories with controlled cases and made existing stories all uncontrolled, explicitly
• Updated types on components to support controlled and uncontrolled usage of components
• Upgraded Storybook library to get rid of an issue that was appearing in dev tools console
  • Storybook was updated to 5.x to get the fix for the errors as seen in this GH issue: [Bug]: TypeError: Cannot read properties of undefined (reading 'count') with onClick action storybookjs/storybook#23787
  • I have tested the stories in Storybook and everything seems to be working fine after the upgrade.

Component changes

Select

Breaking change: must be declared with defaultValue for uncontrolled or value for controlled
defaultValue:

• "" for no default selected values
• string for value(s) to be selected by default (comma-separated string if hasMultipleValues is true)
• undefined otherwise

value:

• "" for no pre-selected value,
• [""] for no pre-selected values (if hasMultipleValues is true)
• string for selected value,
• string[] for multiple pre-selected values,
• undefined otherwise

NativeSelect

Breaking change: must be declared with defaultValue for uncontrolled or value for controlled
Breaking change: deprecated isMultiSelect to bring this in line with Select props and added hasMultipleChoices
defaultValue:

• "" for no default selected values
• string for value(s) to be selected by default (comma-separated string if hasMultipleValues is true)
• undefined otherwise

value:

• "" for no pre-selected value,
• [""] for no pre-selected values (if hasMultipleValues is true)
• string for selected value,
• string[] for multiple pre-selected values,
• undefined otherwise

SearchField

Breaking change: user must provide either a defaultValue or value for when the component should be uncontrolled or controlled, respectively
defaultValue:

• "" for empty, uncontrolled input
• string for value to be pre-populated in input
• undefined otherwise

value:

• "" for no initial controlled value,
• string for initial controlled value,
• undefined otherwise

PasswordField

Breaking change: user must provide either a defaultValue or value for when the component should be uncontrolled or controlled, respectively
defaultValue:

• "" for empty, uncontrolled input
• string for value to be pre-populated in input
• undefined otherwise

value:

• "" for no initial controlled value,
• string for initial controlled value,
• undefined otherwise

TextField

Breaking change: user must provide either a defaultValue or value for when the component should be uncontrolled or controlled, respectively
defaultValue:

• "" for empty, uncontrolled input
• string for value to be pre-populated in input
• undefined otherwise

value:

• "" for no initial controlled value,
• string for initial controlled value,
• undefined otherwise

OKTA-669322

Summary

Testing & Screenshots

• I have confirmed this change with my designer and the Odyssey Design Team.

[bryancunningham-okta]

Not sure this comment will always be accurate. We use this util in other inputs besides checkbox and radio right?

[chrispulsinelli-okta]

Ah yea it's not relevant. I'll remove it. It's an artifact leftover from initial concept work on this.

[bryancunningham-okta]

@chrispulsinelli-okta This looks good to me. But, we should probably wait and let @KevinGhadyani-Okta have a look. Also curious how much disruption we may cause with this change

[benschell-okta]

I like how explicit things are in inputUtils.ts ; agree with Bryan's comment about adjusting the comment (I think this is dev artifact)

[chrispulsinelli-okta]

@bryancunningham-okta there may be some cases where we break functionality where users are using the impacted components in this PR, but I feel that may be minimal. Most of the time, I suspect users will want to use these components in a controlled manner and a good portion of these changes were to support uncontrolled use cases.
There were bugs though where users wanted to use it in a controlled way and the component(s) weren't fully allowing that to happen (select, for example).
There are folks waiting on these changes (especially for Select) and my preference is to not let them wait much longer, but I do understand you wanting to have Kevin also look at it.

I do believe these components to be functioning as expected and to the spec required for controlled and uncontrolled usage. If there are non-functional changes Kevin wants (syntax, formatting, etc.) we can always address that when he's back as well.

[bryancunningham-okta]

@chrispulsinelli-okta Yeah, that sounds good to me. Agreed that we can fast follow if need be.

How are we planning to communicate any possible breaking functionality? This question is mainly for my own learning. So, if/when I do create breaking changes, I know what the process is for communicating them to the broader team.