React v.16.3.0 released

A few days ago, we wrote a post about upcoming changes in our lifecycle methods , where we also touched upon the strategy of gradual migration (updates). In React 16.3.0, we added several new lifecycle methods to aid in this migration. We also provided a new API for long-awaited innovations: the official context API, the ref forwarding API, and the ergonomic ref API.

Official Context API

For many years, React has offered an experimental API for working with context. Let it be a powerful "thing", the use of such an API was under threat, as we all wanted to replace the "experimental" API.

Version 16.3 introduces a new context API that is more efficient and supports both static type checking and deep updates right away.

The old context API will work for all releases of version 16, so you have time to migrate.

Below is an example that shows how you can “skip” a theme using a new API:

const ThemeContext = React.createContext('light'); class ThemeProvider extends React.Component { state = {theme: 'light'}; render() { return ( <ThemeContext.Provider value={this.state.theme}> {this.props.children} </ThemeContext.Provider> ); } } class ThemedButton extends React.Component { render() { return ( <ThemeContext.Consumer> {theme => <Button theme={theme} />} </ThemeContext.Consumer> ); } } 

More about the context API here.

createRef API

React provided two ways to control refs : specifying ref in a regular string and callback. Although the ref indication was simply more convenient as a string, it had several drawbacks and therefore we recommended using the callback option.

Version 16.3 adds a new option to control refs, which offers the convenience of specifying ref as a string with no flaws:

 class MyComponent extends React.Component { constructor(props) { super(props); this.inputRef = React.createRef(); } render() { return <input type="text" ref={this.inputRef} />; } componentDidMount() { this.inputRef.current.focus(); } } 

Callback refs will continue to be supported in the new createRef API. Do not rush to replace callback refs in your components. They are more flexible, so we will leave them for future advanced use.

More about the createRef API here.

forwardRef API

Higher order components (or HOC) are a handy tool for reusing code between components. If we take the previous example with context as a basis, we can create a HOC in which we will “cast” the theme as a property ( props ):

 function withTheme(Component) { return function ThemedComponent(props) { return ( <ThemeContext.Consumer> {theme => <Component {...props} theme={theme} />} </ThemeContext.Consumer> ); }; } 

We can use this HOC to associate components with skin properties ( theme ) from context ( context ) without using ThemeContext directly. For example:

 class FancyButton extends React.Component { buttonRef = React.createRef(); focus() { this.buttonRef.current.focus(); } render() { const {label, theme, ...rest} = this.props; return ( <button {...rest} className={`${theme}-button`} ref={this.buttonRef}> {label} </button> ); } } const FancyThemedButton = withTheme(FancyButton); //    FancyThemedButton,    FancyButton //      (* theme*) //  HOC     props. <FancyThemedButton label="Click me!" onClick={handleClick} />; 

Usually HOC'i prokidyvayut properties (props) in the component that they wrap. Unfortunately, refs are not thrown . This means that we cannot attach ref to FancyButton when using FancyThemedButton. It turns out that it is impossible to call focus() .

The forwardRef API solves this problem by offering to intercept the ref and send it on as a normal property.

 function withTheme(Component) { //  ,  "ref"   React.forwardRef. function ThemedComponent(props, ref) { return ( <ThemeContext.Consumer> {theme => ( <Component {...props} ref={ref} theme={theme} /> )} </ThemeContext.Consumer> ); } //     , //         DevTools, // , "ForwardRef(withTheme(MyComponent))" const name = Component.displayName || Component.name; ThemedComponent.displayName = `withTheme(${name})`; //  React  ref  ThemedComponent. return React.forwardRef(ThemedComponent); } const fancyButtonRef = React.createRef(); //  fancyButtonRef   FancyButton <FancyThemedButton label="Click me!" onClick={handleClick} ref={fancyButtonRef} />; 

Changes in life cycle methods (lifecycle methods)

The component creation API using the class has remained almost unchanged for several years. However, we added support for new "features" (such as error boundaries or the future async rendering mode ) for which this model was not ready as it should.

For example, with the current API it is very easy to block the initial component rendering ( initial render ) with irrelevant logic. In part, this is due to the fact that there are several options for solving the problems posed, and therefore it is not easy to choose the best. We noticed that error handling is often overlooked and this can lead to memory leaks (which in turn will adversely affect async rendering mode in the future). The current class API also complicates our other ideas, such as working on prototyping the React compiler .

Most of these problems are associated with the following lifecycle methods: componentWillMount , componentWillReceiveProps, and ComponentWillUpdate . These methods also make the most of the confusion in the React community. Therefore, we are going to abandon them in favor of a better alternative.

Of course, we understand that such changes will affect a huge number of existing components. Therefore, migration will be as gradual as possible. We will also offer ways of retreat (We have 50,000 components on Facebook. We also need a gradual update).

Deprecation (obsolete method) warning will be included in future 16.x releases, but support for the current "life cycles" will work until version 17. Also, in the seventeenth version you can use them with the UNSAFE_ prefix. We have prepared an automatic script for renaming.

In addition to the future "deprecated" life cycle methods, we added a couple of new ones:

• getDerivedStateFromProps - alternative for componentWillReceiveProps
• getSnapshotBeforeUpdate is an alternative to safely reading properties from the DOM before the update happens.

More about the change in lifecycle here.

StrictMode component

StrictMode is a tool for finding potential problems in your application. Like Fragment, StrictMode is not visually rendered. This component activates additional checks and warnings.

StrictMode works only in development mode ( in development mode, not in "prode" )

Although it is impossible to catch all the problem areas (for example, some types of mutations), the StrictMode component will help in many situations. If you see warnings in strict mode , then most likely you will have bugs in async rendering mode .

In version 16.3, StrictMode can:

• find components using unsafe (old) lifecycle methods
• warn about using the old API ref notation as a string
• track down unexpected side effects

Additional functionality will be added in future React releases.

More about StrictMode here.