Member-only story
One of the most important aspects of clean code — code that will survive the long haul and thrive in large organizations and teams — is being testable. Testable code is confident code. It can be refactored without regressive behavior. It can be extended without introducing bugs. Testable code is a staple of a healthy application, and when it comes to React apps, testing is often unclear.
With React hooks being such a new introduction to the library, not too many teams have established testable code design patterns. Extending my previous article on Optimal file structure for React applications, I am aiming to give this topic the focus and attention it deserves. If you have not given said article a read, it is recommended, as this article will assume your file structure matches.
A React component should have one hook. 🎣
A React component’s hook can be comprised of multiple hooks.
Despite the move from class components to hooks, React components still thrive under the model of container and view. Before, a “smart” container managed and manipulated the state as needed before passing it as props to a “dumb” view component. This division of labor works for a reason. When data flow is unidirectional, it is difficult to manifest spaghetti code.
