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

This article mainly explains "what are the advantages of React 17". Friends who are interested may wish to have a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "what are the advantages of React 17"?

No new features

React 17 is unusual because it doesn't add any new functionality for developers and focuses mainly on upgrading and simplifying React itself.

We are actively developing new features of React, but they do not belong to this version. React 17 is the key to our deep promotion strategy.

What makes this version special is that you can think of React 17 as a transitional version that makes it safer to embed one React version management tree into another React version management tree.

Upgrade step by step

For the past seven years, React has followed all-or-nothing 's upgrade strategy. You can continue to use the old version, or you can upgrade the entire application to a new version. But there is nothing in between.

This approach continues to this day, but we do encounter the limitations of the all-or-nothing upgrade strategy. Many API changes, for example, when opposing the use of legacy context API, cannot be done in an automated way. It's possible that most applications have never used them so far, but we still choose to support them in React. We have to choose between indefinitely supporting outdated API or still using older versions of React for some applications. But neither of these options is appropriate.

Therefore, we would like to provide another option.

React 17 begins to support gradual upgrades of the React version. When you upgrade from React 15 to 16:00 (or from React 16 to 17:00), you usually upgrade the entire application at once. This applies to most applications. However, if the code base was written a few years ago and is not well maintained, upgrading it will become more and more challenging. Although two versions of React can be used on the page, events problems still occur until React 17.

We use React 17 to solve a lot of such problems. This will mean that you will have more options when React 18 or future versions are released. The preferred option is to upgrade the entire application at once, as before. But you can also choose to upgrade your application step by step. For example, you might migrate most applications to React 18, but keep some delayed loading dialogs or child routes on React 17.

But that doesn't mean you have to upgrade gradually. For most applications, upgrading all at once is still the best solution. Loading two versions of React, even if one of them is delayed on demand, is still not ideal. However, for large applications that are not actively maintained, this option can be considered, and React 17 begins to ensure that these applications are not out-of-date.

In order to achieve a gradual upgrade, we need to make some changes to React's event system. These changes may have an impact on the code, which is why React 17 has become the major version. In fact, no more than 20 of the more than 100, 000 components are affected, so we hope that most applications can upgrade to React 17 without having too much impact. If you have any problems, you can contact us.

An example of gradual escalation

We have prepared an example (GitHub) repository that shows how to delay loading older versions of React if necessary. This example is built using Create React App, but a similar approach should apply to other tools. Developers using other tools are welcome to write demo and submit pr.

Note: we have deferred other updates until after React 17. The goal of this release is to achieve gradual upgrades. If it is too difficult to upgrade React 17, our goal will not be achieved.

Change event delegate

Technically, you can always nest different versions of React in your application. However, it is difficult to implement because of the working principle of React event system.

In React components, event handling is usually written inline:

The equivalent DOM operation for this code is as follows:

MyButton.addEventListener ('click', handleClick)

For most events, however, React does not attach them to the DOM node. Instead, React attaches a handler to each event type directly on the document node, which is called an event delegate. In addition to its performance advantages in large applications, it also makes it easier to add new features like replaying events.

Since its release, React has been automatically delegating events. When the DOM event is triggered on the document, the React finds the invoked component, and the React event bubbles up in the component. But in fact, native events have bubbled out of the "document" level, and React is an event handler installed in document.

But that's the difficulty of escalating.

If there are multiple React versions on the page, they will all register event handlers at the top level. This destroys e.stopPropagation () if event bubbling is prevented in the nested tree structure, but the external tree can still receive it. This makes nesting of different versions of React very difficult. This concern is not unfounded-for example, the Atom editor encountered the same problem four years ago.

This is why we want to change the way events are attached at the bottom of React.

In React 17, React will no longer add event handlers to document. Instead, the event handler is attached to the root DOM node of the rendered React tree:

Const rootNode = document.getElementById ('root'); ReactDOM.render (, rootNode)

In React 16 or earlier, React performed document.addEventListener () on most events. React 17 will call rootNode.addEventListener () at the bottom.

Thanks to this change, nesting of old and new versions of React trees is now more secure. Note that for it to work, both versions must be version 17 or later, which is the root cause of the strong recommendation to upgrade to React 17. In a sense, React 17 is a transitional version that makes gradual upgrades possible.

