Understanding React 16.3 Updates

Published
Share this post on BlueskySee discussion on Bluesky

If you are a frontend engineer working with view libraries than you have most likely heard about the recent React updates launched with 16.3.0 (and 16.3.1). I have been using some of these features for a bit, and noticed some interesting patterns that begin to appear, and some pitfalls that many developers might fall into when migrating components and whole applications to use the new 16.3 features.

Context

I could write a full blog post about the new context api in React 16.3, however I want to keep the post relatively short and to the point.

A few of the patterns I have noticed with the new context api are:

Providing a default context can be useful.

If you build UI components for use across a larger application, its unreasonable to require all of the other react components using your components to also wrap your component in a provider. A powerful feature of the new context api is being able to define an initial context value for the consumers. This value will be used when your context consuming component is rendered in a component tree without a provider parent.

1import React, { createContext } from 'react';
2
3const { Provider, Consumer } = createContext({
4  theme: {
5    light: '#f8f9f9',
6    dark: '#374047',
7  },
8});
9
10const UIComponent = props => (
11  <Consumer>
12    {({ theme }) => (
13      <button
14        style={{
15          color: theme.light,
16          background: theme.dark,
17        }}
18      >
19        Button
20      </button>
21    )}
22  </Consumer>
23);
1import React, { createContext } from 'react';
2
3const { Provider, Consumer } = createContext({
4  theme: {
5    light: '#f8f9f9',
6    dark: '#374047',
7  },
8});
9
10const UIComponent = props => (
11  <Consumer>
12    {({ theme }) => (
13      <button
14        style={{
15          color: theme.light,
16          background: theme.dark,
17        }}
18      >
19        Button
20      </button>
21    )}
22  </Consumer>
23);

A minor performance improvement for context provider wrappers is to use a key from state as the context provided

If you want to wrap your context provider in some wrapper that provides an update method of some sort, you generally will do something like this:

1export default class ContextProvider extends Component {
2  state = {
3    light: '#f8f9f9',
4    dark: '#374047',
5  };
6  updateTheme = args => {
7    /* Implementation detail */
8  };
9  render() {
10    return (
11      <Provider
12        // ⚠️⚠️⚠️⚠️
13        value={{
14          ...this.state,
15          updateTheme: this.updateTheme,
16        }}
17      >
18        {this.props.children}
19      </Provider>
20    );
21  }
22}
1export default class ContextProvider extends Component {
2  state = {
3    light: '#f8f9f9',
4    dark: '#374047',
5  };
6  updateTheme = args => {
7    /* Implementation detail */
8  };
9  render() {
10    return (
11      <Provider
12        // ⚠️⚠️⚠️⚠️
13        value={{
14          ...this.state,
15          updateTheme: this.updateTheme,
16        }}
17      >
18        {this.props.children}
19      </Provider>
20    );
21  }
22}

However! This will potentially cause unnecessary re-renders, as now the value provided to the consumers will always be a new object!!!

A simple way to get around this is to construct a nested object in state that is the context you want to provide:

1export default class ContextProvider extends Component {
2  /* Note this needs to be defined before state below */
3  updateTheme = args => {
4    /* Implementation detail */
5  };
6  state = {
7    light: '#f8f9f9',
8    dark: '#374047',
9    context: {
10      light: '#f8f9f9',
11      dark: '#374047',
12      updateTheme: this.updateTheme,
13    },
14  };
15  render() {
16    return (
17      <Provider value={this.state.context}>
18        {this.props.children}
19      </Provider>
20    );
21  }
22}
1export default class ContextProvider extends Component {
2  /* Note this needs to be defined before state below */
3  updateTheme = args => {
4    /* Implementation detail */
5  };
6  state = {
7    light: '#f8f9f9',
8    dark: '#374047',
9    context: {
10      light: '#f8f9f9',
11      dark: '#374047',
12      updateTheme: this.updateTheme,
13    },
14  };
15  render() {
16    return (
17      <Provider value={this.state.context}>
18        {this.props.children}
19      </Provider>
20    );
21  }
22}

