Storybook: addon-controls text input cannot handle Japanese (most likely all CJK text)

[brandonpittman]

Describe the bug
addon-controls' text-input doesn't handle Japanese typing events. Most likely caused by listening to oninput instead of onchange. Pasted Japanese text displays normally.

To Reproduce

1. Create a control that has a text input
2. Try typing Japanese directly into input (ex. 編集）
3. See garbled string

Expected behavior
Input contains string "編集". Copying and pasting this string will display expected result. Actually typing the text into the input causes the error.

Screenshots
https://www.loom.com/share/5310ef1bd23e4f07b9c93ee528d0c948

System:

Environment Info:

  System:
    OS: macOS 10.15.5
    CPU: (8) x64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
  Binaries:
    Node: 14.3.0 - /var/folders/q6/mtqdcmhs7nl4zxxpdf0tr_xm0000gn/T/fnm-shell-1945621/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.5 - /var/folders/q6/mtqdcmhs7nl4zxxpdf0tr_xm0000gn/T/fnm-shell-1945621/bin/npm
  Browsers:
    Chrome: 83.0.4103.116
    Safari: 13.1.1
  npmPackages:
    @storybook/addon-controls: ^6.0.0-beta.37 => 6.0.0-beta.37
    @storybook/addon-docs: ^6.0.0-beta.37 => 6.0.0-beta.37
    @storybook/angular: ^6.0.0-beta.37 => 6.0.0-beta.37

[shilman]

ありがとうございました. can confirm the issue in controls (and also that it's not an issue in addon-knobs, so hopefully it shouldn't be too hard to track down). thanks!

[brandonpittman]

@shilman Thanks! I work for a Japanese company and I'm starting the Storybook adoption process here and not being able to use Japanese in the controls addon would be a huge bummer.

[shilman]

@brandonpittman i've lived in japan, korea, and currently in taiwan so i'm a bit embarrassed about this one. hopefully we can fix it soon, tho it turns out that it's not as easy as i'd hoped to track down.

both controls (new, broken code) and knobs (old, working code) effectively have the same logic:

export const TextControl: FC<TextProps> = ({ name, value, onChange }) => {
  const handleChange = (event: ChangeEvent<HTMLTextAreaElement>) => {
    onChange(name, event.target.value);
  };
  return <Form.Textarea id={name} name={name} value={value} onChange={handleChange} size="flex" />;
};

in both cases, it is a "controlled component" where the value is passed in and the onChange hooks into an external state management system. there's something different about the value that's getting passed in and i'm wondering if you know enough about CJK to help me debug.

i was using korean ㅁㅏㄴ vs 만. is there a version of the string "ㅁ" that is "open to adding more characters to, and a version of the string "ㅁ" that is "end of character"? if so, how would i programmatically convert from the former to the latter? my hypothesis is that the args state management system is unintentionally making that conversion, whereas the knobs state management is not. since they are using the exact same Form.Textarea component.

UPDATE: I replaced the knobs component with a nearly identical copy of the controls component and have confirmed it's an issue in the state management side cc @ndelangen @tmeasday

[brandonpittman]

@shilman 9/10 of these sorts of issues are the events catching changes in the middle of character conversion. I’m interested to know what state management issue would be causing something so similar. Will keep following.

[tmeasday]

@shilman where in the stack does it go from being "correct" to "broken"? Are the events on the channel correct or incorrect (and compared to knobs)?

[ndelangen]

• If we make it an uncontrolled input, the characters combine properly
• the event send TO the preview already contains the incorrect string
• if we start using the value from useState the issue starts

[shilman]

Ermahgerd!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.0.0-beta.44 containing PR #11430 that references this issue. Upgrade today to try it out!

You can find this prerelease on the @next NPM tag.

Closing this issue. Please re-open if you think there's still more to do.

[brandonpittman]

@shilman I'll never be able to test this, because the Angular stuff's still broken when I open controls.