[bug][16.5.0] option returns [object Object] instead of string

[aso1datov]

What is the current behavior?
<option> returns [object Object] instead string

Demo: https://codesandbox.io/s/ww5mv2w957

What is the expected behavior?
Expected string

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

[jquense]

FormattedMessage doesn't render a string, it renders a span which is not valid HTML for the inside of an option tag. You should use intl.formatMessage() directly or try setting the https://github.com/yahoo/react-intl/wiki/Components#intlprovider textcomponent to React.Fragment to avoid the extra span

[aso1datov]

@jquense
Sorry, forgot add default tag for FormattedMessage
It doesn't work with React.Fragment too.

[bvaughn]

For what it's worth, the same Code Sandbox works with React 16.4 but not 16.5.

Maybe related to #13465? cc @gaearon

I don't have context on that change, so I'm not sure if this outcome is expected/okay or not.

[Simek]

If you remove option tag and add tagName property to FormattedMessage demo works correctly.

Fork: https://codesandbox.io/s/6yr4xy5ll3

[jquense]

It doesn't work with React.Fragment too.

we should make this work probably as well.

IDK how to categorize this breakage, it worked solely because of how forgiving browsers can be (which is not unlimited causing the original bug), but the markup is definitely incorrect. It also definitely broke something that "worked" before

[quazzie]

Does not work with a context consumer inside a option either.
https://codesandbox.io/s/pk574rm207

[bvaughn]

I'm going to tag this as a regression for now, at least until we're sure one way or another.

[Simek]

@quazzie You can fix that by wrapping value in option tag inside context Consumer render function.

Fork: https://codesandbox.io/s/oom712ov79

[quazzie]

@Simek thanks but in my real app i use a component that uses context internally so i can't really use that.
<option><MyComponent value="value" /></option>
and MyComponent uses a context.Consumer, processes value a bit and returns a string.

[quazzie]

@bvaughn yeah it seems to be connected to #13465
It seems you can't use any component as child to option.
Test with simple functional component yields same problem:
https://codesandbox.io/s/7y5km7r7k6

[Simek]

@quazzie Sure thing, it seems like it's a regression.

For now if you want you can implement tagName property and pass option as value to component in your app. If property has been provided you can wrap String inside component otherwise you can just return String.

To be clear I'm just providing quick solutions until React team decided how to solve that issue.

[gaearon]

I don't think it was strictly a regression. This is kind of a thorny area. It was never intentionally supported. It accidentally worked on initial mount but then crashed on updates (#13261). Fixing the crash was more important, so we fixed it to be treated as text content (which it should be). Unfortunately this means putting custom components in the middle is not supported. That's consistent with how textarea and similar elements work.

I think it's better to show invalid output and warn about something that breaks on updates, than to let people use it only to discover it crashes in production. But I can see arguments for why this should be supported when the custom component returns a string. Unfortunately I don't know how to fix it in a way that would both solve the update crashes and support text-only content. I think for now it's reasonable to say putting custom components into <option> doesn't really work (and never quite worked correctly), and ask you to manually provide a string to it.

[gaearon]

React 15 also warned about this but we accidentally lost the warning in 16 for cases when components return a string.