`inlineElements` optimization breaks on older browsers; discussion about Symbols and React.elementFromObject() API

[STRML]

See this babel/babel#2517 and the associated discussion around the PR babel/babel#2518, which I don't expect to be merged due to loader issues.

To recap:

The inlineElements optimization requires brittle knowledge of internal React values, namely, $$typeof. This breaks on older browsers unless the developer globally polyfills Symbol, because Symbol will be polyfilled automatically by Babel in the user's code, but will not be polyfilled in the React library. This causes ReactElement.isValidElement to fail as Symbol.for('react.element') !== 0xeac7.

Worse, this bug only occurs in older browsers that don't implement Symbol, meaning that many devs won't catch it right away as it will work fine in FF, Chrome, and (latest) Safari.

This is a hard issue to fix without globally polyfilling Symbol or giving up on the use of Symbol for $$typeof. Babel could automatically this as part of enabling the optimisation, but @loganfsmyth had a better idea - how about a React.elementFromObject() API?

This function would be nothing more than:

React.elementFromObject = function(obj) {
  invariant(obj && typeof obj === 'object', "Supply an object to React.elementFromObject.");
  obj.$$typeof = REACT_ELEMENT_TYPE;
  return obj;
}

This ensures that the REACT_ELEMENT_TYPE we are using is equal to the one used in ReactElement.isValidElement. It shouldn't be necessary to do any validation in elementFromObject because it will be caught by isValidElement later on.

Thoughts?

[sebmck]

The purpose of inlining the elements is to get rid of function calls so I don't think adding a React.elementFromObject call is a good idea since it defeats the point.

[STRML]

I thought so too at first. But the really expensive part of React.createElement() is not the function call itself, but the props and children copying and the associated array and object allocations. Currently, when using external helpers, there's a function call anyway to get REACT_ELEMENT_TYPE.

I think our discussion re: using React.REACT_ELEMENT_TYPE will work just fine, but it would be nice for React to be able to fully abstract over this so we don't need to know what $$typeof is or what magicnum/Symbol it uses.

[gaearon]

I feel that adding a new “blessed” top-level API to work around a bundling / polyfill issue is a bit of an overkill. (By “blessed” I mean something like elementFromObject.)

[STRML]

Perhaps, and it might lead to some confusion in the future - but it would be nice for other (non-babel) tooling in the future, like cljs, that wants to benefit from using raw objects.

[loganfsmyth]

@gaearon I'd argue that it doesn't seem like a bundling issue in the long run. The core issue is that React should not accept random objects as components. What better way to do that than to expose an API that allows that? The current functionality is an API, but it relys on the global symbol registry and it's not clear (to me at least) why that approach was taken, or what makes that better than exposing a function or constant from React directly instead. That would also mean you could avoid relying on the random integer constant, and actually have the constant be a normal object that could be safely compared with ===, and it avoids relying on possibly-polyfilled Symbols alltogether.

[zpao]

cc @sebmarkbage

[sebmarkbage]

The Symbol solution ensures that multiple npm packages or instances of React can coordinate the same identity seamlessly. Even across realms. None of the proposals here address that concern. (It also makes us compatible with a theoretical future Value Types proposals.)

If React can coordinate with multiple versions of itself, then Babel can as well.

One possible solution would be that Babel depends on a module that exposes this or somehow opts out of inlining the polyfill so that it gets the same fallback as React itself.

[loganfsmyth]

I'm totally pro-symbol, to be clear, I was mostly surprised to see that the symbol registry was the actual using facing UI, rather than having React internally pull a symbol from the the registry and expose it as a constant.

[STRML]

I left a comment on the original PR re: the magicNum - why not just use Infinity, which is portable across realms, doesn't require a polyfill, fixes the Babel problem, and fixes the XSS problem.

[STRML]

This problem is still present and will cause unexpected breakage in older browsers in production builds only.

Since profiling has shown that the function call is actually not the bottleneck, I think it makes sense to put this back on the table as a blessed API (if even somewhat undocumented) as not to break apps in production. It would be great for interop with other optimizing runtimes as a fast path alternative to React.createElement() with fewer validations.

Alternatively, could the ReactElement constructor (not ReactElement.createElement) simply be exposed?

Babel helpers have this interesting desire to remain "pure", but I don't consider relying on a Symbol polyfill (and failing interop between a polyfill and native) to be pure. This seems to be the only long-term solution that will fix this for good.

[sebmarkbage]

How does this work with Symbol.iterator which is also a shared symbol that need to be handled the same way between for...of and library code?