What happened

The React ecosystem has long needed a “grown-up” architecture without mandating one global state manager. Bulletproof React answers that with patterns from real production codebases.

Core pieces of the approach:

• Feature-based structure — each feature lives in its own module with components, hooks, API calls, and types. Shared code goes in shared; routing glue lives in app.
• ESLint and import boundaries — feature A does not deep-import feature B’s internals; only the public layer API. That lowers coupling and makes refactors safer.
• Four state types:
  • UI state — local UI (modals, tabs, useState);
  • Application state — client business logic (often Zustand or Context);
  • Server cache — API data (React Query, SWR, and similar);
  • URL state — filters, pagination, tabs in the address bar.
• Security — tokens in httpOnly cookies, route and component guards at several layers, not just hiding a button in the UI.

The Habr article walks through the philosophy using a familiar pain: you open the repo after a few months — or onboard a new developer — and spend a week hunting for where logic was hidden.

Why it matters

React deliberately does not prescribe folder layout. That is a win on a small pet project. On a team of three with a dozen features, it becomes a liability: everyone codes “how they used to,” and merge conflicts plus fear of touching someone else’s module become normal.

Bulletproof React does not ban Redux, Zustand, or Context — it clarifies when each tool fits. Server cache should not be duplicated into a global store “just in case.” URL state should not be spread across ten useEffect hooks.

If you build ERP-style UIs or long-lived admin panels, this reads more like engineering discipline than a trendy stack.

In practice

What you can do on the next sprint:

1. Extract 1–2 features into dedicated folders with index.ts as the public boundary; block deep imports via eslint-plugin-import or boundary rules.
2. Audit state: list screens → for each, label which of the four types apply; remove duplicates (e.g. orders both in React Query and Redux without a reason).
3. Document a one-page “how we lay out files” in README or an ADR — even a short guide cuts onboarding time.
4. Do not copy blindly — on a five-screen app, full Bulletproof may be overkill; add layers as complexity grows.

If you already use Feature-Sliced Design or a modular frontend monolith, much will feel familiar — Bulletproof React is closer to a pragmatic “minimum order” for React teams.

Takeaway

Bulletproof React is about predictability: structure, imports, state, and security are explicit, not “how the repo author felt that week.” It is not a silver bullet, but a solid checklist before the repository becomes a maze again.