A Couple of Thoughts about React / Redux Data (re)Fetching

With all of the craze in web development around React and Redux currently, we at PMG started using it about a year ago and have adopted it in most of our tools that run in the browser. It has made working with Javascript and the presentation layer much more enjoyable than what has been done in the past. If I may say so, using these technologies is the first time I haven’t disliked working with Javascript – but that’s another conversation.

Our development team has run into a couple of simple issues with the React / Redux combo around fetching data, and I am here to share some of my thoughts and fixes concerning the matter.

1. Usage of actions and fetching data in a Component‘s componentWillReceiveProps(nextProps) method.

The issue here is that a component may get new props without being unmounted and remounted (or destroyed and created). A real world example of this possibility is let’s say you have a client (or any other entity type) dropdown in a navbar or some other area of the app. And selecting a client from this dropdown takes you to a dashboard for that entity. Obviously, you will want to fetch your component in componentWillMount() to have the data to render out the component.

But what if the user clicks on another client from the drop-down while on the client dashboard? In React, this will not cause a new component to be created and rendered. Thus you will not have a call to componentWillMount() and the user will be looking at a dashboard for the client they were just looking at, not the one they clicked on. So, you can get around this by overriding the componentWillReceiveProps() method. React will call this method with the new props of the component (the new props that have the new id of the entity the user just clicked on). And here you can ensure that the id did change, and if so, fetch the new entity.
Following is an example component that does just this:

ClientDashboard.js

import React, { Component, PropTypes } from 'react';

export default class ClientDashboard extends Component {
	static propTypes = {
		clientId: PropTypes.string.isRequired,
		client: PropTypes.object,
		fetchClient: PropTypes.func.isRequired,
	}

	componentWillMount() {
		this.props.fetchClient(this.props.clientId);
	}

	componentWillReceiveProps(nextProps) {
		if (this.props.clientId !== nextProps.clientId) {
			this.props.fetchClient(nextProps.clientId);
		}
	}

	render() {
		//return something displaying this.props.client.
	}
}

2. Checking a collection’s contextual state to know whether or not a new fetch is actually needed – or a “cache” check.

The issue here comes from a possible desire to not want to have to fetch a collection every time a collection component is being rendered. Let’s imagine (or know from practice) that you have a collection of components that are all displayed in different tabs or sections of a page. And the tabs can change, thus requiring fetches for all of the collections in each component. So what happens if the user goes from tab “A” to tab “B” then back to tab “A”? Well, if your “A” and “B” components fetch the collection in componentWillMount() and your actions blindly always make a call to the backend, then you potentially get a lot of network talk for these components over and over again. But what if the data in these collections doesn’t change that often? And you really only need to fetch once every five or ten minutes? What if knew whether or the context around the collection changed and if we really need to refetch? If there is no need for a refetch, then the state is already in your Redux store, and the user doesn’t have to wait for loading something they just looked at.

If we think back to issue 1, then imagine this situation occurring “inside” of issue 1. A client has a collection of imports and exports. The imports and exports components are rendered within tabs on the client page. And switching back and forth between the tabs happens regularly. When the user stays within the same client but changes between exports and imports, then refetching every time a component is mounted could be overkill.

So here I suggest keeping the client’s id in the import and export collection state. Call it a “parent id” or a “cache id.” Then when you call, this.props.fetchImports(this.props.clientId) the action creator can examine the state, see that the client id did not change from the last fetch, and the imports do not need to be refetched.

Obviously, there are other considerations for this situation. The parent id may be only part of what determines if a refetch is needed. Say time since the last fetch is also important. Or the user clicks a refresh button, and you want to force a refetch no matter what the state is. All of these options can easily be added to your action creators and abstracted away for the collections you deal with in your application.

React and Redux give the developer a lot of flexibility in how you present and load data to the user. And over the past years in web development, we at PMG have picked up on these patterns that we thought would be beneficial to share.