What Are React Design Patterns (And Why They Are Not Gang of Four)

The previous chapter on layout components was already a design pattern, even if we did not call it that. A pattern is just an effective solution to a recurring problem. Not any solution. An effective one.

That word matters. Every team eventually solves the problem of sharing logic between components. Some solutions are clean and composable. Others produce brittle code that is hard to test and harder to change. Design patterns are the solutions that actually work.

React Patterns Are Not OOP Patterns

If you have read about design patterns before, you probably encountered the Gang of Four catalog: Singleton, Factory, Observer, Decorator. Those patterns emerged from object-oriented systems and describe how objects relate to each other.

React patterns are different. They emerged from specific problems that come up when you build UIs with components and one-directional data flow.

The problems they solve are concrete:

• How do you reuse layout code without repeating the same flex-container CSS in every component?
• How do you share data-fetching logic between two components without duplicating useEffect calls?
• How do you build a form system that handles validation and submission consistently?
• How do you apply functional programming ideas like recursion to component trees?

Each of these has a pattern that solves it cleanly. The next several posts in this series cover them one by one.

The Map

Here is what the patterns chapter covers and the problem each one addresses:

Layout components handle reusable arrangement. The split screen, the list, and the modal from the previous chapter all belong here. Content components stay unaware of where they live.

Container components handle data loading. When two child components need the same fetched data, you do not duplicate the fetch. You extract it into a container that loads the data and passes it down automatically.

Controlled and uncontrolled components handle form state. The distinction between a component that owns its state and one that lets the parent own it becomes critical when building form libraries.

Higher-order components wrap a component to inject behavior. They were the primary reuse mechanism before hooks.

Render props pass rendering logic as a function prop. They solve the same problem as HOCs with a different trade-off.

Recursive components apply functional programming to component trees. Useful for deeply nested structures like file trees and menus.

Why This Order

Each pattern in this series builds on the previous one. Container components extend the separation-of-concerns idea from layout components. HOCs and render props generalize the container idea further.

Understanding them in this order means each new pattern slots into a mental model you already have.

The next post builds the first container component from scratch.

The Essentials

1. A design pattern is an effective solution to a recurring problem, not just any solution.
2. React patterns address UI-specific problems: layout reuse, data sharing, form handling, functional composition.
3. These are not Gang of Four patterns. The problems and solutions are different in a component-based UI model.
4. Each pattern in this series extends the separation-of-concerns idea from the previous one.

Further Reading and Watching

• React Hooks: What Will Happen to the Container/Presenter Pattern? by Kent C. Dodds. Covers how hooks changed the patterns landscape and what still applies.
• React docs: Reusing Logic with Custom Hooks shows where the modern React answer to logic reuse lives, and why patterns like HOCs and render props are less needed than they used to be.