React 17.0 — The news is that there is no news
Discover the new version change of ReactJS and why there is no news at the moment
A few days ago the ReactJS team announced the publication of the first release candidate of version 17 of React on their official blog:
The most striking thing about this announcement is that this update will not include new features, although it does represent a very important change (and from what they say necessary) for the evolution and maintenance of the library itself. Let’s see why!
Gradual updates
The updates that React has introduced in recent times have often involved the introduction of “deprecations” of old functionality, causing development teams to often have problems introducing these new updates, especially in large applications.
That is why the objective of this first version of React 17 is to introduce a method that allows introducing these updates in a less “painful” way. From now on when React is updated there will be options that will allow us to update our application part by part to this new version instead of doing it all at once. For example, we may decide to keep a certain part of the code in a previous version while the rest is updated to the new version.
Since gradual updates mean having multiple versions of ReactJS running, the entire event handling system that React implements underneath has had to be rewritten.
🤓 Be careful! As the React team points out, updating all at once is still the best option, since this way of introducing gradual updates means having two different versions of React running, which is not ideal.
Changes to the event system
Although until now it was not impossible to have multiple versions of React running in our application, this used to cause numerous headaches because of the way React handles events. For example, the Atom code editor encountered a problem related to this almost 4 years ago:
This problem is related to the way that React associates events. When we write this:
<button onClick={handleClick}>
React doesn’t translate that code to this:
someButton.addEventListener('click', handleClick);
Rather, it attaches that event directly to the document
node of the DOM (known as event delegation, which allows you to optimize performance with very large trees as well as rerun events). So when an event occurs in the DOM, React looks for the component to call and lets it bubble up through the component tree.
However, and here comes the problem, in native Javascript this event will have already propagated the level of the document
element, which and as indicated previously, causes strange situations when, for example, we mix React with other libraries such as jQuery or we have several versions of React running: even if the internal tree invokes event.stopPropagation
, the tree that wraps that tree will still receive the event. In other words, if we have an application written in jQuery and inside a chunk that works with React, invoking event.stopPropagation
in React will not prevent the event from reaching jQuery.
Therefore, starting with React version 17, event handlers will be added to the root element of the DOM that contains the application where React is rendered. That is, the element we refer to here:
const rootNode = document.getElementById('root');
ReactDOM.render(<App />, rootNode);// React < 17
document.addEventListener()// React >= 17
rootNode.addEventListener()
Thanks to this change, it will be much easier to embed one version of ReactJS inside another, as long as both versions are at least 17. That is why this change is so important.
useEffect cleanUp
Another very important change in this new version of React is the time when the declared effects are cleaned up through the useEffect hook:
useEffect(function() {
...
return function cleanUp() {
// Its cleanup
};
});
In React version 16, the cleanup of the effect occurred synchronously (the same as the componentWillUnmount
method of class-based components) which caused some performance issues.
As of version 17 of React, the cleaning of the effects is executed asynchronously so that if for example our component is disassembled, the cleaning of the effect will be executed after the screen has been updated.
This change only affects the useEffect
hook since useLayoutEffect
will keep its execution synchronous.
More “minor” changes
Although the two previous changes are the most important for me, React 17 introduces another series of changes that I want to mention at least in passing in case they affect your applications:
- The optimization of the pool of events that React used to do is eliminated because it no longer introduces performance improvements in modern browsers, so now the event fields are safe when we need them.
- From now on if we use the
forwardRef
ormemo
functions and the component returnsundefined
, React will treat this as an error. - And finally the generation of the component stack has been modified so that now it is easier to know which component produced the error.
Do you want to try React 17?
If you have been curious and want to start testing this new version of React, you can do so by installing it through yarn:
yarn add react@17.0.0-rc.0 react-dom@17.0.0-rc.0
Final thoughts
As you can see, this version 17 of ReactJS does not introduce any novelty in terms of features. However, I am sure that the foundations have been laid so that when new versions begin to be released we will have more than interesting surprises that I will comment on here.