React in Enterprise Environment — Experience from Large Projects

Angular 1 taught us what we don’t want. jQuery spaghetti taught us why we need a framework. React 15 taught us that a UI component library can be the foundation of an enterprise application — if you build the right ecosystem around it.

Why React and not Angular 2?¶

At the beginning of 2017, we face a choice: Angular 2 (freshly renamed to Angular 4), React, or Vue.js. Angular offers “batteries included” — routing, forms, HTTP client, dependency injection. React is “just the view layer” — you compose the rest yourself.

For our enterprise project, we chose React. Reasons: flexibility (we choose our own solutions for routing, state, forms), ecosystem (there are orders of magnitude more npm packages for React), hiring (there are more React developers on the market than Angular) and incremental adoption (you can add React to an existing application piece by piece).

Architecture of a Large Project¶

Our project: internal system for a bank, 15 developers, 200+ components, 40+ screens. The structure we chose:

src/
├── components/          # Shared UI components
│   ├── Button/
│   │   ├── Button.jsx
│   │   ├── Button.test.js
│   │   └── Button.css
│   └── DataTable/
├── features/            # Business features (modular)
│   ├── accounts/
│   │   ├── components/
│   │   ├── containers/
│   │   ├── actions.js
│   │   ├── reducer.js
│   │   └── selectors.js
│   └── transactions/
├── services/            # API clients, utilities
├── store/               # Redux store configuration
└── routes/              # React Router definitions

Key decision: feature-based structure instead of type-based (all reducers in one folder, all actions in another). When a developer works on “accounts”, they have everything together.

State Management — Redux¶

Redux is the de facto standard for React state management in 2017. Unidirectional data flow, immutable state, pure reducer functions. For an enterprise application with complex state, it’s a lifesaver — predictable state, time-travel debugging, middleware for side effects.

But Redux has a cost: boilerplate. Action types, action creators, reducers, selectors — for one feature you write 4 files before you get to the UI. We solve this with generators (Plop.js) and conventions.

For async operations, we use redux-saga. Generators are more complex than thunks, but testability and control over side effects is critical in enterprise. Saga can handle cancel, retry, race conditions — things you solve manually in thunks.

Component Library¶

With 15 developers, you need a shared component library. Otherwise, you have 8 different button implementations. We built an internal library on top of React + CSS Modules. Storybook as documentation and playground.

Rules: every component has PropTypes (we hadn’t introduced TypeScript in 2017 yet — we regret this in hindsight), unit test, story in Storybook. Code review doesn’t pass without all three.

Testing¶

Jest for unit tests (fast, snapshot testing, mocking). Enzyme for component testing (shallow rendering, mount, simulate events). Snapshot tests for UI regression — change a component, Jest shows the diff.

Goal: 80% code coverage on business logic (reducers, selectors, utilities). We test UI components for behavior, not implementation. “Click the button, check that the callback was called” — not “check that the div has the active class”.

Performance and Code Splitting¶

200+ components = large bundle. Solution: React Router code splitting with Webpack 2 dynamic imports. Each route loads lazily — initial load under 200 KB gzipped. Webpack Bundle Analyzer revealed that moment.js was taking up 60 KB of locale files that nobody was using.

React Perf tools (React DevTools Profiler didn’t exist in 2017 yet) for identifying unnecessary re-renders. Reselect for memoized selectors. PureComponent instead of Component where it makes sense.

What We Would Do Differently¶

• TypeScript from the start — PropTypes aren’t enough, refactoring 200 components without types is painful
• CSS-in-JS instead of CSS Modules — styled-components would solve theming more elegantly
• Less Redux — not every state belongs in the store, local state is OK for forms and UI
• Mono-repo — component library in a separate repo adds friction, Lerna mono-repo would be better

React Works in Enterprise — With Discipline¶

React doesn’t give you structure — you have to create it. Conventions, code review, shared component library, testing strategy. React’s flexibility is both a strength and weakness. For a small team it’s freedom, for a large team without rules it’s chaos.