[addon-controls] select options object format is reversed

[y-nk]

Describe the bug

To Reproduce
Steps to reproduce the behavior:

Build any story with addon-controls and :

argTypes: {
  prop: {
    control: 'select',
    options: { val1: 'Value 1', val2: 'Value 2' },
  }.
}

Expected behavior
The <select> should display a list of "Value 1, Value 2" and the story should receive "val1, val2" as arg.

What is happening instead
The <select>displays a list of "val1, val2" and the story receives "Value 1, Value 2" as arg.

System

Environment Info:

  npmPackages:
    @storybook/addon-a11y: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/addon-actions: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/addon-backgrounds: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/addon-controls: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/addon-storysource: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/addon-viewport: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/addons: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/client-api: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/react: ^6.1.0-alpha.17 => 6.1.0-alpha.17
    @storybook/theming: ^6.1.0-alpha.17 => 6.1.0-alpha.17

Additional notes
Current dirty patch involves:

    control: {
      type: 'select',
      options: Object.fromEntries(Object.entries(mockUp).map(arr => arr.reverse())),
    },

┆Issue is synchronized with this Asana task by Unito

[shilman]

Is this actually a bug? Arg names must be strings, but arg values can be anything. So the current schema makes more sense to me than the proposed reversal.

[bryantee]

Would be great if the docs showed the options list as an object as suggested above, since current examples really only show the array syntax.

[VladimirCores]

We experience the problem when the selected option does not have "title" (object key) displayed in select field.

And object defined like this:

We assign them like:

Any ideas why this happens?

[pavelspichonak]

I have the same issue as @VladimirCores has. @VladimirCores did you find out why this happens?

[pavelspichonak]

@shilman looks like I found out when we have the issue described by @VladimirCores.

When value of option is string it works great. But when the value of option is object it works like @VladimirCores described.

this works good:
options: { option1: "option1Value", option2: "option2Value" }

but this has issue:
options: { option1: { someProp: "somePropValue" }, option2: { someProp: "somePropValue" } }

[majard]

We are experiencing the same problem by @VladimirCores too.

[ghengeveld]

Control options must be simple strings so they can be serialized and synced to the URL. Control options can still be defined as an object, but it must be a string -> string mapping. The only use case I see is if you want a custom select label that may not be serializable (e.g. outside the [a-z0-9 _-] range). For example: options: { да: 'yes', нет: 'no' }

To allow any kind of value to be used and controlled as arg, we're working on a new mapping feature in #14100. It will not fix the bug explained above, but it will provide a workaround. It will also log a warning when it encounters an object as value in options, and suggest to use mapping instead.

[ghengeveld]

As of Storybook 6.2, control.options is deprecated in favor of options (one level up), which only accepts an array. With that, we've circumvented the "object format is reversed" problem.

As mentioned before, we've introduced mapping to allow for complex arg values.

We've also introduced control.labels to allow you to configure custom labels for your checkbox, radio or select input.