toString children of title

[sebmarkbage]

children of title can either behave like children or like an attribute. We're kind of treating it more like an attribute now so we should support toString/valueOf like we do on attributes.

[sizebot]

Comparing: d4bc16a...b809f3d

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	+0.02%	154.33 kB	154.37 kB	+0.04%	48.96 kB	48.97 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	+0.02%	156.26 kB	156.29 kB	+0.04%	49.61 kB	49.63 kB
facebook-www/ReactDOM-prod.classic.js	+0.05%	532.87 kB	533.12 kB	+0.03%	94.93 kB	94.96 kB
facebook-www/ReactDOM-prod.modern.js	+0.05%	517.97 kB	518.22 kB	+0.03%	92.73 kB	92.76 kB
facebook-www/ReactDOMForked-prod.classic.js	+0.05%	532.87 kB	533.12 kB	+0.03%	94.93 kB	94.96 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
facebook-www/ReactDOMServer-prod.modern.js	+0.25%	123.42 kB	123.72 kB	+0.10%	23.39 kB	23.41 kB
facebook-www/ReactDOMServer-prod.classic.js	+0.24%	126.55 kB	126.86 kB	+0.10%	24.01 kB	24.03 kB
facebook-www/ReactDOMServerStreaming-prod.modern.js	+0.24%	128.54 kB	128.85 kB	+0.10%	24.70 kB	24.72 kB

Generated by 🚫 dangerJS against b809f3d

[sophiebits]

Does this match how textarea and option work?

[sebmarkbage]

I think there's a mismatch between SVG on the server and SVG on the client, unless I'm missing a special case.

[sebmarkbage]

Does this match how textarea and option work?

Those are not matching each other but that's the intention.

option is a mess that uses React.Children.

textarea doesn't ignore function and symbol, which maybe it should since attributes do.

[sebmarkbage]

<option> is different because it actually renders the children as children. It also flattens it for the purpose of comparing the currently selected value. That might not line up exactly which is probably a bug somewhere.

[gnoff]

I think there's a mismatch between SVG on the server and SVG on the client, unless I'm missing a special case.

Yeah this is tricky. on the client a title in svg is treated like a component and there is no prohibition on children (except that now it would be valid to use a toStringable on the server but not on the client for a title in an svg.

[gnoff]

As you pointed out client svg titles don't have parity of rendering behavior on server/client with the current implementation

<svg><title>hello {'world'}</title></svg>

// renders on server as
<svg><title /></svg>

// renders on client as
<svg><title>hello world</title></svg>

granted that should warn on the server so you wouldn't be totally surprised by it but it would also fail on hydration on the client

We could special case children for title in ReactDOMComponent and have it do the same kind of toStringing but that's a branch in a very hot function that will nearly never be used. We can also have non-resource titles have old rendering semantics and change the warning so it doesn't warn when you are a title in an svg

[gnoff]

this would cause <svg><title>hello {"world"}</title></svg> to render null if enableFloat is true and hello <!-- -->world if enableFloat is false. Is it ok to put these same restrictions on svg titles?

[sebmarkbage]

that doesn't change with this PR. that was already happening because it was setting child to be an array which is an object and so is ignored.

The inconsistencies already exist. Just trying to add the toObject for now to unblock and then we can follow up with fixes.