Modern React development offers a toolbox of design patterns—but not every pattern is worth its weight in every code‑base. In smaller apps you win by staying lightweight; in enterprise‑scale products you can’t survive without architectural patterns that coordinate dozens of teams. This guide maps 16 popular patterns from *Learning Patterns* to three common project sizes so you can pick the right tool for the right moment.
1. Small Projects — “One‑dev / One‑feature” size
Why keep it simple?
Small apps (≤ 5 components, a single bundle) need the fewest abstractions. Hooks, ES modules and singletons already cover reuse, state and configuration; anything deeper adds friction.
Patterns worth using
| Pattern | How it works | Why useful in tiny apps |
|---|---|---|
| Hooks |
useState, useEffect, custom hooks share stateful logic inside functional components. |
Replaces HOCs/Render‑props, no wrapper hell |
| Module | Each file exports public members; private helpers stay hidden. | Encapsulation prevents global leaks without extra layers |
| Factory | Returns a component/service variant based on params. | Generate small themed widgets or API clients on demand |
| Singleton | One global instance accessed via import. | Ideal for analytics SDK, event‑bus with minimal boilerplate |
| Provider (Context) |
<ThemeProvider> supplies values to the tree, consumed with useContext. |
Eliminates prop‑drilling for theme or locale |
10 Typical Small‑size Projects
- Personal portfolio site
- Weather widget SPA
- Markdown notes app
- Pomodoro timer
- Todo‑list with localStorage
- Single‑page landing page with form
- Image gallery viewer
- QR‑code generator
- Unit‑converter tool
- Countdown timer for events
Small‑project take‑away
Lean on Hooks + Modules first; add Provider or Singleton only when two+ components need the same data.
2. Medium Projects — “Feature‑team / Shared library” size
Why patterns matter here
With tens of components and several developers, you’re coordinating data flow, code reuse and cross‑cutting concerns. Patterns that separate view from data and formalise side effects pay off.
Patterns that shine
| Pattern | How it works | Medium‑scale benefit |
|---|---|---|
| Provider | Context providers hold auth, theme, feature flags. | Central source of truth across pages |
| Container / Presentational | Containers fetch data, hand it to dumb UI components. | Keeps UI reusable, eases testing |
| Compound Components | Parent shares internal context with children (e.g. Tabs). | Build cohesive, flexible widgets. |
| Observer | Observable streams notify subscribers; consumed via hooks. | Live updates from sockets, RxJS |
| Proxy | Wrapper intercepts calls to API / storage. | Inject headers, logging, caching in one place |
| Command | Encapsulates an action with execute/undo. |
Enables undo/redo, time‑travel debugging |
10 Typical Medium‑size Projects
- Blogging platform with admin panel
- E‑commerce dashboard
- Multi‑step form wizard with autosave
- SaaS analytics portal
- Internal CRM for small team
- Real‑time chat app
- Kanban board like Trello clone
- Learning‑management system module
- Company wiki / knowledge‑base
- Video streaming dashboard with user roles
Medium‑project take‑away
As features grow, explicit boundaries (Provider, Containers) and event‑driven patterns (Observer, Command) keep complexity readable.
3. Large Projects — “Multi‑squad / Multi‑year” scale
Why you need architecture
Enterprise apps juggle thousands of components, micro‑front‑ends, and real‑time data. Performance and team isolation become existential.
Heavy‑hitters
| Pattern | How it works | Large‑scale strength |
|---|---|---|
| Mediator / Middleware | Central object (Redux middleware, service bus) routes messages. | Decouples features, enforces policies |
| Flyweight | Shares immutable data between many similar objects (virtual lists). | Cuts memory & re‑render costs in huge datasets |
| Proxy | Same as medium, but now adds retries, circuit‑breakers. | Gate‑keeps unstable backends |
| Observer | Streams power notifications, analytics, collaborative cursors. | Scale to millions of updates without prop‑drilling |
| Factory | Generates per‑tenant themes / API clients for white‑label apps. | Supports SaaS multi‑tenant configs |
| Singleton | One expensive WebGL renderer or analytics client per app shell. | Prevents duplicate heavy resources |
| Provider | Shared auth/theme for micro‑front‑ends. | Keeps UX consistent across teams |
| Command | Action objects stored in history stack. | Enables full audit log & branching undo |
10 Typical Large‑size Projects
- Enterprise resource‑planning (ERP) suite
- Global e‑commerce marketplace
- Real‑time collaborative document editor
- Cloud management console (AWS‑like)
- Social media platform
- Banking dashboard with live market feeds
- Healthcare electronic records portal
- Multi‑tenant SaaS CRM
- Streaming analytics monitoring (IoT)
- Omnichannel contact‑center UI
Large‑project take‑away
Architecture patterns (Mediator, Flyweight) prevent both runtime meltdown and organisational gridlock; combine with Providers and Factories to standardise shared behaviour.
Final Thoughts
Start as simple as you can and scale patterns only when pain appears. Hooks and Modules cover most microscopic apps. As a team grows, adopt Providers, Containers and event‑driven patterns. Once multiple squads ship in the same bundle, treat patterns like Mediator or Flyweight as non‑negotiable infrastructure. Choose patterns for today’s size, but keep tomorrow’s scale in mind.
Top comments (0)