React v.16.3.0 released

Original author: Brian Vaughn
  • Transfer

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


Official Context API


For many years, React has been providing an experimental contextual API. Even if it was a powerful “thing”, the use of such an API was at risk, since we all wanted to replace the “experimental” API.


Version 16.3 introduces a new context API, which is effective immediately, and supports both static type checking ( static checking of the type ) as well as deep renovation ( deep updates ).


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

Below is an example that shows how you can "prokinut" design theme ( theme is ), using the new API:


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

More about the context API here.


createRef API


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


Version 16.3 adds a new option for managing refs, which offers the convenience of specifying ref as a string without flaws:


class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.inputRef = React.createRef();
  }
  render() {
    return ;
  }
  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 HOCs) are a convenient 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 "thread" the theme as a property ( props ):


function withTheme(Component) {
  return function ThemedComponent(props) {
    return (
      
        {theme => }
      
    );
  };
}

We can use the HOC, to bind the components with the properties of themes ( theme is ) out of context ( context The ) without 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 (
      
    );
  }
}
const FancyThemedButton = withTheme(FancyButton);
// Мы можем отрисовать FancyThemedButton, как будто это FancyButton
// Компонент автоматически получит текущую тему (*свойство theme*)
// И HOC прокинет его вниз через props.
;

Typically, HOCs throw properties (props) into the component that they wrap. Unfortunately, refs do not throw . This means that we cannot attach ref to FancyButton when we use FancyThemedButton. It turns out that focus()it is impossible to call .


The forwardRef API solves this problem by proposing to intercept ref and send it further as a regular property.


function withTheme(Component) {
  // обратите внимание, что "ref" предоставлен нам React.forwardRef.
  function ThemedComponent(props, ref) {
    return (
      
        {theme => (
          
        )}
      
    );
  }
  // Следующие несколько строк кода необязательны,
  // они нужны чтобы дать компоненту понятное имя в 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
;

Changes in lifecycle methods


The API for creating components using the class has not changed 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 simple to block the initial rendering of the component ( initial render ) by irrelevant logic. In part, this is due to the fact that there are several options for solving the tasks, and therefore choosing the best is not easy. We noticed that error handling is often neglected and this can lead to memory leaks (which in turn will adversely affect asynchronous rendering mode in the future ). The current class API also complicates our other ideas, for example, work on prototyping the React compiler .


Most of these problems are related to the following lifecycle methods: componentWillMount , componentWillReceiveProps, and ComponentWillUpdate . These methods also add the most confusion to 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 to retreat (We have 50,000 components on Facebook. We also need a gradual upgrade).


Deprecation (deprecated method) warning will be included in future 16.x releases, but support for 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 future deprecated life cycle methods, we have added a couple of new ones:



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 only works in development mode ( in development mode, not in "prod" )

Despite the fact that 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 a warning in "strict mode" ( strict mode ), then most likely you will have bugs in asynchronous rendering mode ( the async rendering mode ).


In version 16.3, StrictMode can:


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

Additional functionality will be added in future React releases.


More about StrictMode here.


Also popular now: