What Is New In React V17?

We will explain in this article the function of this major React v17 update, what improvements you can expect in this release and how you can try it.

React Fiber(React v 16) has been working in a fantastic manner and has taken some important steps to enhance the developer experience and efficiency of react-built applications.

However, we have curated this article to see how React v17 has seen some changes. Basically, there are no major new features introduced, only improvements to the earlier existing features.

Here are the changes we can expect in react v17:

1. Gradual react upgrades
2. Event root will no longer be documented.documentElement
3. Clean up in useEffec  t() will change from synchronous to asynchronous
4. Consistent Errors for Returning Undefined
5. New Changes in the Event System
6. No event pooling
7. Removing Private Exports
8. New Lifecycle Methods
9. Native Component Stacks
10. Changes to Event Delegation

Let’s have a look at them one by one–

1. React v17 Allows Gradual React Upgrades

The application may work well when you update your entire application from React 15 to 16 or from React 16 to 17. Yet, if the codebase was written more than a few years ago and is not regularly maintained, it may become increasingly difficult.

Although two versions of React can be used on the website, it was unstable and caused event issues until react v17 came into the picture. Some improvements have been made to the React event system in order to allow gradual upgrades. React17 is an essential release because the changes could break down.

2. “Event root” Will no Longer be document.documentElement

Until now, when installing a React component, your event listener has been directly attached to the document level, which could have created several problems, such as inconsistencies with your other non-react code, javascript libraries, etc. but in react v17, it will attach them to the root DOM container into which your React tree is rendered.

3. Clean up in useEffect() Will Change from Synchronous to Asynchronous

Until React v17 came into the market, the cleanup mechanism used to run synchronously (identical to componentWillUnmount used in classes) which implies that when unmounting your components, react was used to execute the cleanup function and then update the screen which is used to slow down the heavy apps.

Now, the cleanup functions are going to run asynchronously, after the screen gets updated. This will improve the performance of the app.

4. Consistent Errors for Returning Undefined

React v17 also includes error handling cases where undefined is returned from the rendering function. In Reactv16, Components that return undefined are considered as an error. Previously, React only did this for class and function components, but did not check the return values of forwardRef and memo components.

In react v17, the behavior for forwardRef() and memo() components are consistent with regular function and class components. Returning undefined from them is an error.

const Button = () => {
	// React will throw an Error
	<
	button / > ;
};
let Button = forwardRef(() => {
	// React 17 surfaces this as an error instead of ignoring it.
	<
	button / > ;
});

let Button = memo(() => {
	// React 17 surfaces this as an error instead of ignoring it.
	<
	button / > ;
});

React 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 errors, but there’s nothing wrong with having some additional protection.

5. New Changes in the Event System

A few changes can be observed in the event system, some of which we have listed down:

1. They took care of the problems faced at onScroll the event. The problem was that OnScroll callback on the parent element fires when a children element is scrolled.
2. onFocus and onBlur events have changed to use with native focusin and focusout events.
3. onClickCapture will be used to capture browser phases.

6. No Event Pooling

React 17 deletes the optimization of “event pooling” from React. In major browsers, it does not improve efficiency and confuses even experienced React users.

React reused the event objects for output in older browsers between separate events and set all event fields to null.

While using React 16, you need to call e.persist() to use the event properly or read the property you want earlier.

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

This code is executed as you would expect in React 17. The old design of event pooling has been eliminated entirely, enabling you to read the event fields when you need them.

7. Removing Private Exports

React Native for the web, in particular, used to rely on certain internals of the event system, but this dependency became weak and used to clash a lot.

These private exports are abolished in React 17. We understand that React Native for Web was the only project that used them and that a migration to a new method has already been completed that does not rely on these private exports.

This implies that the old React Native Web version will not be compatible with React 17 but will work with the updated versions. It doesn’t affect too much in reality because React Native had to release new versions to adjust to changes in its internal reaction.

8. New Lifecycle Methods

The new lifecycle methods are switched with the deprecated lifecycle methods. These two methods are: getDerivedStateFromProps and getSnapShotBeforeUpdate.

The hazardous processes are replaced by these new lifecycle methods. For instance, componentWillUpdate can be replaced by using getDerivedStateFromProps together with shouldComponentUpdate, componentWillMount should be removed altogether for async rendering.

getDerivedStateFromProps

This method is bound to replace componentWillReceiveProps and componentWillUpdate and will be called after a component is created and when it received new props.

It returns an object to update the state when props change or null when there is no change in state.

state = {
	cachedSomeProp: null
};
static getDerivedStateFromProps(nextProps, prevState) {
	return {
		cachedSomeProp: nextProps.someProp,
		..
	};
}

getSnapshotBeforeUpdate

This method manages component changes and replaces componentWillUpdate efficiently and operates with componentDidUpdate.

It is called and returns the value to the componentDidUpdate that handles the changes before any Dom updates:

class ScrollingList extends React.Component {
	listRef = null;
	getSnapshotBeforeUpdate(prevProps, prevState) {
		if (prevProps.list.length < this.props.list.length) {
			return (
				this.listRef.scrollHeight - this.listRef.scrollTop
			);
		}
		return null;
	}
	componentDidUpdate(prevProps, prevState, snapshot) {
		if (snapshot !== null) {
			this.listRef.scrollTop =
				this.listRef.scrollHeight - snapshot;
		}
	}
	render() {
		return ({
			/* …contents… */ });
	}
	setListRef = ref => {
		this.listRef = ref;
	};
}

9. Native Component Stacks

The browser will give you a Javascript function name and locations stack trace when you toss an error in the browser. The JavaScript stacks, however, often aren’t enough to identify a problem since the hierarchy of the react tree is vitally valuable.

You don’t want to know just that a button has made a mistake, but where the button is in the react tree.

In React 17, a different method is used for the component stacks to be generated that combines them from the regular native JavaScript stacks.

This helps you in a production environment to get the completely symbolic react component stack traces.

It’s very unconventional how React handles this. The browsers currently do not provide a way to get a function’s stack frame.

When the react detects a mistake, the component stack can now be rebuilt, throwing a temporary error (and catching it) from within each of its above components, where possible.

This gives you a small penalty for crashing results, but only once per component type.

10. Changes to Event Delegation

Essentially, apps built in various versions of React have always been possible to nest. The way they react event system worked was, however, very delicate.

In React components, you usually write event handlers inline:

<button onClick={handleClick}>

The vanilla DOM equivalent to this code is something like this:

myButton.addEventListener('click', handleClick);

In fact, React does not really connect them to the DOM nodes you declare on most events. Rather, React adds one handler per event type directly at the document node. It is known as the delegation for the event. It also makes it simpler to add new features such as replaying events, apart from its efficiency advantages for large applications.

Since its initial release, React has done event delegation automatically. When a DOM event initiates on the document, React understands which component to call, and then the React event goes upwards through your components. But, in reality, the native event has already bubbled up to the document level, where React installs its event handlers.

How to Install it- The Installation Process

The best way to figure out new bugs is to install the React 17.0 release candidate. A release candidate is bound to contain more bugs than a stable release, so don’t deploy it to production yet.

To install React 17 RC with npm–

run

npm install [email protected] [email protected]

To install React 17 RC with Yarn-

run

yarn add [email protected] [email protected]

Bottom Line

React v17 is a new release with many reasons for React developers to get motivated. Not only does it have some fantastic, revolutionary functionality that will reshape how React applications are designed, but it also builds on recently implemented functionality such as Hooks with gradual improvements that enable developers to make better use of them.

This would lead to better solutions and improved experience and an incredible future for React!

FAQ