React 17 - going BIG where it matters

To be honest, I’m not really a big React fan myself, but recently I started to rediscover the library. Using Vue and going even as far as to create my own UI library, I came to appreciate the ecosystem and “time-to-deploy” that developing with React gave me. So, despite my past negative bias, I started to use React pretty extensively, even to a point of enjoyment. And news that broke out a few days before this post, about the Release Candidate (RC) for React v17 pleasantly surprised me.

So, in this post, I’d like to give you a brief overview of what’s coming with the new version, and - spoiler warning - why the supposed “lack of new features” is actually a good thing.

What’s RC anyway?

For those rather unfamiliar with all the software release cycle concepts, here’s a small summary.

Release Candidate (RC for short) is a stage above alpha and beta (which you might be more familiar with). Here, the software (React in this case) is still in development, but with great potential to become a stable product.

There can be multiple RCs, with the last one becoming the stable or “production” release. Right now React 17 is at the stage of the first RC.

The problem with new features

For a UI library that seems to be at the forefront of web development, constantly introducing new concepts and pushing the web forward, the lack of any new developer-facing features seems kind of weird for the major release that React v17 is. No next hooks, no stable concurrent mode, no nothing! Just some minor “upgrades” under the hood. Is this a joke?

Alright, maybe I’m a bit sarcastic here, but hopefully, you get the point. I agree with the React team, that there’s no need for fancy new features right now, just because the number gets a bump.

It wasn’t that long ago that we got stable hooks, or experimental concurrent mode and suspense. React definitely doesn’t stop getting new features. However, with its growth in popularity and usage (especially among big corporations), it’s not a surprise that lately stability and “upgradeability” have been gaining increasingly more attention.

How does such an approach fit into the broader React landscape? Take the most recent case of hooks for example. Even though the official blog post that announced their stable release clearly mentioned that adopting them isn’t mandatory, many developers jumped onto the hype train, implementing hooks, which often resulted in mixed feelings about the new feature.

Don’t get me wrong, it’s often desired to use the latest and greatest the moment it drops, but it’s always not good to rush things. Using a new feature without proper understanding usually leads to confusion and messy code, rather than the hyped improved readability, clarity, and performance.

That’s why I’m all-in on what’s React v17 is going for. With only a few fixes here and there, it makes future upgrades much easier and less painful. This way, developers can upgrade when they want and how they want, going as far as to even using multiple versions of React at the same time with ease, and adopting new features only when the developers are clearly ready for them. That’s some really BIG focus on things that really matter.

The new stuff

With opening thoughts out of the way, let me briefly discuss the new “underlying features” of React v17. Keep in mind that the core React team did a really good job of describing them in the official blog post, so I won’t be going too much into detail here.

Gradual upgrades

What I’ve already discussed - the goal of the first React v17 release is to make React more “upgradeable”. The React team correctly called this “feature” gradual upgrades, as they’re meant to ease out the upgrade process, by not requiring you to upgrade your entire codebase all at once.

This is only possible thanks to a number of internal tweaks that are included in this new version.

Event delegation

For easier usage/nesting of apps that use different versions of React, a few changes have been made. Arguably the biggest one is related to event delegation.

You might know that in DOM, there’s an event delegation mechanism, which allows you to listen for events on the upper-level element, while still being able to detect which lower-level element was interacted with, due to event bubbling up the node tree.

React uses it to its own advantage for better performance on large trees and additional functionalities. However, it always attached its event listeners to the most top-level document node (through document.addEventListener()), resulting in potential conflicts when multiple React versions were used at the same time.

React v17 fixes that by registering listeners on the node ReactDOM renders to (i.e. root element), effectively getting rid of any potentially unwanted conflicts.

Event pooling

Sticking to events for now a feature called “event pooling” was apparently removed from v17. It reused the event object between different events while setting all fields to null in-between the process. It was meant to improve performance in the older browsers, but as it’s no longer the case with the modern ones, and the feature itself was also causing some issues, it was simply removed.

Effect cleanup

Next up, for the hooks lovers - a few improvements have been made to useEffect() for better timing of the cleanup function.

useEffect(() => {
  // Side-effect
  return () => {
    // Cleanup
  };
});

The function is now run asynchronously (just like the effect itself), while also executing in the same order as the effects.

Return undefined

React v17 also improves its handling of cases where undefined is (most likely by accident) returned from the rendering function. This usually resulted in errors being thrown, but not so much for components wrapped in memo() or forwardRef().

const Button = () => {
  // Error
  <button />;
};
const Button = forwardRef(() => {
  // Nothing
  <button />;
});
const Button = memo(() => {
  // Nothing
  <button />;
});

v17 standardizes the behavior by throwing errors in all of the above cases. Still, with modern coding tools and the advent of arrow functions, it’s rather hard not to notice such error, but there’s nothing wrong with having some additional protection.

Component stacks

Speaking of errors, the new version, also brings some improvements to them. Mainly the new mechanism for generating component stacks (organically introduced in v16) that results in better debugging experience, no matter the production or development environment.

Private exports

Lastly, some private exports containing the React internals have been removed. This shouldn’t matter much to you unless you’re using React Native for Web.

Test drive

So, these are the new features. Of course, there are some smaller performance improvements and other kinds of tweaks here and there, but that’s pretty much it for the “breaking” changes.

If you want to see how much/little has changed, feel free to install the latest RC (not in a production of course) and take it for the test drive with the following command:

npm install react@next react-dom@next

The future is feature-packed

With all that said, for those of you striving for new features - rest assured - they’ll come. Just like hooks which dropped in v16.8, new features aren’t bound to a version number. Experimental features will eventually become stable, and new features will arrive as well. Just remember - it’s good to be up-to-date with the latest and greatest, but it’s not worth it to rush things. Keep your own pace, upgrade steadily, and confidently.

Speaking of up-to-date, if you really want to be up-to-date with all of my latest content, consider following me on Twitter, Facebook, or through my newsletter. Also, if you have any questions or thoughts about React v17, leave them in the comment section below. Thanks for reading and happy coding!