This change also makes it easier for React to embed applications built using other technologies. For example, if the "shell" of an application is written in jQuery, but the newer code is written in React, the e.stopPropagation () in the React code prevents it from affecting the jQuery code-- as you would expect. In other words, if you no longer like React and want to rewrite the application (such as using jQuery), you can convert React to jQuery from the outer layer without destroying event bubbles.

It has been verified that many of the issues reported on issue tracker over the years have been resolved by new features, most of which are related to the integration of React and non-React code.

Note: you may wonder if this will break the Portals outside the root container. The answer is that React also listens for events on the portals container, so this is not a problem.

Solve the hidden trouble

As with other major updates, the code may need to be adjusted. At Facebook, we adjusted about ten of thousands of modules to accommodate this update.

For example, if document.addEventListener (...) is used in the module. With the manual addition of DOM snooping, you may want to capture all React events. In React 16 or earlier, even if you called e.stopPropagation () in the React event handler, the DOM snooping you created would still trigger because the native event was already at the document level. Bubbling with React 17 will be blocked (on demand), so your document level event listener will not trigger:

Document.addEventListener ('click', function () {/ / if the React component calls e.stopPropagation () / / then this custom listener function will not receive a click event})

You can convert monitoring to use event capture to fix this kind of code. To do this, you can pass {capture: true} as the third parameter of document.addEventListener:

Document.addEventListener ('click', function () {/ / now this event handler uses event capture, / / so it can receive all click events!}, {capture: true})

Note that this strategy is more adaptable globally. For example, it might fix existing errors in the code that occur when e.stopPropagation () is called outside the React event handler. In other words, the event bubbling of React 17 is closer to regular DOM.

Other major changes

We keep major changes in React 17 to a minimum. For example, it does not delete task methods that were deprecated in previous versions. However, it does contain some other major changes that, as a rule of thumb, are relatively safe. Overall, due to the existence of these factors, no more than 20 of the more than 100,000 components are affected.

Alignment browser

We made some minor updates to the event system:

The onScroll event no longer bubbles to prevent some confusion.

The onFocus and onBlur events of React have been switched to native focusin and focusout events at the underlying level. They are closer to the existing behavior of React and sometimes provide additional information.

Capture events (for example, onClickCapture) are now using capture listeners in the actual browser.

These changes bring React closer to browser behavior and improve interoperability.

Note: although the focus event was switched from React 17 to focusin, onFocus did not affect the bubbling behavior. In React, the onFocus event is always bubbling, and it continues to bubble in React 17 because it is usually a more useful default. Take a look at this sandbox to see the different checks that can be added for different specific use cases.

Remove event pool

Remove "event pooling" from React 17. It doesn't improve the performance of modern browsers and even confuses experienced developers:

