Forem: Keshav Agarwal

How We Built a Code Quality Pipeline That Roasts Bad PRs Before Humans Have To

Keshav Agarwal — Sun, 15 Mar 2026 04:58:33 +0000

The Slow Descent Into "It's Fine, Ship It"

Nobody wakes up one day and decides to ruin a codebase. It's more of a group activity that happens gradually, like a potluck where everyone brings potato salad.

When our team was small — two or three devs who reviewed every line — code quality maintained itself through osmosis. We all knew the patterns. We all agreed on formatting. Nobody wrote an 800-line component because someone would notice and gently question their life choices.

Then the team grew. More features, more devs, more PRs flying in simultaneously. And the cracks started showing:

Components quietly ballooning past 700 lines — because "I'll refactor it later" (narrator: they did not refactor it later)
Formatting roulette: tabs here, spaces there, trailing commas in this file but not that one
Duplicate i18n messages across different feature modules — the same English string defined in three different messages.js files with three different IDs, leading to translation mismatches and wasted localization budget (more on this — it's a bigger deal than it sounds)
console.log('HERE') statements left behind like breadcrumbs from a debugging session that ended three sprints ago
var declarations showing up in a modern codebase, haunting us like a ghost from JavaScript past

No single dramatic incident. No production outage. Just a slow, steady erosion of the standards we thought were obvious. Death by a thousand "LGTM, merge it" reviews.

Code review alone couldn't save us — reviewers are human, PRs are long, and "does this file exceed 500 lines?" isn't the kind of thing you catch at 11 PM after your third coffee. We needed robots. Specifically, mean robots that block your PR and make you feel bad about your formatting choices.

"But What About CodeRabbit / AI Review Tools?"

Fair question. We use CodeRabbit for PR reviews and it's great at catching logic issues and suggesting improvements. But on the free tiers, it suggests fixes — it doesn't enforce them. A developer can read CodeRabbit’s “you should fix this formatting” comment, nod thoughtfully… and merge anyway.

We needed something with teeth. Something that physically prevents a merge until the code meets the bar. So we built our own enforcement layer with GitHub Actions.

"Why Not Biome / oxlint / Modern Linters?"

Also a fair question. New-gen linters like Biome are blazing fast and genuinely exciting. But our build pipelines are still on older Node versions, and our entire toolchain — Babel plugins, Webpack config, ESLint plugins for Redux-Saga, styled-components accessibility — is deeply integrated with the ESLint ecosystem. Migrating to Biome would mean rebuilding a lot of that plugin infrastructure.

ESLint isn't the shiny new thing, but it's battle-tested, extensible, and — critically — it works with our current stack without a rewrite. Sometimes the boring tool that ships today beats the exciting tool that requires a migration quarter.

The Architecture: The Quality Gauntlet

We ended up with a layered quality pipeline. Each layer catches different things at different stages, so by the time code reaches master, it's been interrogated more thoroughly than a suspect in a crime drama.

┌──────────────────────────────────────────────────────────────┐
│                    QUALITY PIPELINE                          │
│                 (a.k.a. "The Gauntlet")                      │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  The Foundation: THE RULEBOOK                                │
│  ┌────────────────────────────────────────────────┐          │
│  │  .eslintrc.yml — the opinionated ruleset       │          │
│  │  max-lines, complexity, prop-types, camelcase  │          │
│  │  + smart overrides for reducers/sagas/tests    │          │
│  └────────────────────────────────────────────────┘          │
│         │ powers both layers below                           │
│         v                                                    │
│  Layer 1: COMMIT TIME (local)                                │
│  ┌────────────────────────────────────────────────┐          │
│  │  lint-staged                                   │          │
│  │  • ESLint --fix on staged *.js files           │          │
│  │  • Prettier on staged *.json files             │          │
│  │  Catches: formatting, auto-fixable errors      │          │
│  └────────────────────────────────────────────────┘          │
│         │                                                    │
│         v                                                    │
│  Layer 2: PR TIME (GitHub Actions — run in parallel)         │
│  ┌──────────────┐ ┌─────────────────┐ ┌───────────┐          │
│  │ JS Linter    │ │ Duplicate i18n  │ │ Gitleaks  │          │
│  │ (full ESLint)│ │ (cross-file)    │ │ (secrets) │          │
│  └──────┬───────┘ └───────┬─────────┘ └─────┬─────┘          │
│         └────────────┬────┘                  │               │
│                      v                       │               │
│              Merge blocked until ALL pass ◄───┘              │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Each layer exists because the previous one isn't enough. The ESLint rulebook defines what matters — it's the foundation that powers everything else. lint-staged catches formatting but only runs on staged files. GitHub Actions catches everything but only on PRs. All three together form the net. One layer alone is a suggestion. Three layers together are the law.

The PR checks run in parallel — the linter, duplicate i18n check, and Gitleaks scan are independent workflows that kick off simultaneously. Since they don't share state, GitHub runs them on separate runners at the same time. For most repos, the entire suite finishes in under a minute. You push, you wait a few seconds, and you know exactly where you stand.

Layer 1: Pre-Commit Hooks (lint-staged)

The first line of defense runs before code ever leaves your machine:

{
  "lint-staged": {
    "*.js": "npm run lint:eslint:fix",
    "*.json": "prettier --write"
  },
  "pre-commit": "lint:staged"
}

Every git commit triggers this. JavaScript files get ESLint with --fix — formatting issues, missing semicolons, trailing spaces are auto-corrected before you even see them. JSON files get Prettier. The developer doesn't have to remember anything. The formatting wars are over before they start.

Note: If you're on an older version of lint-staged (< v10), you'll need to add "git add --force" after each command. v10+ handles re-staging automatically.

But lint-staged only touches staged files. If ComponentA.js is clean but ComponentB.js already has a linting error, lint-staged won't catch it. Also, a developer can bypass this entirely with git commit --no-verify. (We trust our team, but we also trust automation more.)

That's where the real enforcers come in.

Layer 2: GitHub Actions — The PR Gatekeepers

The Linter Workflow

Every PR triggers a full ESLint pass across the entire codebase. Here's the workflow (condensed — the real one installs ~30 packages):

name: JavaScript Linting Validator

on:
  pull_request:
    types: [opened, reopened, synchronize]
    branches:
      - '*'

jobs:
  js-lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'

      # Nuclear option: clean slate every time
      - run: rm -f .npmrc
      - run: rm -rf node_modules package-lock.json
      - run: npm cache clean --force

      # Install only linting deps (not the whole project)
      - name: Install ESLint + Prettier + Babel deps
        run: |
          npm install "@babel/core@^7.26.7" \
            "@babel/eslint-parser@^7.26.5" \
            "eslint@^8.57.0" \
            "eslint-config-prettier@^10.0.1" \
            "eslint-plugin-react@^7.37.4" \
            "eslint-plugin-prettier@^5.2.3" \
            "prettier@^3.4.2" \
            # ... ~20 more packages
            --no-save --silent

      - run: npx eslint .

A few things worth calling out:

The clean-slate install. We nuke node_modules, package-lock.json, .npmrc, and the npm cache before installing. Aggressive? Yes. It ensures we're never tripped up by stale local artifacts. One tradeoff worth noting: deleting the lockfile means CI resolves versions independently from your local setup, so there's a slim chance of version drift between what devs run locally and what CI installs. For linting-only deps this is a low risk we accept — but for production installs, you'd want to keep the lockfile.

Every PR, every branch. Not just master — every branch. If your feature branch has a lint error, you know immediately.

It blocks the merge. This is a required check. No "I'll fix it in the next PR" escape hatch. The robot says no, the robot means no.

The Duplicate i18n Check (Our Favorite)

This one solves a problem that quietly costs real money at scale, and we haven't seen many teams talk about it.

The problem: In a large internationalized codebase, many features define their own messages.js file for react-intl. Over time, different developers writing similar features independently define the same English string:

// In CreateEntity/messages.js
defineMessages({
  saveButton: { id: 'app.createEntity.save', defaultMessage: 'Save' },
});

// In EditEntity/messages.js (different dev, different sprint)
defineMessages({
  saveAction: { id: 'app.editEntity.save', defaultMessage: 'Save' },
});

Two different IDs, same defaultMessage. In English, no one notices. But when you send these to a translation vendor, you're paying to translate the same string multiple times. Worse — different translators might translate "Save" differently, so users see inconsistent text across the product. One screen says the equivalent of "Store" and another says "Keep." Subtle, but it erodes trust.

At scale — dozens of languages, hundreds of message strings — these duplicates add up fast in translation costs and QA time.

The workflow is dead simple:

name: Check Duplicate i18n Messages

on:
  pull_request:
    types: [opened, reopened, synchronize]
    branches: ['*']

jobs:
  check-duplicates:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
      - run: node scripts/check-duplicate-messages.js

The custom script behind it:

Recursively finds every messages.js and message.js file
Regex-extracts all { id: '...', defaultMessage: '...' } definitions — handling single-line, multi-line, and template literal formats
Builds a map of message values to their file locations
Flags any defaultMessage that appears in two or more different files

When it fails, the output is clear:

Found 47 message files to check

CROSS-FILE DUPLICATE MESSAGE VALUE FOUND
Value: "Save"
  In app/components/pages/CreateEntity/messages.js:
    - ID: app.createEntity.save
  In app/components/pages/EditEntity/messages.js:
    - ID: app.editEntity.save

Cross-file duplicate message values found.

PR blocked. Fix is always the same: extract the shared string to a common messages file or reuse the existing definition. This single check has saved us from dozens of translation inconsistencies — and a non-trivial amount of translation spend.

Gitleaks Secret Scan

We also run Gitleaks on every PR to master. It scans for accidentally committed secrets — API keys, tokens, credentials:

name: Gitleaks Secret Scan

on:
  pull_request:
    types: [opened, reopened, synchronize]
    branches: [master]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Standard security hygiene. If you're not doing this, start today. It catches the kind of mistake that turns a normal Tuesday into an incident response.

The Rulebook: ESLint Rules That Actually Matter

The rules are the backbone. Anyone can set up a linter — the interesting part is what you choose to enforce. Here's our opinionated ruleset with the "why" behind each choice.

`max-lines: 500` — The God Component Killer

max-lines:
  - error
  - max: 500

500 lines is generous enough for complex forms but strict enough to prevent the 800-line monsters that nobody wants to review and everybody pretends they'll "refactor someday." If your component hits 500 lines, it's doing too much. Split it. Your future self (and your reviewers) will thank you.

`complexity: 10` — Keep Functions Readable

complexity:
  - error
  - max: 10

Cyclomatic complexity of 10 means a function can have at most 10 independent paths. This catches those deeply nested if/else/switch pyramids that look like they were written during a fever dream. If your function has complexity 15, it needs decomposing.

`react/prop-types: error` — Component Contracts

react/prop-types: error
react/require-default-props: error

Yes, we know TypeScript exists. We're not using it (yet). PropTypes are the closest thing to a component contract in JS-land. When a new dev opens a component, propTypes tells them exactly what it expects — no reading the entire render method to figure out what props exist.

`camelcase: error` — One Convention to Rule Them All

camelcase:
  - error
  - properties: always

Try reading a codebase where half the variables are user_name and the other half are userName. It's like reading a book where the author randomly switches between British and American spelling. Technically functional, spiritually painful.

`prettier/prettier: error` — Formatting Is Not a Discussion

prettier/prettier:
  - error
  - { singleQuote: true, printWidth: 100, endOfLine: 'lf' }

Prettier as an ESLint error means formatting violations block the merge. Not warnings. Not suggestions. The specific settings (single quotes, 100-char lines) matter less than the fact that they're enforced uniformly. Tabs vs spaces debates belong in 2015 where we left them.

The Smart Part: Overrides

Not every file should follow the same rules. This is where the config stops being dogmatic and starts being practical:

overrides:
  - files: '**/reducer.js'
    rules:
      complexity: off

  - files: '**/saga.js'
    rules:
      complexity: off
      camelcase: off

  - files: '**/*.test.js'
    rules:
      react/prop-types: off

  - files: '**/tests/**/*.test.js'
    rules:
      complexity: off
      camelcase: off
      max-lines: off

Reducers get unlimited complexity because Redux reducers are fundamentally big switch statements. A reducer handling 15 actions has complexity 15 — that's not bad code, that's just how reducers work. Forcing artificial splits would make the code worse.

Sagas get complexity + camelcase exemptions because sagas are the boundary layer where external API naming (user_name, created_at) meets internal conventions. Forcing camelcase there means either renaming every API field or suppressing the rule on every line. Both are worse than the override.

Tests get relaxed rules because we want developers to write more tests, not fewer. If prop-types or max-lines are blocking test coverage, the rules are hurting more than helping.

What We'd Do Differently

Honesty hour.

Outdated Node in CI. Our linter workflow was pinned to an older Node version for a while — the kind of tech debt that works fine until it doesn't, like driving with an expired inspection sticker. Upgrading means verifying 30+ Babel and ESLint packages resolve correctly on the newer runtime. We got there eventually, but it sat on the "we'll get to it" list longer than we'd like to admit.

The clean-slate install is slow. Nuking node_modules and reinstalling from scratch on every PR isn't fast. Dependency caching (actions/cache) would fix this. We traded speed for reproducibility, but you can have both.

The Takeaway

If you're setting up quality gates for a multi-developer codebase, here's the framework:

Start with the rules. Define what "good code" means in your linter config. Be opinionated — it's easier to relax rules than to introduce them into a codebase that's already feral.
Enforce locally. lint-staged + pre-commit hooks fix the easy stuff automatically. Zero friction.
Enforce in CI. GitHub Actions catch what local hooks miss — and unlike pre-commit hooks, they can't be skipped with --no-verify.
Write overrides, not exceptions. Instead of // eslint-disable-next-line scattered across hundreds of files, configure overrides by file pattern. Encode your team's decisions in the config, not in comments.
Build custom checks for your pain. The duplicate i18n check isn't in any plugin — we wrote it because it was our problem. Every codebase has unique failure modes. Write scripts to catch yours.

The goal isn't zero lint warnings. The goal is that a new developer can join the team, open a PR, and the pipeline tells them exactly how the team writes code — without anyone writing a Confluence doc that nobody reads.

Running custom quality checks in your CI that go beyond standard linting? I'd love to hear what problems they solve. Drop them in the comments.

How We Managed State Across 900+ React Components Without Losing Our Minds

Keshav Agarwal — Sat, 07 Mar 2026 16:11:24 +0000

The Bug That Changed Everything

A few months into building our enterprise SaaS platform, a customer reported a bizarre issue: saving a reward configuration would silently overwrite pricing data that another team member had edited seconds earlier.

The root cause? Two components — three levels apart in the tree — were each managing their own copy of the same entity. One saved stale data over fresh data. No error. No warning. Just silent data loss.

That incident killed any remaining appetite for scattered local state. This happened in a codebase with 900+ components across 18+ pages, multiple devs contributing simultaneously, multi-step creation flows with cross-step validation, and millions of end users.

We went all-in on centralized state management with Redux — and it became the single best architectural decision we made. (Also the most verbose one, but we'll get to that.)

Redux wasn't just our data store. It was the coordination layer — the air traffic control for components that otherwise had no business knowing about each other. A setting change in Component A causing Component B to refresh, a sidebar selection updating a detail panel three levels away — all orchestrated through Redux actions and sagas instead of prop callbacks or tangled useEffect chains.

The Architecture: Feature-Based Redux Modules

Every feature owns a self-contained Redux module with five files:

src/features/CreateEditEntity/
  constants.js    # Namespaced action types
  actions.js      # Action creator functions
  reducer.js      # State transitions (Immutable.js)
  saga.js         # Async side effects (Redux-Saga)
  selector.js     # Memoized state selectors (Reselect)

Yes, five files per feature. I know, I know — I can hear you groaning. I'll address the boilerplate elephant later.

But this structure meant any developer could find the business logic for any feature in seconds. No "where does this state live?" Slack messages at 3 PM. Each slice owned a single concern: createEditEntity handled only the reward creation flow, configSettings handled only category config. No god-reducers trying to manage the entire known universe.

The Stack

Library	Role
react ^18.2.0	UI library
redux 4.0.1	Core state container
react-redux 5.1.0	React bindings (`connect`, `Provider`)
redux-saga 0.16.2	Generator-based side effects
immutable 4.3.7	Persistent immutable data structures
reselect 4.0.0	Memoized selectors
webpack ^5.91.0	Bundler with Module Federation

Not the latest versions — and that's part of the story. This architecture was established years ago and has stayed stable through multiple product evolutions. If it ain't broke, don't npm install.

Dynamic Injection: Load Only What You Need

Not every feature loads on the first page. Reducers and sagas are injected into the store only when their component mounts:

const withReducer = injectReducer({ key: 'createEditEntity', reducer });
const withSaga = injectSaga({ key: 'createEditEntity', saga });

export default compose(withReducer, withSaga, withConnect)(CreateEditEntity);

A user who only visits a listing page never downloads the reducer logic for the creation flow. Webpack decides when code loads - Redux decides how it integrates into the store.

The Three Patterns That Actually Mattered

Out of everything we built, three patterns delivered outsized value. If you take nothing else from this post, take these. (And maybe a coffee. This is the meaty part.)

1. Sagas as the Business Logic Layer (The Biggest Win)

This is the hill I'll die on. Sagas absorbed the business logic that would otherwise pollute components. Components became pure render functions — they dispatch intents and display state. Everything messy? That's the saga's problem now.

Navigation — after a successful save, the saga dispatches a route change - the component never calls history.push
Notifications — success/error toasts are triggered by sagas, not component-level useEffect chains
Cross-feature coordination — when a reward is saved, a saga dispatches an action that marks the rewards list cache as stale, so the next visit triggers a refresh
Dependent actions — after saving entity A, dispatch actions to refresh entity B's list, invalidate a cache slice, and update a sidebar count — without the originating component knowing about these dependencies

To make this concrete, here's our actual reward creation flow — a 5-step wizard where the saga orchestrates everything end-to-end. No code wall this time, just the flow:

┌─────────────────────────────────────────────────────────────┐
│                    EDIT / DUPLICATE FLOW                    │
│                  (initializeGetByIDSaga)                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  User navigates to /edit/:entityId                          │
│         │                                                   │
│         v                                                   │
│  1. FETCH ─── call(Api.getEntityById, entityId)             │
│         │                                                   │
│         v                                                   │
│  2. EXTRACT PRICING MODE from nested configs                │
│    (buried 3 levels deep in the API response, obviously)    │
│         │                                                   │
│         v                                                   │
│  3. PARALLEL FETCH T&C ─── filter languages with T&C URLs   │
│    │         │         │    then fetch ALL in parallel      │
│    v         v         v    (no waterfall nonsense)         │
│   [en]     [fr]      [de]  ─── convert to text              │
│    │         │         │                                    │
│    └────┬────┘─────────┘                                    │
│         v                                                   │
│  4. DISPATCH per-language T&C updates to Redux              │
│         │                                                   │
│         v                                                   │
│  5. DISPATCH GET_ENTITY_BY_ID_SUCCESS                       │
│    └─> reducer calls hydrateFormState() which transforms    │
│        the flat API blob into our 5-step form state:        │
│        name, description, audience, payment, inventory,     │
│        languages, categories, restrictions...               │
│                                                             │
│  ✓ Form is now pre-filled. User edits away.                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

That handles loading and populating the form. Now here's what happens when the user clicks Save — and this is where it gets interesting, because the saga has to gather state from 6 different Redux slices and assemble a single API payload:

┌─────────────────────────────────────────────────────────────┐
│                       SAVE FLOW                             │
│                    (saveEntitySaga)                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  User clicks "Save" ─── dispatches SAVE_ENTITY_REQUEST      │
│         │                                                   │
│         v                                                   │
│  1. GATHER STATE from 6 Redux slices:                       │
│    ┌────────────────────────────────────────────┐           │
│    │  orgData ─── tenantData ─── configData.    │           │
│    │  formState ─── pricingMode ─── customFields│           │ 
│    └────────────────────────────────────────────┘           │
│         │                                                   │
│         v                                                   │
│  2. TRANSFORM via generateSavePayload()                     │
│    UI state ──────────────────────────> API payload         │
│    ┌──────────────────────────────────────────┐             │
│    │  Step 0: Basic meta (dates → UTC)        │             │
│    │  Step 1: Targeting (segments, tiers)     │             │
│    │  Step 2: Pricing & billing configs       │             │
│    │  Step 3: Limits (per-user, global)       │             │
│    │  Step 4: Localization (multi-lang)       │             │
│    │  Step 5: Additional (tags, groups, cats) │             │
│    └──────────────────────────────────────────┘             │
│         │                                                   │
│         v                                                   │
│  3. DETECT MODE ─── CREATE or EDIT?                         │
│         │                                                   │
│         v                                                   │
│  4. API CALL ─── Api.createEntity or Api.editEntity         │
│         │                                                   │
│         ├──── success ──> dispatch SUCCESS                  │
│         │                 push analytics event              │
│         │                 navigate to /listing              │
│         │                 show toast ("Go grab a coffee")   │
│         │                                                   │
│         └──── failure ──> dispatch FAILURE                  │
│                           show error toast                  │
│                           (we blame the API, naturally)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

The beauty of this? The component does almost nothing interesting.

It renders form fields across 5 steps, dispatches SET_* actions on keystrokes (SET_NAME, SET_DESCRIPTION, SET_TARGET_SEGMENT, SET_LIMITS...), and dispatches SAVE_ENTITY_REQUEST when the user clicks Save. That's it.

The component doesn't know how to transform data, doesn't know which API to call, doesn't know about T&C URL fetching, doesn't care about analytics. All that orchestration — loading, transforming, assembling across 6 reducers, saving, tracking, navigating — lives in the sagas. The component just renders and dispatches. No useEffect chains. No "which lifecycle method does this run in?" existential crises.

Any time you find yourself writing useEffect(() => { if (saveSuccess) { navigate(...); showToast(...); trackEvent(...); } }), that logic belongs in a saga. The saga owns the entire chain of consequences from a single user intent.

2. Concurrent Uploads with eventChannel + fork

This pattern handled hundreds of concurrent media uploads in production. We needed bulk uploads of images, videos, and rich content to S3 — each tracked independently with progress, error state, and retry capability.

function createUploadChannel(file) {
  return eventChannel((emitter) => {
    const xhr = new XMLHttpRequest();
    xhr.upload.onprogress = (e) =>
      emitter({ progress: Math.round((e.loaded / e.total) * 100) });
    xhr.onload = () => { emitter({ success: true }); emitter(END); };
    xhr.onerror = () => { emitter({ error: true }); emitter(END); };
    xhr.open('POST', '/api/upload');
    xhr.send(file);
    return () => xhr.abort(); // cleanup = cancellation
  });
}

function* uploadSingleFile(file, index) {
  const channel = yield call(createUploadChannel, file);
  try {
    while (true) {
      const event = yield take(channel);
      if (event.progress)
        yield put({ type: 'UPDATE_PROGRESS', index, progress: event.progress });
      if (event.success)
        yield put({ type: 'FILE_UPLOAD_SUCCESS', index });
    }
  } finally {
    channel.close();
  }
}

function* uploadAllFiles({ payload: files }) {
  const tasks = yield all(
    files.map((file, i) => fork(uploadSingleFile, file, i))
  );
  // Wait for all uploads OR a cancel action — whichever comes first
  yield race({
    done: all(tasks.map((t) => t.toPromise())),
    cancel: take('CANCEL_ALL_UPLOADS'),
  });
}

eventChannel bridges callback-based APIs into the saga world. fork spawns concurrent tasks. race lets the user cancel everything mid-flight. Try building this with useState and useEffect — I'll wait. (Actually, don't. You'll end up with a ref-heavy, leak-prone mess and a therapy bill.)

3. No Prop Drilling — Components Connect Directly

This is what makes Redux scale in component-heavy apps. In our codebase, components at every level connect directly to the store:

Parent page connects to 4 selectors
Child form independently connects to 9
Sibling accordion connects to 13
Deeply nested molecule (3 levels deep) connects to 5 selectors spanning multiple reducer domains

None of these pass data to each other through props. Each component declares exactly which state slices it needs. Adding a new data dependency to the nested molecule requires zero changes to any parent component.

We used createStructuredSelector + factory selectors (makeSelect*) to ensure each connected component gets its own memoization cache:

const mapStateToProps = createStructuredSelector({
  entityDetails: makeSelectEntityDetails(),
  isLoading: makeSelectIsLoading(),
});

const withConnect = connect(mapStateToProps, mapDispatchToProps);
export default compose(withReducer, withSaga, withConnect)(EntityComponent);

What Bit Us (And What We'd Do Differently)

Look, no architecture survives contact with reality unscathed. Here's where ours drew blood — and how we'd fix each one.

Immutable.js Was a Mistake → Use Immer

I'll say it plainly. Every boundary in our code has a tax:

Reading a value? state.get('name') instead of state.name — because apparently dot notation was too easy
Passing to a child component? .toJS() — which creates a new object reference every render, defeating the very memoization you set up five minutes ago
Receiving from an API? fromJS(response) — easy to forget, leading to subtle bugs where a component gets an Immutable Map instead of a plain object and React just... renders [object Object] with a straight face

New developers would spend their first week debugging issues that boiled down to "you forgot .toJS()" or "you called .get() on a plain object." The cognitive overhead never went away. It's like a toll booth on every data highway in the app.

The fix: RTK uses Immer under the hood. Write state.name = 'foo' and get immutable updates for free. No more .get() / .set() / .toJS() gymnastics. This is the change we want most.

Five Files Per Feature Is a Lot → RTK createSlice

Every new feature: constants, actions, reducer, saga, selector. For a simple "show advanced options" toggle, a junior developer has to touch all five files plus wire up injectReducer. That's the kind of ceremony that makes people question their career choices.

The fix: createSlice collapses constants + actions + reducer into one file. One file per feature instead of five — that alone would cut our boilerplate by 60%.

And here's the twist: AI-driven development has largely neutralized this pain in the meantime. Tools like Cursor and Claude can generate a complete feature module from a single prompt. The repetitive, predictable patterns that make Redux verbose are precisely what make AI assistance highly effective. What used to be 30 minutes of boilerplate is now 2 minutes of AI-generated code plus a quick review.

Sagas Are Hard to Debug → Keep for Complex Flows, RTK Query for the Rest

Stack traces through generator functions are opaque. The declarative effect model (call, put, select) means you can't just set a breakpoint and step through — you have to understand the saga middleware's execution model. We had a saga that silently swallowed errors for weeks because a try/catch was in the wrong place. Finding it required manually stepping through the generator yields like an archaeologist brushing dirt off pottery.

The fix: RTK Query for straightforward data fetching — it handles loading states, caching, and cache invalidation out of the box. Keep sagas only for complex orchestration flows where they genuinely shine (like the reward creation wizard above).

connect() HOCs Feel Dated → Hooks

Our codebase uses connect() rather than useSelector/useDispatch hooks. This leads to deeply nested component trees in React DevTools — it's HOCs all the way down. Functional, battle-tested — but it has that "we built this before hooks existed" energy.

The fix: useSelector and useDispatch are simpler, more composable, and produce cleaner component code. No more HOC wrapper hell in React DevTools.

The silver lining: AI-assisted migration

We're not stuck with these pain points forever. With tools like Claude and Cursor, migrating away from Immutable.js, converting HOCs to hooks, and collapsing five-file modules into RTK slices isn't a quarter-long rewrite — it's a series of well-prompted afternoons. The same repetitive patterns that make Redux verbose make it a perfect target for AI-assisted refactoring. We're chipping away at the tech debt one feature at a time, and it's going faster than anyone expected.

The core architecture stays. Feature-based modules with a centralized store remain the right choice at this scale. The organizational pattern scales - only the implementation details change.

The Takeaway

Redux gets a bad reputation for boilerplate, and honestly? Some of that is deserved. Writing five files to add a boolean toggle does feel like filling out government paperwork.

But for a complex, multi-team enterprise application where state consistency and debuggability matter more than velocity on small features, centralized Redux gave us something invaluable: predictability at scale.

900+ components. 18+ pages. Millions of users. Multiple devs. Quarters of active development. Zero "where does this state live?" mysteries. That's a trade-off we'd make again.

Pick your tools based on your complexity:

For local UI state, useState is perfect — don't let anyone shame you into Redux for a modal toggle.
For server state caching, RTK Query or TanStack Query are excellent.
But when your app becomes a coordination problem — when components across different routes need to react to each other's changes — a centralized store with a proper orchestration layer is hard to beat.

Have you migrated a large Redux codebase to RTK, swapped Immutable.js for Immer, or converted connect() HOCs to hooks? What broke first? Drop your war stories below.

Shoutout to Anurag Volety for the early guidance and mentorship that shaped how I think about building UI at scale.

Forem: Keshav Agarwal

How We Built a Code Quality Pipeline That Roasts Bad PRs Before Humans Have To

The Slow Descent Into "It's Fine, Ship It"

"But What About CodeRabbit / AI Review Tools?"

"Why Not Biome / oxlint / Modern Linters?"

The Architecture: The Quality Gauntlet

Layer 1: Pre-Commit Hooks (lint-staged)

Layer 2: GitHub Actions — The PR Gatekeepers

The Linter Workflow

The Duplicate i18n Check (Our Favorite)

Gitleaks Secret Scan

The Rulebook: ESLint Rules That Actually Matter

max-lines: 500 — The God Component Killer

complexity: 10 — Keep Functions Readable

react/prop-types: error — Component Contracts

camelcase: error — One Convention to Rule Them All

prettier/prettier: error — Formatting Is Not a Discussion

The Smart Part: Overrides

What We'd Do Differently

The Takeaway

How We Managed State Across 900+ React Components Without Losing Our Minds

The Bug That Changed Everything

The Architecture: Feature-Based Redux Modules

The Stack

Dynamic Injection: Load Only What You Need

The Three Patterns That Actually Mattered

1. Sagas as the Business Logic Layer (The Biggest Win)

2. Concurrent Uploads with eventChannel + fork

3. No Prop Drilling — Components Connect Directly

What Bit Us (And What We'd Do Differently)

Immutable.js Was a Mistake → Use Immer

Five Files Per Feature Is a Lot → RTK createSlice

Sagas Are Hard to Debug → Keep for Complex Flows, RTK Query for the Rest

connect() HOCs Feel Dated → Hooks

The silver lining: AI-assisted migration

The Takeaway

`max-lines: 500` — The God Component Killer

`complexity: 10` — Keep Functions Readable

`react/prop-types: error` — Component Contracts

`camelcase: error` — One Convention to Rule Them All

`prettier/prettier: error` — Formatting Is Not a Discussion