getDerivedStateFromProps

So far I have noticed three primary pitfalls of the new static getDerivedStateFromProps lifecycle method on React components.

Always return a value at the end of the getDerivedStateFromProps method.

React will ensure to warn you if you ever return undefined (which will be the return value if you don't actively return anything) from the method. A good example of when this might happen is like this:

1class App extends React.Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    if (nextProps.value !== prevState.value) {
4      return {
5        value: nextProps.value,
6      };
7    }
8    // ⚠️⚠️⚠️⚠️
9  }
10
11  /* implementation detail */
12}
1class App extends React.Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    if (nextProps.value !== prevState.value) {
4      return {
5        value: nextProps.value,
6      };
7    }
8    // ⚠️⚠️⚠️⚠️
9  }
10
11  /* implementation detail */
12}

Note that if nextProps.value does equal prevState.value then the method will return undefined.

One tip I suggest to resolve this potential issue is to start by adding one last return null at the end of the method when you first add getDerivedStateFromProps:

1class App extends React.Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    if (nextProps.value !== prevState.value) {
4      return {
5        value: nextProps.value,
6      };
7    }
8    // Start by adding this, then modify the logic above
9    return null;
10  }
11
12  /* implementation detail */
13}
1class App extends React.Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    if (nextProps.value !== prevState.value) {
4      return {
5        value: nextProps.value,
6      };
7    }
8    // Start by adding this, then modify the logic above
9    return null;
10  }
11
12  /* implementation detail */
13}

getDerivedStateFromProps will overwrite any initial state if you conditionally fall back to default values

This was a difficult one to debug, but one key thing to keep in mind when using getDerivedStateFromProps is that it will run before the first-ever render. This can lead to some issues with colliding values between the return of this method and your component's initial state, for example:

1class App extends Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    if (nextProps.value !== prevState.value) {
4      return {
5        value: nextProps.value,
6      };
7    }
8    return null;
9  }
10
11  state = {
12    // ⚠️⚠️⚠️⚠️
13    value: this.props.value || 0,
14  };
15
16  /* implementation detail */
17}
1class App extends Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    if (nextProps.value !== prevState.value) {
4      return {
5        value: nextProps.value,
6      };
7    }
8    return null;
9  }
10
11  state = {
12    // ⚠️⚠️⚠️⚠️
13    value: this.props.value || 0,
14  };
15
16  /* implementation detail */
17}

In the above snippet, if this.props.value is null or undefined initially, then many would think that the value of this.state.value on the initial render will be 0, unfortunately because of getDerivedStateFromProps, this.state.value will be this.props.value always and will never be the fallback of 0.

So far the only way I found to get around this is to either track if it is the first time calling getDerivedStateFromProps, or to check that nextProps.value is neither null or undefined before the !== comparison.

  1. If you need to compare to prevProps you need to store that information in state

This is kind of the largest discussion about this new feature, many developers have voiced their opinions in adding prevProps as another argument to the method to compare new props with the previous props. The only way to get around this is to store the needed information from prevProps into state:

1class App extends Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    const { prevProps } = prevState;
4    if (nextProps.value !== prevProps.value) {
5      return {
6        prevProps: nextProps,
7        someDerivedValue: nextProps.value,
8      };
9    }
10    return null;
11  }
12
13  state = {
14    prevProps: this.props,
15    someDerivedValue: 0,
16  };
17}
1class App extends Component {
2  static getDerivedStateFromProps(nextProps, prevState) {
3    const { prevProps } = prevState;
4    if (nextProps.value !== prevProps.value) {
5      return {
6        prevProps: nextProps,
7        someDerivedValue: nextProps.value,
8      };
9    }
10    return null;
11  }
12
13  state = {
14    prevProps: this.props,
15    someDerivedValue: 0,
16  };
17}

getSnapshotBeforeUpdate

Coming soon, I haven't written too many components that need this just yet. But I have a feeling I will be using this a decent amount!

Tags:

ReactJavaScriptWeb Development