@spicyj

Should we just treat children (and dangerouslySetInnerHTML) specially? It seems maybe-useful to cast other things to string.

Yeah, that's what my original diff (jimfb@a703c37) did, but then I thought about it and most of the coercions were mistakes. There are situations where we might want to treat non-string values differently (for instance, a function property following the pattern onXXX might be treated as an event handler). Figured we could always relax the coercion requirement in the future, but for now requiring it to be a string/number seems like a reasonable restriction. If you still want it changed, let me know, I don't have a strong preference.

Ping @spicyj. Have I convinced you that we should require all webcomponent props to be strings/numbers, and perhaps back off on this requirement later. Or would you prefer to go with the older diff (jimfb@a703c37). Or what's your thinking?

Regardless, this is a breaking change so it should not be a patch level release. It can go into 0.15.

@sebmarkbage Addresses a regression that we introduced; namely that we now set the children attribute to [Object object] for all web components.

Then we should do what @spicyj suggested and your original.

JS has lots of coercion. It's just how the language works. Silently ignoring isn't necessarily better. It is probably worse here since it becomes a breaking change rather than an isolated patch of the regression.

If you want to protect against it, use Flow or something like Restrict Mode on top.

@jimfb updated the pull request.

@spicyj @sebmarkbage PR updated; ready to merge?

@jimfb updated the pull request.

@jimfb I'm going to do another 0.14.2 soon so if you can fix up the last few things we can probably get this in there.

Although… I don't see history of when this got changed from 0.15 to 0.14.1, is it actually safe?

Done. I rebased. This was a regression introduced in 0.14, so it should be safe.

@jimfb updated the pull request.

Well, this doesn't quite bring us back to the same behavior of 0.13. So regression… sort of yes. But the changes here don't "fix" everything. I don't know what's right.

I think there's also an argument to be made for explicit use of the children prop vs the rest arg use. The rest arg use has clear intention of putting them as actual child nodes. The children prop is less clear (and unfortunately a big cloudy when we consider composition and {...this.props}).

React.renderToStaticMarkup(<my-component>5</my-component>)
React.renderToStaticMarkup(<my-component children={5}></my-component>)
React.renderToStaticMarkup(<my-component>{[5]}</my-component>)

// 0.13.3
'<my-component>5</my-component>'
'<my-component>5</my-component>'
'<my-component>5</my-component>'

0.14.1
'<my-component children="5">5</my-component>'
'<my-component children="5">5</my-component>'
'<my-component children="5">5</my-component>'

// With this
'<my-component children="5">5</my-component>'
'<my-component children="5">5</my-component>'
'<my-component>5</my-component>'

As you can see, you've only changed that last one. Which is consistent with the "not coercing children" issue as filed. Maybe that's correct and I should shut up, it just seems weird.

@zpao So the "correct" behavior, imo, is to have <my-component children="5" /> != <my-component>5</my-component> at the element level. It's fine if you want to merge children into props.children before passing them into composite components in order to preserve API, but at the element level they should be separate.

Sebastian wants (at least for now) us to drop the typeof checks, so I'll do that now.

@jimfb updated the pull request.

I think that it is likely that if we wanted to "standardize" the outline of a React Element, that other people might have opinion on this part of the structure. If it becomes necessary, I'd like to punt changing the React Element outline until that point.