Use a Symbol to tag every ReactElement

[sebmarkbage]

Fixes #3473

I tag each React element with $$typeof: Symbol.for('react.element'). We need
this to be able to safely distinguish these from plain objects that might have
come from user provided JSON.

The idiomatic JavaScript way of tagging an object is for it to inherent some
prototype and then use instanceof to test for it.

However, this has limitations since it doesn't work with value types which
require typeof checks. They also don't work across realms. Which is why there
are alternative tag checks like Array.isArray or the toStringTag. Another
problem is that different instances of React that might have been created not knowing about eachother. npm tends to make this kind of problem occur a lot.

Additionally, it is our hope that ReactElement will one day be specified in
terms of a "Value Type" style record instead of a plain Object.

This Value Types proposal by @nikomatsakis is currently on hold but does satisfy all these requirements:

https://github.com/nikomatsakis/typed-objects-explainer/blob/master/valuetypes.md#the-typeof-operator

Additionally, there is already a system for coordinating tags across module
systems and even realms in ES6. Namely using Symbol.for. (thx @sebmck)

Currently these objects are not able to transfer between Workers but there is
nothing preventing that from being possible in the future. You could imagine
even Symbol.for working across Worker boundaries. You could also build a
system that coordinates Symbols and Value Types from server to client or through
serialized forms. That's beyond the scope of React itself, and if it was built
it seems like it would belong with the Symbol system. A system could override
the Symbol.for('react.element') to return a plain yet
cryptographically random or unique number. That would allow ReactElements to
pass through JSON without risking the XSS issue.

The fallback solution is a plain well-known number. This makes it unsafe with
regard to the XSS issue described in #3473. We could have used a much more
convoluted solution to protect against JSON specifically but that would require
some kind of significant coordination, or change the check to do a
typeof element.$$typeof === 'function' check which would not make it unique to
React. It seems cleaner to just use a fixed number since the protection is just
a secondary layer anyway. I'm not sure if this is the right tradeoff.

In short, if you want the XSS protection, use a proper Symbol polyfill.

Finally, the reason for calling it $$typeof is to avoid confusion with .type
and the use case is to add a tag that the typeof operator would refer to.
I would use @@typeof but that seems to deopt in JSC. I also don't use
__typeof because this is more than a framework private. It should really be
part of the polyfilling layer.

Test Plan:

examples/basic/index.html works in Chrome and Firefox which both have native Symbols - and in Safari which doesn't.

React.createElement('div').$$typeof // Symbol(react.element).

[sebmarkbage]

Fixed this bug in older browsers.

[sebmarkbage]

I used a single underscore here for consistency with _owner and _store while the properties in config use the double underscore.

[glenjamin]

This is a great solution to the XSS issue! Just need to make sure no-one adds a way to run symbol.for via JSON parsing :)

[trueadm]

works in Chrome and Firefox which both have native Symbols - and in Safari which doesn't.

I do believe this is very soon to change with the latest Safari for iOS 9 and El Capitan (16th September and 30th September according to yesterday's Apple event). :)

[gaearon]

0xeac7 0x0cc5!

(edited for hexiness, thanks @RReverser for the tip)

[RReverser]

@gaearon o is not valid hex char :P

[chicoxyzzy]

someone please tell me why 0xeac7? I can't sleep

[zpao]

0xeac7 sorta kinda looks like React

[yiminghe]

why not use Math.random()

[sebmarkbage]

It doesn't cover postMessage though.

[STRML]

We want postMessage to work, right? In my testing, it actually does, since structured cloning supports much more advanced serialization than JSON.stringify().

This is confirmed in the w3c tests: https://github.com/w3c/web-platform-tests/blob/master/workers/interfaces/DedicatedWorkerGlobalScope/postMessage/structured-clone-message.html#L32

[sebmarkbage]

We don't want it to work cross domain by default. That's still a security risk.

However, we do want it to work if you're able to coordinate the Symbol across the worker boundaries.

[STRML]

I would argue that if you're deliberately catching cross-origin postMessage and inserting objects directly into your views without validation, you're asking for it.

This would be nice for webworkers though, as Symbols don't transfer via structured cloning (so you'd have to explicitly catch elements and re-tag them).

[sebmarkbage]

See #3473 for more context.

It is too easy to expect a string and not realize it might be an object:

loadString(function(stringData) {
  React.render(<div>Content: {stringData}</div>, container);
});