Function handleChange (e) {setData (data = > ({... data, / / This crashes in React 16 and earlier: text: e.target.value});}

This is because React reused event objects for different events in older browsers to improve performance and set all event fields to null before them. In React 16 and earlier, the consumer had to call e.persist () to use the event correctly or read the required properties correctly.

In React 17, this code works as expected. The old event pool optimization operation has been deleted, so the consumer can read the event field when needed.

This changed the behavior, so we marked it as a major update, but in practice we didn't see it having an impact on Facebook (and even fixed some bug!). Note that e.persist () is still available in the React event object, but with no effect.

Timing for cleaning up side effects

We are synchronizing the timing of the useEffect and the cleanup function.

UseEffect (() = > {/ / This is the effect itself. Return () = > {/ / This is its cleanup. };)

Most side effects (effect) do not require delayed refresh of the view, so React reflects on the screen that updates are executed asynchronously immediately after they are updated (in rare cases, you need a side effect to prevent redrawing. For example, if you need to get dimensions and positions, use useLayoutEffect).

However, the side effect cleanup function, if any, runs synchronously in React16. We found that this is not ideal for large applications because synchronization slows down view updates (for example, switching tags).

In React 17, the side effect cleanup function is executed asynchronously-- if the component is to be uninstalled, the cleanup runs after the view is updated.

This reflects how the side effects themselves run more closely. In rare cases, you may want to rely on synchronous execution and use useLayoutEffect instead.

Note: you may wonder if this means that you will not be able to fix the warning about setState on unmounted components now. Don't worry, React specifically handles this situation and does not issue a setState warning during a short interval between uninstallation and cleanup. Therefore, the request or interval to cancel the code can almost always be saved.

In addition, React 17 executes the cleanup in the same order as the effect based on their position in the tree. In the past, the order was sometimes different.

Potential hidden danger

Reusable libraries may require in-depth testing of this situation, but we have encountered only a few components that interrupt execution because of this problem. For example:

UseEffect (() = > {someRef.current.someSetupMethod (); return () = > {someRef.current.someCleanupMethod ();};})

The problem is that someRef.current is mutable, so when you run the cleanup function, it may already be set to null. The solution is to store values that will change inside the side effects:

UseEffect (() = > {const instance = someRef.current; instance.someSetupMethod (); return () = > {instance.someCleanupMethod ();};})

We don't want this problem to affect everyone, and our lint plug-in for eslint-plugin-react-hooks/exhaustive-deps (please make sure you use it in the project) will warn you about this situation.

Return a consistent undefined error

In React 16 and earlier, returning undefined always reported an error:

Function Button () {return; / / Error: Nothing was returned from render}

It is easy to inadvertently return undefined:

Function Button () {/ / forgot to write ruturn here, so this component returns a undefined. / / React will report an error without ignoring it. ;}

Previously, React only did this on class and function components, but did not check the return values of forwardRef and memo components. This is due to a coding error.

In React 17, the behavior of forwardRef and memo components is consistent with that of regular function components and class components. An error will be reported when returning undefined

Let Button = forwardRef (() = > {/ / forgot to write ruturn here, so this component returns a undefined. / / React17 will report an error without ignoring it. ;}); let Button = memo (() = > {/ / forgot to write ruturn here, so this component returns a undefined. / / React17 will report an error without ignoring it. ;})

For cases where you do not want to render anything, please return null.

Native component stack

When you encounter an error in the browser, the browser will provide you with stack information with the name and location of the JavaScript function. However, the JavaScript stack is usually not sufficient to diagnose the problem, because the hierarchy of the React tree may be equally important. Not only do you need to know which Button threw the error, but you also want to know where Button is in the React tree.

To solve this problem, when you encounter an error, the "component stack" message will be printed starting with React 16. Still, they are not as good as the native JavaScript stack. In particular, they are not clickable in the console because React does not know where the function is declared in the source code. In addition, they are almost useless in production. Unlike conventional compressed JavaScript stacks, they can be automatically restored to the position of the original function in the form of sourcemap, while using React component stack, it is necessary to choose between stack information and bundle size in production environment.

In React 17, component stacks are generated using different mechanisms that stitch them together with regular native JavaScript stacks. This allows you to get fully symbolized React component stack information in a production environment.

The way React does this is a bit unconventional. Currently, browsers cannot provide a way to get the function stack framework (source file and location). Therefore, when React catches an error, it rebuilds its component stack information through temporary errors thrown (and captured) within the above components of the component. This increases the performance loss in the event of a crash, but only once per component type.

If you are interested, you can read more details in this PR, but in most cases, this mechanism will not affect your code. From the user's point of view, the new feature is that component stacks can be clicked (because they depend on the native browser stack framework) and can be decoded in production like regular JavaScript errors.

Part of the big change is that for this function to work properly, React will re-execute some of the above functions and parts of some class constructors on the stack after catching the error. Because rendering functions and class constructors should not have side effects (which are also important for SSR), this does not cause any practical problems.

Remove private export

Finally, the major change worth noting is the removal of some React internal components that were previously exposed to other projects. In particular, React Native for Web used to rely on some internal components of the event system, but this dependency is fragile and often broken.

In React 17, these private exports have been removed. As far as we know, React Native for Web is the only project that uses them, and they have completed the migration to other methods that do not rely on those privately exported functions.

This means that the old version of React Native for Web will not be compatible with React 17, but the new version can use it. In fact, it hasn't changed much, because React Native for Web must release a new version to accommodate changes in its internal React.

In addition, we removed the helper method of ReactTestUtils.SimulateNative. They were never recorded, did not do as their names implied, and did not deal with the changes we made to the event system. If you want an easy way to trigger events in native browsers during testing, use React Testing Library instead.

Installation

We encourage you to try React version 17.0 RC as soon as possible, and you can ask us if you have any problems during the migration. Note that the candidate version is not as stable as the stable version, so do not deploy it to the production environment.

To install React 17 RC version from npm, execute:

Npm install react@17.0.0-rc.0 react-dom@17.0.0-rc.0

To install React 17 RC version from yarn, execute:

Yarn add react@17.0.0-rc.0 react-dom@17.0.0-rc.0

We also provide a UMD build of React RC through CDN:

At this point, I believe you have a deeper understanding of "what are the advantages of React 17". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.