Common React Mistakes Part 2: Connecting too many Components

In part one we talked about Monolithic Components and a Lack of Abstraction. In this post, we will continue talking about best practices we’ve found working with React/Redux over the past year.

Connecting too many components is an issue that should be avoided when working in React and Redux. Having too many components connected to the state can cause things to go wrong with updating the data and how it gets displayed on the screen. Read on to see how these issues are avoided.

Manipulation of the state and any rendering of data should be kept separate in order to prevent re-rendering issues which can cause incorrect data to be displayed. Rendering data is solely presenting information to the screen, so changing the state involves accessing and updating the store. If too many components get connected to the store, components may get updated at different (and incorrect) times. This follows the idea of having separate presentational and container components which we will talk about next.

Effective usage of React and Redux relies on the principle of separating presentational and container components. A presentational (or pure) component is one that is solely focused on how things look on the page and therefore does not mutate data, does not have its own state from the store and can only rely on data via incoming props. A container component is concerned with how the data is manipulated and thus makes changes to the state by calling actions, and accesses the store via connect(). A container component can hold both types of components within it, passing props and callbacks down, but it’s not good practice to chain too many together as this can make it hard to track the data flow and maintain. (This is discussed more in the next section.) This separation of logic and design is important because it allows us to write easily reusable components while embracing the React/Redux foundations.

When an overabundance of components are connected, it becomes more difficult to figure out what is causing changes to occur in the page. Unrelated components should not be able to affect one another in order to keep clear what exactly is changing and why. The challenge is finding the sweet spot where connecting components makes sense to the project but doesn’t inhibit another developer from being able to understand the logic behind the data flow and presentation. In addition to adding this additional complication, having too many connected components can cause unnecessary page rendering which can make an app less performant.

Although these issues are avoidable, they can be hard to prevent when jumping into your first React/Redux project. For our team, these concepts were encountered through trial and error and lots of refactoring. Now that we’re aware of best practices though, we’ve been able to maintain our React projects much more efficiently.