React#31的render怎么解决

这篇文章将为大家详细讲解有关React#31的render怎么解决，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

卡颂日常从事基础架构相关工作。这次接到一个任务：封装一个React组件交给业务方使用。

组件本地开发无误，自测无误，交给业务方接入无误，业务方测试环境验收无误。

然而，当包含该组件的页面小流量上线后，监控平台立刻收到报警：

Minified React error #31 ......

打开监控看板，发现大部分报错来自于一款机型：「Vivo x7」，Android版本5.1。完整报错信息如下：

看看时间：周五晚上6点半。呵，还有我解决不了的React问题?半小时搞定，过周末去～

然而......

找准问题原因

简单描述下#31号错误信息描述的内容：

React的render函数可接受的返回值类型包括：

• string，比如return 'I am kasong';

• number，比如return 123;

• array，比如return  [<p>ka</p>, <p>song</p>];。

其中[]会被处理为React.Fragment

• object，比如return  <p>ka song</p>;。

因为该返回值会被编译为React.createElement(或jsx.createElement，视React版本不同而不同)。

而React.createElement的返回值是一个对象(即object类型)。

这里的报错信息是说：你某个组件返回了一个非法值。因为这个值是object类型，但是他不是一个JSX对象。

想要复现这个问题也很简单，比如如下代码：

function App() {   reutrn {}; }

返回值是个object，但非JSX对象。

作为React老司机，是绝对不可能写错返回值类型的。况且，写错的话，本地开发就会报错了。

而且很奇怪，这个问题，为什么只在这款机型复现呢?

初见端倪

现在我们掌握的线索是：

• 这是个个别机型复现的报错

• 报错原因是因为render函数返回了错误的类型

我们需要更多线索!!

虽然是被压缩的线上代码，但好在React提供了必要的错误信息。

这个错误的object包含了如下字段：

found: object with keys {$$typeof, type, key, ref, props, _owner}).

居然包含$$typeof!!!

$$typeof是React源码内部用来判断JSX对象类型的字段。

比如React.Fragment、React.portal、div这三种JSX分别对应三种$$typeof。

换言之，包含$$typeof的object类型，大概率是一个JSX对象。

既然这个报错的object对象就是一个JSX对象，那React为什么还认为他是一个非法的返回值呢?

React狠起来连自己都杀?

深入源码

要解答这个问题，必须深入React源码。

由于我的组件中没有使用Fragment或Portal这样的特性，所以将问题定位在普通React组件对应的$$typeof。

在源码中，这种类型被称为REACT_ELEMENT_TYPE。

• PS：Fragment类型为REACT_FRAGMENT_TYPE，Portal类型为REACT_PORTAL_TYPE，

var hasSymbol = typeof Symbol === 'function' && Symbol.for; var REACT_ELEMENT_TYPE = hasSymbol ? Symbol.for('react.element') : 0xeac7;

可以看到，当宿主环境支持Symbol时，REACT_ELEMENT_TYPE === Symbol.for('react.element')。

不支持时，REACT_ELEMENT_TYPE === 0xeac7

与此同时，REACT_ELEMENT_TYPE这个变量的定义不仅存在于React这个包中，也存在于ReactDOM包中。

Vivo x7的WEBview原生不支持Symbol。似乎有点儿苗头了!

审查业务方代码后发现，业务方使用core-js实现了Symbol polyfill。

那么设想如下场景：

假如业务方代码打包的顺序是：

React -> core-js -> ReactDOM

那么在运行时，React首先加载，执行到定义REACT_ELEMENT_TYPE变量这行代码时，宿主环境全局不存在Symbol。

所以在React这个包中，REACT_ELEMENT_TYPE === 0xeac7

接着运行core-js，他会在window上挂载Symbol。

接着ReactDOM在运行时，执行到定义REACT_ELEMENT_TYPE变量这行代码时，宿主环境已经存在全局变量Symbol。

所以在ReactDOM中，REACT_ELEMENT_TYPE === Symbol.for('react.element')

而React.createElement方法来自React包，组件的render方法是在ReactDOM包中的reconciler模块调用的，

所以就会发生判断组件类型时，0xeac7 !== Symbol.for('react.element')，让React认为这是个非法的返回值。

在遥远的2016年，就有人就此给React提issue[1]。

事实真的如此么?

然而审视业务方代码后发现，依赖打包的顺序是：

core-js -> React -> ReactDOM

按照刚才的推理，React和ReactDOM都能拿到core-js提供的Symbol polyfill。

拨云见日

此时早已华灯初上，我为我对React的轻视流下了不争气的泪水。

亏我还是React Contributor，React技术揭秘[2]作者，React 17的源码方法名都能背下来。

嗯?React 17??难道!

v16.14之前版本的React中JSX对象会被编译为React.createElement。

此版本之后createElement被从React包中拆分出来，独立在react/jsx-runtime中。

编译工作则由@babel/plugin-transfORM-react-jsx插件完成。

那么此时，REACT_ELEMENT_TYPE的定义存在于jsx-runtime、React、ReactDOM三个包中。

也就是说，如果编译后包的执行顺序是：

jsx-runtime -> core-js -> React -> ReactDOM

在低端Android机上还会复现这个问题!

这里截取一个网友遇到同样问题后他的截图：

• 这个问题的讨论见Bug: IE 11 not working with latest React version

可以看到，jsx-runtime被babel编译成第一个依赖，破案!

所以，这实际上是个babel编译后产物顺序造成的bug，已经有人给babel提相关issue[3]

最终我将JSX的编译方式从编译为jsx.createElement降级为React.createElement解决了这个报错。

此时，夜已深。。。

每一片雪花都是那么纯洁，直到他们组成了一场雪崩。

这个bug的各方，React、babel、提供组件的我、业务方代码，单独来看，没有一方有问题。

但是，当一系列巧合合并在一起，就是一个线上bug。

这也显示了线上小流量、报错监控基建的重要性。

关于React#31的render怎么解决就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。