Shulou(Shulou.com)06/03 Report--

This article will explain in detail how to solve the render of React#31. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Kasong is engaged in infrastructure-related work on a daily basis. This time, I received a task: to encapsulate a React component to be used by the business side.

The local development of the component is correct, the self-test is correct, and the access to the business side is correct, and the business side test environment acceptance is correct.

However, when the small traffic on the page containing the component goes online, the monitoring platform immediately receives an alarm:

Minified React error # 31.

Open the monitoring Kanban and find that most of the errors come from one model: "Vivo x7", Android version 5.1. The complete error message is as follows:

Look at the time: 06:30 on Friday night. Oh, is there a React problem that I can't solve? I'll do it in half an hour. I'll go over the weekend.

However.

Find out the cause of the problem

Briefly describe what error message # 31 describes:

The types of return values that are acceptable to the render function of React include:

String, such as return'I am kasong'

Number, such as return 123

Array, such as return [

Ka

Song

];.

Where [] will be treated as React.Fragment

Object, such as return

Ka song

;.

Because the return value will be compiled to React.createElement (or jsx.createElement, depending on the version of React).

The return value of React.createElement is an object (that is, the object type).

The error message here says: one of your components returned an illegal value. Because this value is of type object, but it is not a JSX object.

It is also easy to reproduce the problem, such as the following code:

Function App () {reutrn {};}

The return value is an object, but not a JSX object.

As a veteran React driver, it is absolutely impossible to write the wrong return value type. Moreover, if you write it wrong, the local developer will report it wrong.

And it's strange, why is this problem only repeated in this model?

The first clue

Now the clue we have is:

This is an error report of an individual model.

The reason for the error is that the render function returns the wrong type

We need more clues!

Although it is compressed online code, fortunately, React provides the necessary error information.

The wrong object contains the following fields:

Found: object with keys {$typeof, type, key, ref, props, _ owner}).

Unexpectedly, it contains $$typeoplefavored!

$typeof is a field used internally by the React source code to determine the type of JSX object.

For example, React.Fragment, React.portal, and div correspond to three kinds of $typeof respectively.

In other words, the object type that contains $$typeof is most likely a JSX object.

Since the error object object is a JSX object, why does React still think it is an illegal return value?

React killed himself when he was ruthless?

Deep into the source code

To answer this question, you must go deep into the React source code.

Since I don't use features like Fragment or Portal in my component, I focus on the $$typeof corresponding to a normal React component.

In source code, this type is called REACT_ELEMENT_TYPE.

PS:Fragment type is REACT_FRAGMENT_TYPE,Portal type is REACT_PORTAL_TYPE

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

As you can see, when the hosting environment supports Symbol, REACT_ELEMENT_TYPE = = Symbol.for ('react.element').

If not supported, REACT_ELEMENT_TYPE = = 0xeac7

At the same time, the definition of the variable REACT_ELEMENT_TYPE exists not only in the React package, but also in the ReactDOM package.

Symbol is not supported natively in webview of Vivo x7. There seems to be some sign of it!

After reviewing the business side code, it is found that the business side uses core-js to implement Symbol polyfill.

Then imagine the following scenario:

If the business side code is packaged in the following order:

React-> core-js-> ReactDOM

Then at run time, React loads first and executes to the line of code that defines the REACT_ELEMENT_TYPE variable, and there is no Symbol globally in the host environment.

So in the React package, REACT_ELEMENT_TYPE = = 0xeac7

Then run core-js, and he will mount Symbol on window.

Then, at run time, when ReactDOM executes the line of code that defines the REACT_ELEMENT_TYPE variable, the global variable Symbol already exists in the host environment.

So in ReactDOM, REACT_ELEMENT_TYPE = Symbol.for ('react.element')

The React.createElement method comes from the React package, and the render method of the component is called from the reconciler module in the ReactDOM package.

So when determining the component type, 0xeac7! = = Symbol.for ('react.element') makes React think that this is an illegal return value.

In as far away as 2016, someone mentioned issue to React.

Is that really the case?

However, after looking at the business side code, it is found that the order of dependency packaging is:

Core-js-> React-> ReactDOM

According to the reasoning just now, both React and ReactDOM can get the Symbol polyfill provided by core-js.

restore justice

By this time, the lights were already on, and I shed discontented tears for my contempt for React.

Thanks to the fact that I am also the author of React Contributor,React technology disclosure [2], the source code method name of React 17 can be memorized.

Huh? React 1700? Is it!

JSX objects in React versions prior to v16.14 are compiled to React.createElement.

After this release, createElement is split from the React package and is separate in react/jsx-runtime.

The compilation is done by the @ babel/plugin-transform-react-jsx plug-in.

At this point, the definition of REACT_ELEMENT_TYPE exists in three packages: jsx-runtime, React, and ReactDOM.

That is, if the compiled package is executed in the following order:

Jsx-runtime-> core-js-> React-> ReactDOM

This problem will be repeated on low-end Android!

Here is a screenshot of a netizen after he encountered the same problem:

For a discussion of this issue, see Bug: IE 11 not working with latest React version

As you can see, jsx-runtime is compiled into the first dependency by babel, solve the case!

So, this is actually a bug caused by the sequence of compiled products of babel, and someone has already mentioned the relevant issue to babel [3]

In the end, I downgraded the compilation mode of JSX from compiled to jsx.createElement to React.createElement to solve this error.

By this time, it was late at night.

Every snowflake is so pure until they form an avalanche.

The parties to this bug, React, babel, I who provide the components, and the business code, alone, no one has a problem.

But when a series of coincidences come together, it is an online bug.

This also shows the importance of monitoring infrastructure with small online traffic and error reporting.

On how to solve the render of React#31 to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.