Fix our custom element serializer in IE11

[youknowriad]

In IE11, React don't use the constants for its element types because of the lack of support for Symbols. Which means in our element serializer we need to check against those numbers React uses as types.

This fixes an issue where RichText content was not saved in IE11

Testing instructions

• Create a paragraph in IE11 and type something in it
• Save and refresh the page
• The content should still be there.

[tofumatt]

This is a pretty gnarly bug and I tested the fix in IE 11 on Windows 10–it fixed it, so I say 🚢

Were there any issues filed for this? I don't see them mentioned in the summary.

[youknowriad]

@tofumatt It's not filled I think, I just noticed it when fixing other IE11 bugs :)

[aduth]

Agree that this was pretty critical to fix, but this needs to be refactored in a subsequent pull request since we're already assuming the fallback values in the assignment of the const. It should either be corrected there, or removed from there (ideally the former).

I can plan to set aside some time to take a look.

[gziolo]

@youknowriad thanks for fixing, and let's refactor :)

[aduth]

I do suspect the main issue here is that our Babel runtime transform is converting the Symbol check in HAS_SYMBOL assignment to the version used by core-js, so effectively HAS_SYMBOL will always be true, and Symbol.for will use the polyfilled version. This is unlike in React, where Symbol is not polyfilled and thus will use the fallback value. The mismatch in behavior is likely what caused the switch not to properly catch the type of the element.

I've having trouble finding a way to detect true native environment support for Symbol without triggering the replacement by the runtime transform.

Another option would be to avoid (re-)defining the React constants, and instead generate a dummy pair of Provider / Consumer components and access the $$typeof property of them to use in the switch. I avoided this purely for the memory overhead of creating an unused component, but it seems more stable given the issues faced with trying to define the Symbol value.

[aduth]

For historical context, this was a regression of #8189