The Separation of Reactjs Presentation and State

Components are powerful. They are the building blocks of Reactjs, allowing us to dynamically generate HTML on the fly and attach all the logic we could need through props and state management. When I first started working with react, I often tried to combine those two features into a single component. Since then, I realized that there were other types of responsibility I should separate my components by in addition to just defining elements on the web page. I learned that presentation and logic are better off apart - just because we can combine them doesn't mean we should!

 The first issue caused by combining presentation and state concerns is complexity. I would end up with incredibly complicated components where it was hard to tell what code was shaping the JSX and what code was managing the state. Inevitably, this caused those lines to blur. It became challenging to identify render conditions or see if I had accidentally introduced mutation into my state management. This made these components harder to maintain and reuse.

 This complexity also made testing components very challenging. When a component has too much functionality crammed into it, it becomes difficult to ensure you've covered all of the functionality in your test. The test file would need a mixture of wildly different tests that validated the HTML generated from the component as well as calling the state functions. If you need more than one type of unit test to test the functionality of any “unit,” it’s a good sign that the unit has multiple responsibilities that should be separated.

 When you have so many moving pieces in a single component, you also need to think about how to organize those different types of functions within your code to keep the code bar clean and consistent.

 Now I dedicate one component to any state storage/logic and a separate functional component contains all my jsx code to format data and produce HTML. The logic component can be a class component if you need state and access to lifecycle methods, or you could make this a functional component that utilizes Hooks. You can write tests that explicitly test those functions and methods. Separating state/logic components from presentation concerns makes it easy to replace or enhance your logic components with a state management library like redux with almost no changes to your jsx. It’s incredibly powerful to be able to make significant refactors and improvements strictly through adding or deleting code and making very few changes to existing code.

 The presentation component can always be a simple functional component. The move the react community is making toward stateless functional components endorses this separation. You can easily test every permutation of the generated HTML with some simple Jest snapshot tests. These components become so much more reusable. Presentation components can be wrapped multiple times in different combinations without having to be touched at all.

 Like all things there are occasional exceptions, but overall, separating presentation and logic/state components has been a monumental improvement for how I write react. Our velocity, quality, and meaningful test coverage has improved significantly. I know many have an aversion to more files but, to me, having smaller, more testable, and better organized units always outweighs the perceived negative of having more files.