DEV Community: ICraftCode

System Design - Building an Experiment Service

ICraftCode — Sun, 19 Jul 2026 10:05:45 +0000

Vocabulary

Experiment: is the thing under test — "does the new signup page convert better than the old one."

Variant: Each version shown to visitor.

Control: The version you'd show if there were no experiment running.

Weight: Traffic doesn't have to split evenly across variants — each variant carries a weight, its configured share of traffic.

Exposure: When a visitor sees a variant.

Conversion: When they complete the goal action — signing up, buying something.

Conversion rate: Conversions divided by exposures, per variant — is the number that eventually tells you which variant won.

Requirements

Functional requirements

A client (a business — this is a multi-tenant service) can sign up and get credentials.
A client can define an experiment: its variants and their weights.
Given a visitor and an experiment, the system returns which variant they should see.
Exposures and conversions are recorded as they happen.
A client can view exposures, conversions, and conversion rate per variant.

Non-functional requirements

Low latency on the read path. The variant-assignment call sits directly between a visitor and their page rendering. It has to respond in single-digit-to-low-double-digit milliseconds — a real browser is blocked on it.
Consistency. The same visitor, on the same experiment, must always get the same variant, for as long as the experiment runs.
Data integrity. Every exposure and conversion must be counted exactly once, even under retries and duplicate requests.
Multi-tenancy. One client's experiments must never be visible to, or affected by, another client's.
Scalability. Traffic should be able to grow by orders of magnitude without a redesign — by adding capacity, not by rewriting.
Graceful degradation. If any dependency misbehaves, the system degrades to a safe default rather than failing visibly for a real visitor.

Every design decision below traces back to one of these — mostly the first three.

API design

`POST /clients` — sign up

No auth here — you can't require a key to get your first key!.

curl -X POST https://api.yourexperimentservice.com/clients \
  -H "Content-Type: application/json" \
  -d '{"name": "Acme Labs"}'

Response:

{ "id": "cl_9f2a", "name": "Acme Labs", "api_key": "sk_live_..." }

`POST /experiments` — configure an experiment

Requires the API key from signup.

curl -X POST https://api.yourexperimentservice.com/experiments \
  -H "Content-Type: application/json" \
  -H "X-API-Key: sk_live_..." \
  -d '{
    "key": "signup_test",
    "status": "live",
    "variants": [
      { "key": "control", "weight": 70 },
      { "key": "variant_b", "weight": 30 }
    ]
  }'

Response: the persisted experiment

`GET /assignment` — the hot path

curl "https://api.yourexperimentservice.com/assignment?user_id=visitor_123&experiment_key=signup_test" \
  -H "X-API-Key: sk_live_..."

Response:

{ "experiment_key": "signup_test", "assigned_variant": "control" }

Same user_id + experiment_key always returns the identical result, indefinitely.

`POST /events` — record an exposure or conversion

curl -X POST https://api.yourexperimentservice.com/events \
  -H "Content-Type: application/json" \
  -H "X-API-Key: sk_live_..." \
  -d '{
    "visitor_id": "visitor_123",
    "experiment_key": "signup_test",
    "variant_key": "control",
    "event_type": "exposure"
  }'

Response:

{ "status": "success", "event_id": "ev_88b1" }

A repeated identical exposure returns this same shape with the same event_id — not an error.

`GET /results` — reporting

curl "https://api.yourexperimentservice.com/results?experiment_key=signup_test" \
  -H "X-API-Key: sk_live_..."

Response:

{
  "experiment_key": "signup_test",
  "results": [
    { "variant_key": "control", "exposures": 812, "conversions": 94, "conversion_rate": 0.116 }
  ]
}

The same data also powers a tenant-scoped dashboard view, so a client can check results without writing a script.

High-level design

Four independent write paths — signup, configuration, assignment, and events — all persist to one database. Reads for reporting go through the same store, for now. Of these four, only the assignment path carries a strict latency budget: it's invoked once per page view, synchronously, with a real visitor's browser waiting on the response. That single asymmetry — one latency-critical path, three that can afford to be slower — drives most of the design decisions below.

Design deep dive: the assignment API — sticky and deterministic

This is the most interesting endpoint in the system, and it's worth separating the requirement from the mechanism, because the two get conflated easily.

The requirement is stickiness. A visitor must see the same variant on every visit, for the life of the experiment. If you've worked with load balancers, this should sound familiar — it's the same property that session affinity ("sticky sessions") provides: routing a client's subsequent requests to the same backend server it hit the first time.

The traditional way to get stickiness is stateful: the first time you see a visitor, make a decision and remember it — in a session store, a cookie plus a server-side lookup, or a load balancer's affinity table. Every later request has to consult that stored state.

The mechanism is determinism instead of memory. There's a cheaper way to get the same property, if one condition holds: if the decision is a pure function of information already available on every request, nothing needs to be stored — the identical answer can be recomputed every time. That's the route taken here.

Concretely hash the visitor ID and the experiment key together, producing a number. Reduce it to a fixed range — say 0 to 99 — and partition that range according to the configured weights: the first 70 numbers to variant A on a 70/30 split, the rest to variant B. The same two inputs always hash to the same number, so the same visitor lands in the same partition, for the same experiment, forever — nothing written to disk, no state anywhere.

Two properties of the hash function are doing the actual work:

Determinism — the same input always produces the same output. This is what gives stickiness without storage. Most hash functions are deterministic by construction; this isn't something you engineer, but it is the property being relied on here.
Uniform distribution — across many different inputs, outputs spread evenly across the output range, without clustering. This is what makes a configured 70/30 split actually land close to 70/30 in practice, instead of skewing toward one variant because of some quirk in how visitor IDs happen to be generated.

Why hash the visitor ID and the experiment key together, rather than the visitor ID alone. This detail matters more than it looks. Hash the visitor ID alone, and a given visitor lands in the same percentile bucket for every experiment ever run — someone in the "top 30%" bucket for one experiment is in the top 30% for all of them. That's an unwanted correlation: it means experiments aren't actually independent of each other, and a visitor who happens to convert unusually well (or badly) skews every test in the same direction. Hashing the experiment key in as well gives each experiment its own, effectively independent bucketing for the same visitor — which experiment and which visitor stop leaking into each other.

A clarifying note, since the terminology overlaps. This is not the same thing as consistent hashing, a related but distinct technique for distributing data across a changing set of nodes — think shards in a distributed cache or database — while minimizing how much gets remapped when a node is added or removed. What's happening here is simpler: one hash function mapping (visitor, experiment) to a fixed bucket range that never changes shape. Worth knowing the distinction, since "hashing for consistent assignment" and "consistent hashing" sound alike but solve different problems.

One more subtlety worth internalizing. This design produces two different guarantees, and verifying one doesn't verify the other. For any single visitor, the assignment is completely deterministic — no randomness in an individual decision at all. Across a population of visitors, the outputs merely look randomly distributed, and it's that population-level randomness that makes a configured split hold up in aggregate. That second property is statistical, not deterministic, and it has to be checked empirically, with a genuinely large sample — a handful of test visitors can look meaningfully skewed purely by chance in a perfectly correct system, and can just as easily look fine when something's actually broken.

Design deep dive: idempotency and duplicate prevention

Recording an exposure or conversion looks trivial: a visitor saw a variant, write a row. It stops being trivial the moment real traffic replaces clean test data — double-clicks, retried page loads, back-and-forward navigation all produce the same logical event more than once. If every one of those writes a row, every conversion-rate number downstream is silently inflated.

The naive fix, and why it isn't enough. Check whether this exact event has already been recorded before writing a new one. The problem: "check" and "then write" are two separate operations with a gap between them. Under concurrent requests, two duplicate calls can both pass the check before either has written anything. This is a classic check-then-act race condition — sometimes called TOCTOU, time-of-check to time-of-use — and it shows up anywhere a read-then-write isn't atomic.

The actual fix: idempotency, enforced structurally. An operation is idempotent if performing it once and performing it five times leave the system in the same state. The reliable way to get there isn't detecting duplicates in application code — it's making a duplicate physically impossible to write, by pushing a uniqueness constraint down to the storage layer itself: here, a unique constraint on (visitor, experiment, variant, event type). A duplicate write is no longer something application code has to notice — the write itself is rejected by the database, no matter how many concurrent requests arrive. The calling code treats "rejected as duplicate" as a success, not an error, since the thing it wanted recorded already exists.

This generalizes well beyond one system — it's the same principle behind idempotency keys in payment APIs, exactly-once processing in message queues, and safe retries in any at-least-once delivery system. Wherever possible, move "detect and reject a duplicate" down into "make the duplicate structurally impossible," as close to the data as the storage layer allows.

Data model (low-level design)

Four entities, and the relationships between them are doing real work, not just organizing storage:

Client: the tenant. Everything else exists only in the context of one of these.
Experiment: belongs to exactly one client. Its name only has to be unique within that client, not globally — which is exactly what makes "scope every lookup to the tenant" a hard requirement rather than a nice-to-have. Two clients can legitimately name an experiment the same thing; any lookup that isn't scoped by client risks serving one tenant's config to another tenant's request.
Variant: belongs to an experiment, carries a weight
TrackingEvent: one row per exposure or conversion, referencing both the experiment and the specific variant it happened under, carrying the idempotency-enforcing uniqueness constraint from the section above.

Worth naming explicitly: this ledger is append-only, not a set of counters incremented in place. Exposures could be tracked as a single mutable number per variant, but in-place counters have their own race conditions under concurrent writes, and they throw away the ability to answer questions nobody thought to ask up front — when exactly did this happen, in what order did events actually arrive. A new row per event, nothing ever mutated, trades some storage growth for meaningfully better correctness and flexibility.

Scaling: where the real system design happens

Everything above works comfortably at low-to-moderate traffic. The interesting engineering is in what breaks first as volume grows, and matching each failure to the specific technique that fixes it — not reaching for every scaling tool that exists because it sounds thorough. Correctness and clean API design get you a working system; how it behaves at 100x the traffic is what makes it a system.

Caching

The first thing to strain is reads on the assignment path. The query itself stays fast and indexed, but at high enough concurrency, requests start queuing for a free database connection, because configuration data is read constantly and almost never changes. Read far more than written is exactly the case a cache is built for. A cache-aside layer in front of the database, invalidated whenever the underlying configuration actually changes, takes the database out of the hot path almost entirely except on a miss.

Message queues, for the write path

Further out, the write side starts to strain: every exposure and conversion is a synchronous insert, and the uniqueness constraint that provides idempotency becomes, at high enough volume, itself a point of contention among many concurrent writers. The fix is a queue in front of the write — accept the event, acknowledge immediately, let a pool of workers drain the queue and perform the actual writes, often batched together, which is far cheaper per row at real volume than one insert at a time.

Read replicas

This is also the point where reporting queries start meaningfully competing with write traffic on the same database — the natural moment to introduce a read replica dedicated to reporting and dashboard queries, leaving the primary free to focus on writes.

Partitioning

Further still, the event ledger itself becomes the bottleneck — large enough that its indexes stop comfortably fitting in memory, and even indexed queries degrade. The fix here is partitioning, most naturally by time, since "how long do raw events actually need to be kept" is a real, answerable retention question in a way that visitor or experiment distribution isn't. At true extremes, raw events stop being the right thing to query for reporting at all, and a separate streaming layer maintaining pre-aggregated counts becomes the actual read path instead.

Load balancing

The app tier scales horizontally with essentially no extra design work, provided it stays stateless — no server-side session storage anywhere, so any instance can serve any request and a load balancer can distribute purely by load, with no session-affinity rules to get wrong (a nice callback: the assignment API achieved that same statelessness one layer up, via hashing, for exactly this reason). The one thing that genuinely has to be right: the load balancer's health check needs to hit a dedicated, request-independent liveness endpoint, never a page whose response can legitimately vary by who's asking — otherwise the load balancer can misread normal behavior as an unhealthy instance and start cycling servers that are actually fine.

Rate limiting, for multi-tenant fairness

Nothing so far stops one tenant's traffic spike from degrading latency for every other tenant sharing the same infrastructure. Per-tenant rate limiting, applied before it's ever actually needed, is far cheaper than retrofitting it after a real incident where one customer's bad day became everyone's bad day.

Observability

None of the fixes above should be applied before the specific metric that motivates it is actually visible — cache hit rate, queue depth, replica lag, per-tenant volume. Introducing infrastructure speculatively, because it sounds like the mature thing to do, is its own kind of mistake — solving a problem that hasn't been confirmed to exist yet.

Closing thought

The organizing principle underneath almost everything above is worth stating plainly: on a system that sits directly on a page's critical path, the safe default when anything goes wrong — an experiment nobody's heard of, a failed external call, an unreachable cache — is to fail toward the plainest, safest experience, never to error, hang, or block. A real visitor should never be able to tell that an experimentation system is having a bad day. Getting the happy path fast is the easy half of this problem. Making every unhappy path invisible is the harder, more important half.

Coffee?

If this article saved you a few hours of architectural overthinking (or inspired a personal project of your own), consider buying me a coffee ☕
https://superprofile.bio/vp/buy-me-a-coffee-263

It helps me continue writing about software architecture, system design and, every now and then, the occasional poem.

Architecture Decisions Behind Building a Simple Personal Software Tool

ICraftCode — Thu, 09 Jul 2026 15:56:01 +0000

The Idea

This article documents my thought process while system-designing a simple personal software tool — from the first idea to the final architecture.

Amidst all the Web 2.0, AI-powered, blockchain-enabled and quantum-ready buzzwords, I wanted to build something embarrassingly simple: a humble desktop application for my own personal use. Think along the lines of a budgeting tool, an expense tracker, a personal journal and the like.

Tech Stack

As the ideator, architect and developer of this idea, my first question was obvious: what stack?

As a backend engineer, my muscle memory immediately said Ruby on Rails. But Rails nudges you toward a web app — did I actually want one? No. I wasn't building the next social media platform; some things don't need to be shared, gamified, liked or commented on. I wanted a personal tool people could download and use, which ruled out SaaS entirely: no multi-tenancy, no authentication, no login page, no backend at all. Just a native app from an app store, paid for once, used for as long as they liked. Rails wasn't the problem — I was solving the wrong problem.

So I decided to build a macOS application using Flutter (never touched it before). Every user gets their own local SQLite database. No servers, no infrastructure, no internet dependency.

Of course, local databases don't grow on trees... they grow on disks, and mine couldn't keep growing forever. Thankfully, the app didn't need soft deletes — I wanted cold-blooded hard deletes without a care in the world for the destroyed. I also wasn't expecting years of active records, so capping it around a hundred active entries felt reasonable.

My first thought was to hand users a script that periodically purges old records. Then I realised — why should they? Nobody installs a finance app hoping to do database maintenance on weekends. The app can expose a simple clean-up option instead, and a future version can quietly prune old archived entries on its own, based on a retention policy. People shouldn't have to care about vacuuming SQLite any more than they care about defragmenting a hard disk.

Easy. Build the application, publish it, charge once, users own their data. I proudly declare I'm not responsible if their laptop decides to retire unexpectedly.

Life was good. Until...

Mobile Versions

Who isn't greedy? Certainly not me — I was already thinking about Android and iOS. Copy-paste the business logic into three different applications? My toddler would cancel me for repeating myself. Clearly, we needed code sharing.

The obvious question was whether that meant an API server, turning the desktop and mobile apps into thin clients. Absolutely not — that quietly brings back everything I'd just eliminated: authentication, multi-tenancy, hosting, cloud bills, and before I know it I've accidentally built a SaaS product.

So without a client-server architecture, how do we reuse business logic across platforms? I realised I was conflating two different things: the application's code and the application's data.

Think of a chocolate cake recipe (yes, still craving one). Three people baking the same cake each buy their own ingredients, use their own kitchen, their own oven. The only thing they share is the recipe — following the same recipe doesn't mean mixing batter in the same bowl. (Wow, I actually like that analogy.)

Software works the same way — business logic is the recipe, user data is the ingredients. Once separated, the solution was simple: we aren't sharing data, we're sharing behaviour. This is where Flutter shines: write the business logic once in Dart, compile it separately for every platform. Compile, not copy. The same Dart code becomes a native macOS, Android and iOS app — different binaries, same source, identical behaviour, each still owning its own local SQLite database.

We aren't sharing data. We're sharing logic. Shared recipe, independent kitchens. (Can't take my mind off that chocolate cake.)

Phew — we eliminated the need for a client-server architecture again. Proud as a peacock.

Synchronization

Just when the headache had disappeared, the wanna-be product manager in me asked: "What about synchronization?" Fair question — if I edit an entry on my MacBook, I'd like to see it on my phone too. I'm only a needy mortal.

My first instinct: "back to needing a server" — every client talks to a central server, which stores the data and serves it to everyone else. Done. Except that brought back everything I'd just eliminated: a central database means authentication, multiple users mean multi-tenancy, private data means authorization. Suddenly I'm hosting databases, taking backups, patching security, paying cloud bills. My tiny personal app had quietly turned into a SaaS product. Nope. Not happening. I backed away slowly.

Next idea, equally tiring: let users export the local database and import it on another device. Technically it works — export, transfer, import, done. Elegant? Absolutely not. I wouldn't use my own app after hearing that. (And the cake analogy has officially stopped helping — we can't sync cakes. Am I the only one imagining it?)

A friend suggested skipping the cloud entirely: devices on the same Wi-Fi discover each other and sync directly — no accounts, no storage providers, no infrastructure. I liked it, but it solved a different problem. My phone isn't always on the same network as my laptop; I travel, devices sleep, and if they all have a bad day together, so does my data. Peer-to-peer is fantastic for apps that live inside a home network. I wanted sync to work wherever I was, and I liked my cloud storage doubling as a backup. So I reluctantly parked the idea.

There had to be a middle ground: sync without owning servers or asking users to juggle database files. Then it hit me — I don't need a backend, I need a courier. The cloud doesn't have to understand, validate or query my data, or even look inside it. It just moves changes from one device to another. Suddenly iCloud and Google Drive looked less like databases and more like delivery services. Every device keeps its own local SQLite database; the cloud just carries transports between them. I don't own it, maintain it, or pay for it — users bring their own storage account. Synchronization stopped being an infrastructure problem and became a file transfer problem. That tiny shift in perspective felt like waving a magic wand. (Waving it to fetch me a cake... still no luck.)

Great, we have our cloud courier. Now: when should synchronization happen?

First thought: sync on every create or edit. Problem solved, self-proclaimed genius. Except imagine typing away — create an entry, typo, edit, another typo, edit, forgot something, edit again. Congratulations, four syncs in under a minute. Not elegant, and users don't expect another device to reflect every keystroke — this isn't a collaborative document editor.

Fine — every five minutes? Reasonable, until I imagined editing something, closing the app two minutes later, and opening it on my phone at home to find nothing synced. Periodic sync didn't feel reliable either.

What about syncing only on close — finish working, close the app, it uploads the latest changes? Except apps don't always get to say goodbye: laptops crash, batteries die, operating systems kill your app without asking. (How are they so cold-blooded?) Waiting for shutdown suddenly seemed risky.

There had to be a middle ground. (Desperately prays so.) Bingo — debounced sync. Instead of syncing after every write, the app just remembers something changed, like a Post-it note saying "don't forget to back me up." Every write marks the database dirty and starts a short timer; another write before it expires just resets the timer. Only when the user pauses for thirty or sixty seconds does the app upload the accumulated changes — notified after the pause, not after every keystroke.

But what if the user closes the app before the debounce timer fires? (It isn't easy being an overthinker. Nor living with one.) Simple — one final sync before the app backgrounds or closes. Now even my perfectionist self couldn't find fault. (Yet.) No constant uploads, no cron jobs, no manual "Sync Now" button — just sync whenever it makes sense.

Next question: how does another device know something new is waiting? I don't want every phone and laptop asking "anything new? anything new?" every few seconds — this is a boring app, not cortisol-inducing social media. The answer: a quick metadata check against the cloud on startup. Nothing changed, nothing happens. Something newer exists, it downloads before the user starts working. No polling, no background jobs — one check at startup.

One final question: what if two devices edit the same record before either syncs? Edit an expense on my MacBook while travelling, then edit the same expense on my phone before the first change reaches the cloud — now both devices think they're right. Who wins? Welcome to distributed systems.

I briefly looked at CRDTs — multiple devices modify data independently and mathematically converge to the same state. Beautiful. Also complete overkill for a personal expense tracker; sometimes the smartest decision is knowing what not to build. A simpler strategy sufficed: every record carries a last_modified_at timestamp, and when two versions meet, the newer one wins — Last-Write-Wins.

Is it perfect? No — simultaneous edits could overwrite each other. But honestly, how often am I editing the same entry on two devices at the same instant? Almost never. The complexity wasn't worth the tiny probability. Engineering isn't about eliminating every edge case — it's choosing which ones deserve your attention.

And with that, my synchronization story finally felt complete.

Backwards Compatibility

By now I finally had an architecture I was genuinely happy with. (Read: "arrogant about.") One codebase, native applications, local storage, automatic synchronization, no backend, no infrastructure. Surely we're done?

Not quite. Software refuses to stay "done." A bug gets reported, fixed. A better idea strikes, gets built. A feature gets requested, added. (Respect the one user who finds your humble app useful.) Version 1 quietly becomes Version 2, then 3, then 17. Applications evolve. (So should we.)

That raises an important question: what happens to users on an older version? Suppose Version 1 stores an entry like this:

Entry
------
id
title
status

A few months later I decide every entry should also remember when it was created. Seems harmless — Version 2 now expects:

Entry
------
id
title
status
created_at

I publish Version 2. The user updates. The new code looks for created_at — except the user's database still belongs to Version 1, and that column doesn't exist. Best case, an error. Worst case, a crash. Nothing's more frustrating than an update that breaks your own data.

One option: ask users to export everything, delete the database, recreate it and import it all again. Remember when I said I wouldn't use my own application if it behaved that way? Exactly.

Updates should feel invisible. Instead, on startup after an update, the app quietly checks the local database's schema version. Matches the latest? Nothing happens. Older? It automatically runs a migration first — a tiny set of instructions teaching yesterday's database to become today's: add a column, create a table, reshape data, whatever's needed. Version 1 becomes 2, 2 becomes 3, 3 becomes 4, one step at a time. The user's data survives every update. (Just like my relentless attempts to avoid building a SaaS app.)

Software shouldn't punish users for staying up to date. A good update feels boring: click update, open the app, carry on where you left off. That's backwards compatibility — not supporting old software forever, but protecting the trust users place in you every time they update.

The architecture finally felt complete: fully offline, synchronized across devices, evolving without breaking anyone. The next question wasn't technical — it was commercial. How should this thing be packaged?

Packaging

One unexpected side-effect of choosing a local-first architecture had nothing to do with engineering — it changed how I could package the product (don't panic, this one's pleasant).

Down the traditional SaaS route, the business model chooses itself: users sign up, I host servers, store their data, pay cloud bills, every single month — which means they pay me every single month. Subscriptions aren't evil, sometimes they're justified. But I wasn't running an always-on service. The app runs on the user's device, the database lives on their machine, sync uses their own cloud storage. Once published, my recurring infrastructure cost is almost zero.

That opens up business models a SaaS architecture can't support. Someone buys once and uses it for as long as they like. Years later, a much-improved Version 2 becomes a product decision, not an infrastructure one — free upgrade, discounted upgrade, new edition, whatever. My architecture doesn't force subscriptions just to keep the lights on. No accounts, no reminders, no "your trial expires in 3 days." Just software.

It got more interesting once I stopped thinking about one app. What if I built a whole collection of personal tools — budgeting, expense tracking, a reading log, a meal planner? Publishing four separate apps means duplicating almost everything: four to install, four to update, four to maintain. Didn't feel right.

Instead, package it all into one application — a toolbox, where every module ships in but users unlock only what they need. Someone wants just budgeting, fine, they buy budgeting. Someone wants budgeting, tracking and meal planning but not the reading log — also fine. As needs evolve they unlock more: no new app to discover, no new interface, no data migration. Want everything? Bundle it cheaper. Everybody wins.

None of this requires the architecture to change. Still local-first, sync works the same, migrations work the same — only the licensing changes.

I wasn't designing a single application anymore — I was quietly building a platform for personal software, letting people decide how much or how little to make it their own. Ironically, the biggest business decision in the project had nothing to do with marketing; it happened the moment I chose local-first over SaaS. (Thanks to my overwhelm.) Sometimes the cleanest business model is just a side-effect of a clean architecture.

Closing Thoughts

Is this architecture perfect? Probably not. If my laptop dies seconds after an edit, before the debounce timer syncs it, I lose those last few changes. I'm okay with that trade-off — I wasn't trying to eliminate every failure, just build something simple, practical and pleasant to maintain.

Sometimes the simplest architecture that satisfies your requirements is the best one. There are probably better approaches than the ones I chose — that's the fun part of system design. Rarely a single "correct" answer, only trade-offs. If you'd have done this differently, I'd love to hear it. This wasn't about proving I built the perfect architecture — just documenting the thought process behind one.

Coffee?

If this article saved you a few hours of architectural overthinking (or inspired a personal project of your own), consider buying me a coffee ☕
https://superprofile.bio/vp/buy-me-a-coffee-263

It helps me continue writing about software architecture, system design and, every now and then, the occasional poem.

Solving the Zombie Row Problem: A Deep Dive into React State Management

ICraftCode — Tue, 27 Jan 2026 16:28:06 +0000

What you'll learn: This comprehensive guide walks through implementing a delete feature in a React + Remix application, battling the infamous "Zombie Row" bug, and discovering fundamental state management patterns. Perfect for developers learning React or deepening their understanding of state ownership, hooks, and component architecture.

⚠️ A Confession Before We Begin

Full transparency: This bug happened because I jumped into React and Remix development with a backend developer mindset, without properly learning the fundamentals first.

I thought: "I know JavaScript, I've built APIs, how hard can frontend be?"

Spoiler alert: Very hard when you skip the learning phase.

This article chronicles my journey from:

❌ Treating React components like API endpoints
❌ Fighting the framework instead of embracing it
❌ Copy-pasting patterns I didn't understand
❌ Debugging by trial and error

To finally:

✅ Understanding React's mental model
✅ Learning proper state management patterns
✅ Writing maintainable, testable code

If you're also transitioning from backend to frontend (or just struggling with React state), this is for you. Every mistake I made, you can avoid. Every lesson I learned the hard way, you can learn the easy way.

Let's dive in. 👇

📖 What We'll Cover

The Problem - Understanding the "Zombie Row" bug
The Infrastructure - GraphQL, Remix, and React architecture
The Toolbox - React Hooks explained from first principles
The Battlefield - Three failed attempts (and why)
The Victory - The Container/Presentational solution
The Lessons - Key takeaways and best practices

🧟 Chapter 1: The Problem (The "Zombie Row")

The Backend Perspective

As a backend engineer, DELETE is straightforward:

Client sends DELETE /api/items/123
Server removes record from database
Server returns 200 OK
Done. The data is gone.

But in modern frontend applications with client-side state management, the story is different. The browser maintains its own copy of the data—a cache—and that cache doesn't automatically know when the server has deleted something.

The Scenario

You're building a data management interface with a table display. The page shows a list of items:

Name	Description	Actions
Item A	Full Access	👁️ Edit Delete
Item B	Limited	👁️ Edit 🗑️
Item C	Read Only	👁️ Edit 🗑️

The user workflow:

User clicks the 🗑️ (delete icon) on "Item B"
Confirmation dialog appears: "Delete Item B?"
User clicks "Delete"
Network request fires: DELETE /api/items/456
Server responds: { "success": true }
Success toast appears: ✅ "Item B has been deleted"

The Bug: The Zombie Row

Expected Behavior:

The "Item B" row immediately disappears from the table
Table now shows only "Item A" and "Item C"

Actual Behavior:

The success toast appears
The "Item B" row is STILL in the table
User confusion: "Wait, did it actually delete?"
User refreshes the page (F5)
NOW the row is gone

This is what we call a Zombie Row—data that is dead in the database but still alive on the screen.

Why Did This Happen?

The bug stemmed from a fundamental architectural problem in how our DataTable component was designed. Let me show you the code:

// ❌ THE PROBLEMATIC ARCHITECTURE

// CHILD COMPONENT: DataTable.tsx
export function DataTable({ connection }) {
  // The Table owns its own internal copy of the data
  const [edges, setEdges] = useState(connection.edges);

  return (
    <table>
      {edges.map(edge => (
        <ItemRow key={edge.node.id} item={edge.node} />
      ))}
    </table>
  );
}

// PARENT COMPONENT: ItemsPage.tsx
export default function ItemsPage() {
  const data = useLoaderData(); // Initial data from server

  const handleDeleteSuccess = () => {
    // ❌ PROBLEM: I know the item was deleted...
    // But how do I tell DataTable to remove it from its internal state?
    // The Table is holding its own private copy of `edges`!
  };

  return <DataTable connection={data.connection} />;
}

The Core Problem:

Child Owns the State: DataTable has its own useState(connection.edges) - it made a private copy of the data when it first rendered
Parent Can't Control Child: Even though the parent knows a item was deleted, it has no way to tell the child's internal state to update
Props Don't Re-trigger State: Passing new props doesn't automatically reset a child's useState value
Stale Cache: The table keeps showing its original cached data until the entire page refreshes

💡 Mental Model: Think of it like this: The parent is a manager who knows an employee left the company, but the reception desk (the child component) is still showing the old employee directory because they printed it out on Day 1 and never check for updates.

The Real-World Impact

This wasn't just a visual glitch. It caused:

❌ User Trust Issues: "Did my action actually work?"
❌ Support Tickets: Users reporting "delete isn't working"
❌ Workaround Behavior: Users developed the habit of refreshing after every delete
❌ Data Confusion: Users would try to edit a "deleted" item thinking it was still active

⚠️ The Bottom Line: We needed to fix this. But first, I needed to understand the infrastructure I was working with.

⚙️ Chapter 2: The Infrastructure (Understanding the Stack)

Before attempting fixes, I needed to understand the tools I was working with. Coming from a backend background, React's ecosystem felt like learning a new language.

🏗️ The Data Flow Architecture

Our application uses a specific tech stack:

Server (GraphQL API)
      ↓
   Remix (Server-Side Framework)
      ↓
   React (UI Library)
      ↓
  Browser (Client Cache)

Let me break down each layer:

1. GraphQL with Relay-Style Connections

GraphQL is our API query language, but we use a specific pattern called Relay Connections for pagination.

What is a Connection?

Instead of returning a simple array of items, our API returns a structured object:

// ❌ Simple Array (Not Scalable)
{
  "items": [
    { "id": "1", "name": "Item A" },
    { "id": "2", "name": "Item B" }
  ]
}

// ✅ Relay Connection (Scalable Pagination)
{
  "connection": {
    "edges": [
      {
        "cursor": "Y3Vyc29yOjE=",  // A bookmark for this position
        "node": { "id": "1", "name": "Item A" }
      },
      {
        "cursor": "Y3Vyc29yOjI=",
        "node": { "id": "2", "name": "Item B" }
      }
    ],
    "pageInfo": {
      "hasNextPage": true,
      "endCursor": "Y3Vyc29yOjI="
    }
  }
}

Understanding the Parts:

Node: The actual data object (the Item itself)
Edge: A wrapper around the Node that includes pagination metadata
Cursor: A unique bookmark (Base64 encoded) that marks this item's position in the full list
PageInfo: Tells us if there are more pages and what cursor to use for "Load More"

Why This Structure?

When the user clicks "Load More," we send:

query GetItems($after: String) {
  items(first: 20, after: "Y3Vyc29yOjI=") {
    edges { cursor node { id name } }
    pageInfo { hasNextPage endCursor }
  }
}

The server says: "Give me 20 items AFTER this bookmark." This is more efficient than offset-based pagination (LIMIT 20 OFFSET 40) because cursors work with sorted, filtered data.

2. Remix: The Server-Client Bridge

Remix is a React framework that handles routing and data fetching. Key concepts:

Loaders (Read Operations)

A loader runs on the server before the page renders. It fetches initial data:

export async function loader({ params }: LoaderFunctionArgs) {
  // This runs on the SERVER before React renders
  const result = await graphqlClient.query(GET_ITEMS_QUERY, {
    variables: {
      id: params.id,
      first: 20  // Initial page size
    }
  });

  return { connection: result.data.items };
  // Remix serializes this and sends it to the browser
}

Actions (Write Operations)

An action runs on the server when a form is submitted (like our delete operation):

export async function action({ params }: ActionFunctionArgs) {
  // This runs on the SERVER when delete is triggered
  const result = await graphqlClient.mutate(DELETE_ITEM_MUTATION, {
    variables: { id: params.itemId }
  });

  if (result.errors) {
    return { success: false, error: "Delete failed" };
  }

  return { success: true };
}

useFetcher (The Communication Robot)

This is a hook that creates a "mini-robot" to talk to actions WITHOUT navigating away from the page:

import { useFetcher } from "@remix-run/react";

function DeleteButton({ itemId }) {
  const fetcher = useFetcher();

  const handleDelete = () => {
    // Sends request to the action at this path
    fetcher.submit(
      { itemId },  // Form data
      { method: "delete", action: `/api/items/${itemId}` }
    );
  };

  // Track the state
  console.log(fetcher.state); // "idle" | "submitting" | "loading"
  console.log(fetcher.data);  // The response from action

  return (
    <button onClick={handleDelete} disabled={fetcher.state !== "idle"}>
      {fetcher.state === "submitting" ? "Deleting..." : "Delete"}
    </button>
  );
}

Fetcher States:

idle: Nothing happening, ready for new request
submitting: Request is being sent to server
loading: Server responded, Remix is processing
idle (again): Done, fetcher.data contains response

This was KEY to understanding why my first attempts failed. The fetcher state is TRANSIENT—it clears after completing!

3. React Component Architecture

Our page uses a component hierarchy:

ItemsPage (Parent/Container)
  ├── DeleteDialog
  │     └── FetcherButton
  └── DataTable (Child/Presentation)
        ├── TableHeader
        └── ItemRow (repeated)
              ├── ViewIcon
              ├── EditIcon
              └── DeleteIcon

The Flow:

User clicks DeleteIcon in an ItemRow
ItemsPage shows DeleteDialog
User confirms → Dialog submits via fetcher
Action runs on server → returns success
PROBLEM: How does DataTable know to remove the row?

This is where understanding state ownership became critical.

🧰 Chapter 3: The Toolbox (React Hooks Explained)

React hooks are functions that let you "hook into" React features. Coming from backend, think of them as lifecycle event handlers.

🪝 1. useState (The State Box)

This creates a piece of state that persists across re-renders:

const [count, setCount] = useState(0);

// Reading state
console.log(count); // 0

// Updating state (triggers re-render)
setCount(1);
console.log(count); // Still 0! (will be 1 on next render)

// Functional update (safe for loops)
setCount(prev => prev + 1); // Uses latest value

⚠️ CRITICAL RULE: Setting state doesn't change it immediately. React schedules a re-render with the new value.

Backend Analogy: Like a database transaction—you queue the change, and it applies after commit (re-render).

🪝 2. useEffect (The Side-Effect Runner)

Runs code AFTER React finishes rendering the UI:

useEffect(() => {
  // This runs AFTER the DOM is updated
  console.log("Component rendered!");

  // Optional cleanup (runs before next effect or unmount)
  return () => {
    console.log("Cleaning up!");
  };
}, [dependency]); // Only re-run if this value changes

The Dependency Array (the second argument) is crucial:

// ❌ No deps array: Runs after EVERY render (usually wrong)
useEffect(() => {
  fetchData();
});

// ✅ Empty array: Runs ONCE on mount
useEffect(() => {
  fetchData();
}, []);

// ✅ With deps: Runs when deps change
useEffect(() => {
  fetchData(userId);
}, [userId]); // Re-run when userId changes

Common Pitfall (This bit me hard):

const [data, setData] = useState([]);

useEffect(() => {
  setData([...data, newItem]); // ❌ Reading `data`
}, [data]); // ❌ `data` is a dependency

// This creates an INFINITE LOOP:
// setData → data changes → useEffect runs → setData → data changes → ...

Backend Analogy: Like a database trigger that fires on UPDATE—if the trigger itself causes an UPDATE, you get infinite recursion.

🪝 3. useRef (The Persistent Box)

A box that holds a value that DOESN'T trigger re-renders when changed:

const countRef = useRef(0);

// Reading
console.log(countRef.current); // 0

// Updating (NO re-render triggered!)
countRef.current = 10;
console.log(countRef.current); // 10 immediately

// Persists across renders
function Component() {
  const renderCount = useRef(0);

  useEffect(() => {
    renderCount.current += 1; // Track renders without causing more renders
  });

  return <div>Rendered {renderCount.current} times</div>;
}

Common Uses:

Timers: const timeoutRef = useRef(null); timeoutRef.current = setTimeout(...)
DOM References: const inputRef = useRef(); <input ref={inputRef} />
Previous Values: const prevPropsRef = useRef(); prevPropsRef.current = props
Flags: const isProcessedRef = useRef(false) (prevent double-processing)

Backend Analogy: Like a static variable in a class—persists across method calls but doesn't trigger events.

🪝 4. useMemo (The Cached Calculation)

Remembers the result of an expensive calculation:

const expensiveValue = useMemo(() => {
  console.log("Calculating...");
  return data.map(item => transform(item));
}, [data]); // Only recalculate if `data` changes

// Without useMemo, this would recalculate on EVERY render
// With useMemo, it only recalculates when `data` actually changes

When to Use:

Expensive transformations (filtering large arrays)
Preventing child re-renders (when passing objects/arrays as props)

When NOT to Use:

Simple calculations (overhead not worth it)
When dependencies change frequently anyway

Backend Analogy: Like Redis caching—calculate once, use many times until invalidation.

🪝 5. useCallback (The Cached Function)

Similar to useMemo, but for functions:

const handleClick = useCallback(() => {
  console.log("Clicked", id);
}, [id]); // Only create new function if `id` changes

// Without useCallback, a new function is created every render
// This matters when passing to child components (causes re-renders)

Why It Matters:

// ❌ Without useCallback
function Parent() {
  const handleClick = () => console.log("Click"); // New function every render
  return <Child onClick={handleClick} />; // Child re-renders every time
}

// ✅ With useCallback
function Parent() {
  const handleClick = useCallback(() => console.log("Click"), []); // Same function
  return <Child onClick={handleClick} />; // Child doesn't re-render unnecessarily
}

🪝 6. useFetcher (Remix-Specific)

Already covered above, but worth emphasizing: This is how we communicate with server actions without page navigation.

⚔️ Chapter 4: The Battlefield (Failed Attempts)

Armed with (minimal) knowledge of these hooks, I started attempting to fix the zombie row bug. Each attempt taught me something valuable about React's state management.

Attempt #1: Optimistic UI with Intents (❌ Failed)

Commit: 3dc0453e - "Removing the deleted item from ui using optimistic ui and intents"
Date: January 21, 2026
Duration: 3 hours of confusion

Understanding "Intent" Pattern

Before diving into what I tried, let me explain what an Intent is in Remix.

What is an Intent?

An intent is a string identifier you pass in formData to tell an action what operation to perform. It's like a command code.

General Usage:

// SCENARIO: One action handles multiple operations
export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const intent = formData.get("intent");

  switch (intent) {
    case "create-item":
      return createItem(formData);
    case "update-item":
      return updateItem(formData);
    case "delete-item":
      return deleteItem(formData);
    default:
      throw new Error("Unknown intent");
  }
}

// IN THE COMPONENT:
function MyComponent() {
  const fetcher = useFetcher();

  const handleCreate = () => {
    fetcher.submit(
      { intent: "create-item", name: "Manager" },
      { method: "post" }
    );
  };

  const handleDelete = () => {
    fetcher.submit(
      { intent: "delete-item", id: "123" },
      { method: "post" }
    );
  };
}

Why Use Intents?

Single action endpoint handles multiple operations
Cleaner routing (one route vs. many)
Easier to share logic between operations

Understanding "Optimistic UI"

Optimistic UI means updating the UI BEFORE the server confirms the operation succeeded. You "optimistically" assume it will work.

General Pattern:

function TodoList() {
  const [todos, setTodos] = useState([
    { id: 1, text: "Buy milk", done: false },
    { id: 2, text: "Walk dog", done: false }
  ]);
  const fetcher = useFetcher();

  const toggleTodo = (id: number) => {
    // ✅ OPTIMISTIC: Update UI immediately
    setTodos(prev => prev.map(todo =>
      todo.id === id ? { ...todo, done: !todo.done } : todo
    ));

    // THEN send to server (might fail!)
    fetcher.submit(
      { intent: "toggle-todo", id },
      { method: "post" }
    );
  };

  // If server fails, rollback:
  useEffect(() => {
    if (fetcher.data?.error) {
      // Revert the optimistic change
      setTodos(prevTodos => /* restore original state */);
    }
  }, [fetcher.data]);

  return (
    <ul>
      {todos.map(todo => (
        <li
          onClick={() => toggleTodo(todo.id)}
          style={{ textDecoration: todo.done ? 'line-through' : 'none' }}
        >
          {todo.text}
        </li>
      ))}
    </ul>
  );
}

The UX Benefit:

User clicks → Instant feedback (no waiting for server)
Feels snappy and responsive
If server fails, you rollback and show error

When It Works Best:

Toggles (like/unlike, complete/incomplete)
Non-destructive operations
Operations with high success rate

When It's Risky:

Deletions (hard to rollback psychologically)
Critical operations (payments, permissions)
Complex validations (server might reject)

Understanding Common UI Component Patterns

Before diving into the implementation, let's understand the key UI components used:

Modal/Dialog Component Pattern

A Dialog is a component that overlays the main UI to demand user attention:

// Generic Dialog Component
interface DialogProps {
  isOpen: boolean;          // Controls visibility
  onClose: () => void;      // Called when user dismisses
  title?: string;
  children: React.ReactNode; // The content inside
}

function Dialog({ isOpen, onClose, title, children }: DialogProps) {
  if (!isOpen) return null; // Don't render if closed

  return (
    <div className="overlay" onClick={onClose}>
      <div className="dialog" onClick={e => e.stopPropagation()}>
        {title && <h2>{title}</h2>}
        {children}
        <button onClick={onClose}>Cancel</button>
      </div>
    </div>
  );
}

// Usage Example
function MyComponent() {
  const [showDialog, setShowDialog] = useState(false);

  return (
    <>
      <button onClick={() => setShowDialog(true)}>Open</button>

      <Dialog
        isOpen={showDialog}
        onClose={() => setShowDialog(false)}
        title="Confirm Action"
      >
        <p>Are you sure?</p>
        <button onClick={() => {
          performAction();
          setShowDialog(false);
        }}>
          Yes, Continue
        </button>
      </Dialog>
    </>
  );
}

Key Principles:

Parent owns the isOpen state
Dialog is controlled (doesn't manage its own visibility)
onClose callback lets parent handle dismissal
Click overlay to close (UX standard)

Table Component Pattern

Tables display lists of data with consistent formatting:

// Generic Table Component
interface TableProps<T> {
  data: T[];                           // Array of items to display
  renderRow: (item: T) => JSX.Element; // How to render each row
  columns: string[];                   // Column headers
  loading?: boolean;
}

function Table<T>({ data, renderRow, columns, loading }: TableProps<T>) {
  return (
    <table>
      <thead>
        <tr>
          {columns.map(col => <th key={col}>{col}</th>)}
        </tr>
      </thead>
      <tbody>
        {loading ? (
          <tr><td colSpan={columns.length}>Loading...</td></tr>
        ) : (
          data.map(renderRow)
        )}
      </tbody>
    </table>
  );
}

// Usage Example
function UserList() {
  const [users, setUsers] = useState([]);

  const renderUserRow = (user) => (
    <tr key={user.id}>
      <td>{user.name}</td>
      <td>{user.email}</td>
      <td>
        <button onClick={() => deleteUser(user.id)}>Delete</button>
      </td>
    </tr>
  );

  return (
    <Table
      data={users}
      renderRow={renderUserRow}
      columns={['Name', 'Email', 'Actions']}
    />
  );
}

Key Principles:

Parent owns the data
Table is presentational (just renders what it's given)
renderRow gives parent control over formatting
Table doesn't know about business logic (deleting, editing, etc.)

Toast/Notification Component Pattern

Toasts show temporary feedback messages that auto-dismiss:

// Generic Toast Component
interface ToastProps {
  message: string;
  type: 'success' | 'error' | 'info';
  isVisible: boolean;
  onDismiss: () => void;
  duration?: number; // Auto-dismiss after X milliseconds
}

function Toast({ message, type, isVisible, onDismiss, duration = 5000 }: ToastProps) {
  useEffect(() => {
    if (isVisible && duration > 0) {
      const timer = setTimeout(onDismiss, duration);
      return () => clearTimeout(timer); // Cleanup
    }
  }, [isVisible, duration, onDismiss]);

  if (!isVisible) return null;

  return (
    <div className={`toast toast-${type}`}>
      <span>{message}</span>
      <button onClick={onDismiss}>✕</button>
    </div>
  );
}

// Usage Example
function MyComponent() {
  const [toast, setToast] = useState({ visible: false, message: '', type: 'info' });

  const showSuccess = (message: string) => {
    setToast({ visible: true, message, type: 'success' });
  };

  return (
    <>
      <button onClick={() => showSuccess('Action completed!')}>
        Do Something
      </button>

      <Toast
        isVisible={toast.visible}
        message={toast.message}
        type={toast.type}
        onDismiss={() => setToast(prev => ({ ...prev, visible: false }))}
        duration={5000} // 5 seconds
      />
    </>
  );
}

Key Principles:

Auto-dismiss with setTimeout (accessibility: users need time to read)
Manual dismiss button (accessibility: user control)
Parent manages visibility state
Different types for different contexts (success/error/info)

My First Attempt: Intent-Based Optimistic Delete

I thought: "I'll use the intent pattern to hide the row immediately, before the server responds!"

The Code:

// ========================================
// FILE: pages/items/index.tsx
// ========================================

function ItemsPage() {
  const data = useLoaderData();
  const fetcher = useFetcher();

  // Try to determine if a delete is in progress
  const deletingItemId = fetcher.formData?.get("itemId");

  return (
    <DataTable
      connection={data.connection}
      deletingId={deletingItemId} // Pass "intent" to child
    />
  );
}

// ========================================
// FILE: components/DataTable.tsx
// ========================================

function DataTable({ connection, deletingId }) {
  // Filter out the item being deleted
  const visibleEdges = connection.edges.filter(edge => {
    // If this item is currently being deleted, hide it
    if (deletingId && edge.node.id === deletingId) {
      return false; // Don't show this row
    }
    return true; // Show all other rows
  });

  return (
    <table>
      {visibleEdges.map(edge => (
        <ItemRow key={edge.node.id} item={edge.node} />
      ))}
    </table>
  );
}

// ========================================
// FILE: app/domains/panels/components/ItemDeleteDialog/index.tsx
// ========================================

function ItemDeleteDialog({ itemId, isOpen, onClose }) {
  const fetcher = useFetcher();

  const handleDelete = () => {
    // Submit with intent
    fetcher.submit(
      { itemId, intent: "delete-item" },
      { method: "delete", action: `/api/items/${itemId}` }
    );
  };

  return (
    <Dialog isOpen={isOpen} onClose={onClose}>
      <button onClick={handleDelete}>Delete</button>
    </Dialog>
  );
}

What I Expected to Happen

User clicks delete → Dialog submits with { itemId: "123", intent: "delete-item" }
Immediately, fetcher.formData contains this data
Parent reads deletingItemId = "123"
DataTable filters out item "123"
Row disappears instantly (optimistic!)
Server processes deletion
Success! Row stays gone.

What Actually Happened (The Bug)

Timeline:
─────────────────────────────────────────────────────
T=0ms:   User clicks "Delete" button
T=1ms:   fetcher.submit() called
         fetcher.state = "submitting"
         fetcher.formData = { itemId: "123", intent: "delete-item" }

T=2ms:   Parent re-renders
         deletingItemId = "123" ← Reads from formData

T=3ms:   DataTable re-renders
         Filters out edge with id="123"
         Row disappears ✅ (looks good!)

T=200ms: Network request completes
         Server responds: { success: true }
         fetcher.state = "loading"

T=205ms: Remix processes response
         fetcher.state = "idle" ← Back to idle!
         fetcher.formData = undefined ← CLEARED!
         fetcher.data = { success: true }

T=206ms: Parent re-renders
         deletingItemId = undefined ← formData is gone!

T=207ms: DataTable re-renders
         No longer filtering anything
         Row reappears! ❌❌❌ ZOMBIE IS BACK!

Why It Failed: The Fetcher Lifecycle

The problem is that fetcher.formData is transient. Remix clears it once the request completes. Here's the lifecycle:

// FETCHER LIFECYCLE:

// Before submit:
fetcher.state = "idle"
fetcher.formData = undefined
fetcher.data = undefined

// After fetcher.submit():
fetcher.state = "submitting"
fetcher.formData = { itemId: "123" } ← Available here
fetcher.data = undefined

// Server responding:
fetcher.state = "loading"
fetcher.formData = { itemId: "123" } ← Still available
fetcher.data = undefined

// After server responds:
fetcher.state = "idle"
fetcher.formData = undefined ← ❌ CLEARED!
fetcher.data = { success: true } ← Response is here

So my logic was:

const deletingItemId = fetcher.formData?.get("itemId");
// This is only defined DURING submission
// Once the request completes, it becomes undefined
// → The filter stops working
// → The row reappears

Additional Problems I Encountered

Problem 1: The "Flicker"

The row would:

Disappear (when formData exists)
Reappear for ~200ms (when formData clears but before success logic runs)
Disappear again (when success logic finally hides it)

Users saw a flicker—the zombie briefly came back to life.

Problem 2: Load More Confusion

// If user clicked "Load More" after deleting:
useEffect(() => {
  if (fetcher.data?.connection) {
    setEdges(prev => [...prev, ...fetcher.data.connection.edges]);
    // ❌ New edges don't know about the deleted item
    // ❌ If deleted item was on page 2, it comes back!
  }
}, [fetcher.data]);

Problem 3: Multiple Rapid Deletes

// User deletes item "123"
deletingItemId = "123" // Only tracks ONE at a time

// Before that finishes, user deletes item "456"
deletingItemId = "456" // Overwrites!

// Now item "123" reappears while "456" is hidden
// Then both reappear when submission completes

The Lessons I Learned

fetcher.formData is not state—it's ephemeral request data
Optimistic UI requires persistence—you need actual state to track what's deleted
Intents alone don't solve state management—they're just command identifiers
Filter logic needs to survive across renders—can't depend on transient values

This attempt taught me: The parent needs to OWN the deleted IDs in real state, not borrow them from the fetcher.

Attempt #2: The "Ref Jungle" (❌ Still Broken)

Commit: a8d27c45 - "fixing bugs in delete"
Date: January 21, 2026
Duration: 2 hours of escalating complexity

After Attempt #1 failed, I thought: "The problem is that the success callback is firing multiple times and creating race conditions. I'll use refs to create locks!"

Understanding the Problem I Was Trying to Solve

I noticed in the console:

DELETE SUCCESS! Item: 123
DELETE SUCCESS! Item: 123
DELETE SUCCESS! Item: 123
Toast shown
Toast shown
Toast shown

The handleDeleteSuccess callback was being called 3 times for a single deletion! Why?

Understanding `useEffect` Dependency Pitfalls

This was happening because of how I structured my useEffect:

// ❌ MY BROKEN CODE

const handleDeleteSuccess = () => {
  console.log("DELETE SUCCESS!");
  setShowSuccessToast(true);
};

useEffect(() => {
  if (fetcher.state === "idle" && fetcher.data?.success) {
    handleDeleteSuccess(); // Called every time this effect runs
  }
}, [fetcher.state, fetcher.data, handleDeleteSuccess]);
//    ^^^^^^^^^^^  ^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^
//    Changes      Changes      NEW FUNCTION EVERY RENDER!

The Problem:

handleDeleteSuccess is redefined on every render (new function reference)
It's in the dependency array
So the effect runs on every render
Each time, it sees fetcher.data.success and calls the handler again

The Render Cycle:

Render 1: handleDeleteSuccess = Function@0x001
          Effect runs → calls handleDeleteSuccess

Render 2: handleDeleteSuccess = Function@0x002 ← NEW reference!
          Dependency changed! Effect runs again → calls handleDeleteSuccess

Render 3: handleDeleteSuccess = Function@0x003 ← NEW reference!
          Dependency changed! Effect runs again → calls handleDeleteSuccess

My Solution: The Ref Locks

I thought: "I'll use useRef to create 'locks' that prevent double-execution!"

// ========================================
// ATTEMPT #2 CODE
// ========================================

function ItemsPage() {
  const fetcher = useFetcher();
  const data = useLoaderData();

  // ========= STATE =========
  const [isDeleteDialogOpen, setIsDeleteDialogOpen] = useState(false);
  const [selectedItemName, setSelectedItemName] = useState("");
  const [selectedItemId, setSelectedItemId] = useState("");
  const [showSuccessToast, setShowSuccessToast] = useState(false);
  const [showErrorMessage, setShowErrorMessage] = useState(false);
  const [errorMessage, setErrorMessage] = useState("");

  // ========= THE REF JUNGLE =========

  // Ref #1: Store the ID we're currently deleting
  const selectedItemIdRef = useRef<string>("");

  // Ref #2: Track which ID we've already shown success for
  const successHandledRef = useRef<string | null>(null);

  // Ref #3: Track which error we've already shown
  const dismissedErrorRef = useRef<string | null>(null);

  // Ref #4: Store timeout for auto-dismissing errors
  const errorTimeoutRef = useRef<NodeJS.Timeout | null>(null);

  // Ref #5: Store timeout for auto-dismissing success toast
  const successTimeoutRef = useRef<NodeJS.Timeout | null>(null);

  // ========= OPEN DELETE DIALOG =========
  const openDeleteDialog = (itemName: string, itemId: string) => {
    // Clear any existing timeouts
    if (errorTimeoutRef.current) {
      clearTimeout(errorTimeoutRef.current);
      errorTimeoutRef.current = null;
    }
    if (successTimeoutRef.current) {
      clearTimeout(successTimeoutRef.current);
      successTimeoutRef.current = null;
    }

    // Reset states
    setShowErrorMessage(false);
    setErrorMessage("");
    setShowSuccessToast(false);
    dismissedErrorRef.current = null;

    // Store the item info
    setSelectedItemName(itemName);
    setSelectedItemId(itemId);
    selectedItemIdRef.current = itemId; // Store in ref too!

    setIsDeleteDialogOpen(true);
  };

  // ========= HANDLE DELETE SUCCESS =========
  const handleDeleteSuccess = useCallback(() => {
    // 🔒 LOCK #1: Prevent duplicate success handling
    if (successHandledRef.current === selectedItemIdRef.current) {
      console.log("Already handled success for", selectedItemIdRef.current);
      return; // Exit early - we've already processed this
    }

    console.log("Handling success for", selectedItemIdRef.current);
    successHandledRef.current = selectedItemIdRef.current; // Mark as handled

    // Clear any errors
    if (errorTimeoutRef.current) {
      clearTimeout(errorTimeoutRef.current);
      errorTimeoutRef.current = null;
    }
    setShowErrorMessage(false);
    setErrorMessage("");

    // Show success toast
    setShowSuccessToast(true);

    // Auto-dismiss toast after 3 seconds
    successTimeoutRef.current = setTimeout(() => {
      setShowSuccessToast(false);
      successHandledRef.current = null; // Reset the lock
    }, 3000);

  }, []); // Empty deps - function never changes

  // ========= HANDLE DELETE ERROR =========
  const handleDeleteError = useCallback((error: string) => {
    // 🔒 LOCK #2: Prevent showing same error multiple times
    if (dismissedErrorRef.current === error) {
      console.log("Error already dismissed:", error);
      return;
    }

    // Clear success toast
    if (successTimeoutRef.current) {
      clearTimeout(successTimeoutRef.current);
      successTimeoutRef.current = null;
    }
    setShowSuccessToast(false);

    // Show error
    setErrorMessage(error);
    setShowErrorMessage(true);

    // Auto-dismiss error after 5 seconds
    errorTimeoutRef.current = setTimeout(() => {
      setShowErrorMessage(false);
      setErrorMessage("");
      dismissedErrorRef.current = null; // Reset the lock
    }, 5000);

  }, []);

  // ========= MONITOR FETCHER FOR RESULTS =========
  useEffect(() => {
    if (fetcher.state === "idle" && fetcher.data) {
      const response = fetcher.data as DeleteResponse;

      if (response.success) {
        handleDeleteSuccess();
      } else if (response.error) {
        handleDeleteError(response.error);
      }
    }
  }, [fetcher.state, fetcher.data, handleDeleteSuccess, handleDeleteError]);

  // ... rest of component
}

What I Expected

I thought the refs would act like "mutex locks" in backend programming:

First call to handleDeleteSuccess sets successHandledRef = "123"
Subsequent calls see the lock and return early
After toast auto-dismisses, reset the lock for next deletion

What Actually Happened

Problem 1: Lock Reset Timing

// Deletion 1: Item "123"
successHandledRef.current = "123" // Lock set
setTimeout(() => {
  successHandledRef.current = null; // Lock cleared after 3s
}, 3000);

// User immediately deletes Item "456"
if (successHandledRef.current === selectedItemIdRef.current) {
  // successHandledRef = "123"
  // selectedItemIdRef = "456"
  // Not equal! So it runs... but...
}

// Wait, what if the first timeout fires while we're deleting the second?
// Lock gets cleared while we still need it!

Problem 2: Still No Solution for Zombie Rows

All these refs were preventing duplicate success messages, but they did NOTHING to solve the actual zombie row problem! The item was still visible in the table because the DataTable still had no way to know about the deletion.

Problem 3: Code Became Unreadable

Look at that code! 5 different refs tracking different aspects of state. It became:

Hard to understand what each ref does
Hard to debug (refs don't show in React DevTools)
Fragile (race conditions between timeouts and user actions)
Not solving the actual problem

The Error I Made: Treating Symptoms, Not the Disease

I was using refs as "band-aids" to fix symptoms:

✓ Prevented duplicate toast messages
✓ Prevented duplicate error alerts
✓ Managed timeouts

But I wasn't fixing the disease:

❌ Zombie rows still appeared
❌ State management still broken
❌ Parent-child communication still missing

Understanding Why Refs Were the Wrong Tool

Refs are good for:

Storing timers (so you can clear them)
Storing DOM references
Storing previous values for comparison
Values that don't affect rendering

Refs are BAD for:

Managing UI state (use useState)
Coordinating between components (use props)
Data that should trigger re-renders
Trying to "lock" or "synchronize" state updates

Backend Analogy:

It's like I was using database triggers to prevent duplicate API calls, when the real problem was that my API endpoint was being called incorrectly in the first place. I should have fixed the caller, not added defensive logic in the database.

The Lessons I Learned

Refs don't fix architecture problems—they're a tool, not a solution
Defensive coding indicates a deeper issue—if you need 5 locks, your design is wrong
Complexity is a code smell—simple problems should have simple solutions
Fix the root cause, not the symptoms—zombie rows were the real issue

After this attempt, I realized: I need to rethink the entire state management architecture, not add more band-aids.

Attempt #3: State Ownership & The Infinite Loop (🔧 Partial Success)

Commit: 47748f68 - "fixing load more issues with delete"
Date: January 23, 2026
Duration: 4 hours of breakthrough and frustration

After two failures, I had a realization: The parent needs to OWN the list of deleted IDs in real state.

The Architectural Shift

I decided to fundamentally change the approach:

❌ Old: Child (DataTable) owns data, parent tries to influence it
✅ New: Parent owns data, parent owns deletions, child just renders

Understanding "State Lifting"

State Lifting means moving state UP the component tree to a common ancestor.

General Pattern:

// ❌ BEFORE: Child owns state
function Parent() {
  return <Child />; // Parent has no control
}

function Child() {
  const [data, setData] = useState([1, 2, 3]); // Child owns it
  return <div>{data.map(n => <span>{n}</span>)}</div>;
}

// ✅ AFTER: Parent owns state
function Parent() {
  const [data, setData] = useState([1, 2, 3]); // Parent owns it
  return <Child data={data} />; // Parent controls it
}

function Child({ data }) {
  // Child is now "dumb" - just displays what parent gives
  return <div>{data.map(n => <span>{n}</span>)}</div>;
}

Why Lift State?

Multiple components need the same data
Parent needs to modify child's data
Sibling components need to communicate
Easier to debug (single source of truth)

My Implementation: The deletedItemIds Set

// ========================================
// FILE: pages/items/index.tsx
// ========================================

function ItemsPage() {
  const data = useLoaderData();
  const fetcher = useFetcher();

  // ========= LIFTED STATE =========

  // NEW: Parent owns the list of deleted IDs
  const [deletedItemIds, setDeletedItemIds] = useState<Set<string>>(new Set());

  // Still using a ref to track current deletion
  const selectedItemIdRef = useRef<string>("");

  // ========= DELETE SUCCESS HANDLER =========

  const handleDeleteSuccess = useCallback(() => {
    // Add the deleted ID to our Set
    setDeletedItemIds((prev) => {
      const newSet = new Set(prev); // Copy the old Set
      newSet.add(selectedItemIdRef.current); // Add new ID
      return newSet; // Return new Set (triggers re-render)
    });

    setShowSuccessToast(true);
  }, []);

  // ========= FILTERING LOGIC =========

  // Create filtered version of edges
  const visibleItems = useMemo(() => {
    return (data.connection?.edges ?? []).filter(edge => {
      // If this item's ID is in our deleted set, don't show it
      return !deletedItemIds.has(edge?.node?.id ?? "");
    });
  }, [data.connection?.edges, deletedItemIds]);

  // Create a new connection object with filtered edges
  const connection = useMemo(() => ({
    edges: visibleItems,
    pageInfo: data.connection?.pageInfo,
  }), [visibleItems, data.connection?.pageInfo]);

  // ========= RENDER =========

  return (
    <Container>
      <DataTable
        connection={connection} // Pass filtered connection
        header={header}
        renderRow={renderRow}
        fetcher={fetcher}
      />
    </Container>
  );
}

Why Use a Set Instead of an Array?

I used Set<string> instead of string[]. Here's why:

// ❌ With Array - O(n) lookup
const deletedIds = ["123", "456", "789"];
const isDeleted = deletedIds.includes("456"); // Loops through array

// ✅ With Set - O(1) lookup
const deletedIds = new Set(["123", "456", "789"]);
const isDeleted = deletedIds.has("456"); // Hash table lookup (instant)

// Performance comparison with 100 deleted items:
// Array: 100 comparisons worst case
// Set: 1 hash lookup

Backend Analogy: Set is like a database index—instant lookup vs. full table scan.

Understanding `useMemo` in This Context

const visibleItems = useMemo(() => {
  return (data.connection?.edges ?? []).filter(edge => {
    return !deletedItemIds.has(edge?.node?.id ?? "");
  });
}, [data.connection?.edges, deletedItemIds]);
//    ^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^
//    Recalc when edges     Or deletedItemIds
//    change                changes

Why useMemo here?

Without useMemo, this filter would run on EVERY render:

// ❌ Without useMemo
function Component() {
  const visibleItems = data.connection.edges.filter(...); // Runs every render
  // Even if data.connection and deletedItemIds haven't changed!

  return <Table rows={visibleItems} />;
}

// ✅ With useMemo
function Component() {
  const visibleItems = useMemo(() =>
    data.connection.edges.filter(...),
    [data.connection.edges, deletedItemIds]
  ); // Only runs when dependencies change

  return <Table rows={visibleItems} />;
}

What Worked: The Immediate Win

✅ Instant Removal:

// User clicks delete
handleDeleteSuccess();

// Inside handleDeleteSuccess:
setDeletedItemIds(prev => new Set(prev).add("123"));

// React re-renders:
visibleItems = edges.filter(edge => !deletedItemIds.has(edge.node.id));
// Item "123" is filtered out
// Row disappears immediately!

✅ Persistence Across Load More:

// User has deleted item "123"
deletedItemIds = Set(["123"])

// User clicks "Load More"
// Server returns page 2 with items 21-40
// One of them happens to be item "123" again (shouldn't happen, but if it does)

visibleItems = allEdges.filter(edge => !deletedItemIds.has(edge.node.id));
// Item "123" stays filtered out!

What Still Didn't Work: The Infinite Loop

But then I encountered a NEW problem: the infinite re-render loop.

The Bug in DataTable

Remember, DataTable still had internal state for handling "Load More":

// ========================================
// FILE: components/DataTable.tsx (BUGGY VERSION)
// ========================================

function DataTable({ connection, fetcher }) {
  // DataTable STILL owns edges state
  const [edges, setEdges] = useState(connection.edges);

  // Handle Load More
  useEffect(() => {
    if (!fetcher.data?.connection) return;

    // Append new edges
    setEdges(prev => [...prev, ...fetcher.data.connection.edges]);
    //         ^^^^
    //         Reading edges here

  }, [fetcher.data, edges]); // ❌ edges in dependency array!
  //                ^^^^^^

  return (
    <table>
      {edges.map(edge => <ItemRow key={edge.node.id} item={edge.node} />)}
    </table>
  );
}

Understanding the Infinite Loop

Initial Render:
────────────────
edges = [item1, item2, item3]
Effect runs (fetcher.data is null, so returns early)

User Clicks "Load More":
────────────────────────
fetcher.data = { connection: { edges: [item4, item5] } }

Effect runs:
  setEdges([item1, item2, item3, item4, item5])

edges changes → Effect deps changed!
────────────────────────────────────
Effect runs AGAIN:
  fetcher.data still has { edges: [item4, item5] }
  setEdges([item1, item2, item3, item4, item5, item4, item5]) ← DUPLICATES!

edges changes again → Effect deps changed AGAIN!
──────────────────────────────────────────────────
Effect runs AGAIN:
  setEdges([..., item4, item5, item4, item5, item4, item5]) ← MORE DUPLICATES!

Infinite loop:
  setEdges → edges changes → effect runs → setEdges → ...

The Core Issue:

useEffect(() => {
  setEdges([...edges, ...newEdges]); // ❌ Reading `edges`
}, [edges]); // ❌ `edges` as dependency

// This creates a feedback loop:
// edges changes → effect runs → setEdges → edges changes → ...

My Attempted Fix: The Nuclear Option

I tried a desperate hack:

<DataTable
  key={visibleItems.length} // ← Force React to destroy and recreate
  connection={connection}
/>

What key Does:

When the key prop changes, React completely destroys the old component and creates a brand new one.

// First render:
<DataTable key={20} /> // 20 items visible

// After deletion:
<DataTable key={19} /> // 19 items visible

// React sees different key:
// 1. Unmount old <DataTable key={20}> (destroy it completely)
// 2. Mount new <DataTable key={19}> (fresh new instance)

Why This "Worked":

Every time visible count changed, React destroyed and recreated DataTable
New instance = fresh state = no infinite loop
But TERRIBLE for performance and user experience

The Side Effects:

Lost scroll position
Lost any UI state in the table
Caused visible "flash" as table re-rendered
Destroyed focus state
Horrible hack that solved symptoms, not cause

Why It Was "Partial Success"

✅ Wins:

Deleted items disappeared immediately
Deletions persisted across Load More
Single source of truth (parent owns deletedItemIds)
No more ref jungles

❌ Problems:

Infinite loop with Load More
Had to use key hack to prevent loop
DataTable still had internal state (wrong!)
Tight coupling (parent creates filtered connection)
Not reusable (DataTable expects specific structure)

The Lessons I Learned

State lifting solves parent-child communication—but both must cooperate
Reading state you're setting in useEffect = infinite loop—use functional setState
key prop is for lists, not fixing bugs—using it to force remount is a code smell
Child components with internal state are hard to control—presentational pattern is better
Partial solutions create technical debt—you're just postponing the real fix

This attempt got us 70% there, but the architecture was still fighting itself. The DataTable needed to be completely stateless for this to work properly.

🏆 Chapter 5: The Victory (The Final Solution)

Current Implementation
Date: January 27, 2026
The Moment Everything Clicked

After three failed attempts and hours of debugging, I finally understood the root problem: I was trying to control a stateful child from a stateful parent. Both were fighting for ownership of the data.

The solution? Make the child completely stateless.

Understanding Container/Presentational Pattern

This is a fundamental React pattern that I should have used from the start.

The Pattern Explained

Container Component (Smart):

Owns all state
Handles business logic
Makes API calls
Processes data
Manages side effects (useEffect)
Passes data DOWN to presentational components

Presentational Component (Dumb):

Receives props only
No useState
No useEffect
No business logic
Just renders what it's told
Pure function: same props = same output

General Example:

// ========================================
// ❌ BAD: Both components manage state
// ========================================

function Parent() {
  const [filter, setFilter] = useState("");
  return <Child onFilterChange={setFilter} />; // Trying to control child
}

function Child({ onFilterChange }) {
  const [items, setItems] = useState([...]); // Child owns data
  const [filteredItems, setFilteredItems] = useState([...]);

  useEffect(() => {
    // Child tries to sync with parent - messy!
  }, [onFilterChange]);

  return <List items={filteredItems} />;
}

// ========================================
// ✅ GOOD: Container/Presentational split
// ========================================

// CONTAINER (Smart)
function Parent() {
  const [items, setItems] = useState([...]); // Parent owns data
  const [filter, setFilter] = useState(""); // Parent owns filter

  const filteredItems = useMemo(() =>
    items.filter(item => item.includes(filter)),
    [items, filter]
  ); // Parent does the filtering

  return <Child items={filteredItems} />; // Just pass filtered data down
}

// PRESENTATIONAL (Dumb)
function Child({ items }) {
  // No state! Just renders what parent gives
  return (
    <ul>
      {items.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  );
}

Benefits:

Single Source of Truth: Parent owns everything
Easier to Test: Presentational component is pure (no mocks needed)
Reusable: Presentational component works with ANY data
No Sync Issues: No two sources of state to keep in sync
Debuggable: Just look at parent's state in React DevTools

The Breakthrough: Refactoring DataTable

I completely rewrote DataTable from stateful to stateless.

Before: Stateful DataTable (Problematic)

// ❌ BEFORE: DataTable manages its own state

export function DataTable({ connection, fetcher }) {
  // Child owns edges state
  const [edges, setEdges] = useState(connection.edges);

  // Child handles Load More
  useEffect(() => {
    if (!fetcher.data?.connection) return;
    setEdges(prev => [...prev, ...fetcher.data.connection.edges]);
  }, [fetcher.data, edges]); // ← Infinite loop!

  return (
    <table>
      {edges.map(edge => <Row key={edge.node.id} data={edge.node} />)}
      {connection.pageInfo?.hasNextPage && (
        <LoadMoreButton fetcher={fetcher} />
      )}
    </table>
  );
}

Problems:

Has its own state (edges)
Manages side effects (useEffect for Load More)
Parent can't control what's displayed
Infinite loop bug
Not reusable

After: Presentational DataTable (Clean)

// ✅ AFTER: DataTable is completely stateless

export type DataTableProps<T> = {
  edges: ConnectionEdge<T>[];        // Parent provides edges
  pageInfo?: PageInfo;               // Parent provides pageInfo
  renderRow: (edge: ConnectionEdge<T>) => ReactElement | null; // Parent controls rendering
  fetcher?: FetcherWithComponents<unknown>;
  header: ReactElement;
};

export function DataTable<T>({
  edges,
  pageInfo,
  renderRow,
  fetcher,
  header,
}: DataTableProps<T>) {
  // ✅ NO useState
  // ✅ NO useEffect
  // ✅ NO business logic

  // Just process what parent gives us
  const rows = useMemo(
    () => edges.map(renderRow).filter(Boolean), // Remove nulls
    [edges, renderRow]
  );

  return (
    <Table>
      <thead>{header}</thead>
      <tbody>{rows}</tbody>
      {pageInfo?.hasNextPage && (
        <tfoot>
          <tr>
            <td>
              <LoadMoreButton fetcher={fetcher} />
            </td>
          </tr>
        </tfoot>
      )}
    </Table>
  );
}

Key Changes:

Removed useState: No internal state
Removed useEffect: No side effects
Added renderRow prop: Parent controls how each row renders
Added edges prop: Parent passes the data
Made it generic <T>: Works with any data type

The Parent: Complete State Ownership

The parent (ItemsPage) now owns EVERYTHING:

// ========================================
// FILE: pages/items/index.tsx
// THE CONTAINER (Smart Component)
// ========================================

function ItemsPage() {
  const data = useLoaderData<typeof loader>();
  const fetcher = useFetcher();

  // ========= PARENT OWNS ALL STATE =========

  // 1. Owns the edges (accumulated from all loaded pages)
  const [edges, setEdges] = useState<ConnectionEdge<Item>[]>(
    data.connection?.edges ?? []
  );

  // 2. Owns the pageInfo (for knowing if there are more pages)
  const [pageInfo, setPageInfo] = useState<PageInfo | undefined>(
    data.connection?.pageInfo
  );

  // 3. Owns the list of deleted IDs
  const [deletedItemIds, setDeletedItemIds] = useState<Set<string>>(
    new Set()
  );

  // For tracking which item is being deleted
  const selectedItemIdRef = useRef<string>("");

  // ========= PARENT HANDLES LOAD MORE =========

  useEffect(() => {
    // Only process when fetcher is done and has data
    if (fetcher.state !== "idle") return;
    if (!fetcher.data?.connection) return;

    // Update pageInfo for next page
    setPageInfo(fetcher.data.connection.pageInfo ?? undefined);

    // Append new edges using FUNCTIONAL setState
    setEdges(prev => [...prev, ...fetcher.data.connection.edges]);
    //         ^^^^
    //         ✅ Using prev, not reading edges
    //         ✅ No infinite loop!

  }, [fetcher.data, fetcher.state]);
  //   ^^^^^^^^^^^^  ^^^^^^^^^^^^^
  //   ✅ Only these two dependencies
  //   ✅ edges is NOT in the array

  // ========= PARENT HANDLES DELETION =========

  const handleDeleteSuccess = useCallback(() => {
    // Add deleted ID to our Set
    setDeletedItemIds((prev) => {
      const newSet = new Set(prev);
      newSet.add(selectedItemIdRef.current);
      return newSet;
    });

    setShowSuccessToast(true);
  }, []);

  // ========= PARENT CONTROLS ROW RENDERING =========

  const renderRow = useCallback((edge: ConnectionEdge<Item>) => {
    const item = edge?.node;
    if (!item) return null;

    // ✅ FILTERING LOGIC: Return null for deleted items
    if (deletedItemIds.has(item.id)) {
      return null; // React will filter this out
    }

    // Render the actual row
    return (
      <ItemTableRow
        key={item.id}
        edge={edge}
        canEdit={canEdit}
        canDelete={canDelete}
        onDelete={() => openDeleteDialog(item.name, item.id)}
      />
    );
  }, [deletedItemIds, canEdit, canDelete, openDeleteDialog]);
  //   ^^^^^^^^^^^^^^^
  //   Only recreate renderRow when deletedItemIds changes

  // ========= RENDER =========

  return (
    <Container>
      {showSuccessToast && (
        <Toast message="Item deleted successfully" />
      )}

      {showErrorMessage && (
        <Alert message={errorMessage} />
      )}

      <ItemDeleteDialog
        isOpen={isDeleteDialogOpen}
        itemName={selectedItemName}
        itemId={selectedItemIdRef.current}
        onSuccess={handleDeleteSuccess}
        onError={handleDeleteError}
      />

      <DataTable
        edges={edges}              // ✅ Parent provides
        pageInfo={pageInfo}        // ✅ Parent provides
        renderRow={renderRow}      // ✅ Parent controls filtering
        fetcher={fetcher}          // For Load More button
        header={<TableHeader />}
      />
    </Container>
  );
}

Why This Works: The Magic of `renderRow`

The key innovation is the renderRow pattern:

// Parent defines this function
const renderRow = (edge) => {
  if (deletedItemIds.has(edge.node.id)) {
    return null; // ← Deleted items return null
  }
  return <ItemTableRow edge={edge} />;
};

// Child (DataTable) uses it
const rows = edges.map(renderRow).filter(Boolean);
//                                 ^^^^^^^^^^^^^^
//                                 Remove all nulls

How It Works:

// Example data flow:

edges = [
  { node: { id: "1", name: "Admin" } },
  { node: { id: "2", name: "Manager" } },  // ← User deleted this
  { node: { id: "3", name: "Viewer" } }
]

deletedItemIds = Set(["2"])

// Step 1: edges.map(renderRow)
[
  <ItemTableRow edge={edge1} />,  // renderRow returned component
  null,                            // renderRow returned null (deleted!)
  <ItemTableRow edge={edge3} />   // renderRow returned component
]

// Step 2: .filter(Boolean)
[
  <ItemTableRow edge={edge1} />,  // Boolean(component) = true ✓
                                  // Boolean(null) = false ✗ (filtered out)
  <ItemTableRow edge={edge3} />   // Boolean(component) = true ✓
]

// Result: Item "2" is gone from UI!

Why filter(Boolean) Works:

Boolean(null) === false        // ✗ Filtered out
Boolean(undefined) === false   // ✗ Filtered out
Boolean(0) === false          // ✗ Filtered out
Boolean("") === false         // ✗ Filtered out
Boolean(<Component />) === true // ✓ Kept
Boolean({}) === true          // ✓ Kept

Understanding Functional setState (No More Infinite Loops)

This was the KEY to fixing the infinite loop:

// ❌ BROKEN: Reading state in setState
useEffect(() => {
  setEdges([...edges, ...newEdges]); // Reading `edges`
}, [edges]); // `edges` in dependencies
// → edges changes → effect runs → setEdges → edges changes → infinite loop!

// ✅ FIXED: Functional setState
useEffect(() => {
  setEdges(prev => [...prev, ...newEdges]); // Using `prev` parameter
}, [fetcher.data]); // `edges` NOT in dependencies
// → fetcher.data changes → effect runs → setEdges → done!

How Functional setState Works:

// React guarantees `prev` is the LATEST value
setEdges(prev => {
  // prev = current edges at the moment of execution
  // Even if multiple setEdges are queued, each gets correct `prev`
  return [...prev, ...newEdges];
});

// Example with multiple updates:
setEdges(prev => [...prev, 1]);  // prev = []     → [1]
setEdges(prev => [...prev, 2]);  // prev = [1]    → [1, 2]
setEdges(prev => [...prev, 3]);  // prev = [1, 2] → [1, 2, 3]
// All queued updates execute correctly!

Backend Analogy:

-- ❌ Bad: Read then Write (race condition)
current_count = SELECT count FROM table;
UPDATE table SET count = current_count + 1;

-- ✅ Good: Atomic operation
UPDATE table SET count = count + 1;

The Complete Data Flow

Let me show you the ENTIRE flow from delete click to UI update:

USER ACTION: Clicks delete button on "Manager" item (id: "123")
────────────────────────────────────────────────────────────────

1. openDeleteDialog("Manager", "123")
   └─ selectedItemIdRef.current = "123"
   └─ setIsDeleteDialogOpen(true)

2. Dialog appears, user clicks "Delete"
   └─ fetcher.submit({}, { method: "delete", action: "/items/123/delete" })

3. SERVER processes deletion
   └─ DELETE_ITEM mutation executes
   └─ Returns: { success: true }

4. fetcher.data = { success: true }
   └─ fetcher.state = "idle"

5. useEffect detects fetcher.data changed
   └─ handleDeleteSuccess() called

6. Inside handleDeleteSuccess:
   setDeletedItemIds(prev => {
     const newSet = new Set(prev);     // Copy old Set: Set([])
     newSet.add("123");                 // Add deleted ID: Set(["123"])
     return newSet;                     // Return new Set
   });

7. deletedItemIds changes → Parent re-renders

8. renderRow function executes for each edge:

   edge1 (id: "1", name: "Admin"):
     ├─ deletedItemIds.has("1") ? NO
     └─ return <ItemTableRow edge={edge1} />

   edge2 (id: "123", name: "Manager"): ← THE DELETED ONE
     ├─ deletedItemIds.has("123") ? YES! ✓
     └─ return null ← Filtered out!

   edge3 (id: "3", name: "Viewer"):
     ├─ deletedItemIds.has("3") ? NO
     └─ return <ItemTableRow edge={edge3} />

9. DataTable receives:
   edges = [edge1, edge2, edge3]  // All 3 edges
   renderRow = (edge) => ...      // Function that returns null for edge2

   rows = edges.map(renderRow)    // [<Row1 />, null, <Row3 />]
               .filter(Boolean)    // [<Row1 />, <Row3 />]

10. UI renders:
    ┌────────────────────┐
    │ Admin    [View][Edit][Delete]  │
    │ Viewer   [View][Edit][Delete]  │  ← Manager is GONE!
    └────────────────────┘

TOTAL TIME: < 10ms (instant to user's eye)

Why This Solution is Perfect

1. Instant Removal

// The moment setDeletedItemIds completes:
// → React schedules re-render
// → renderRow filters out deleted ID
// → DataTable receives filtered rows
// → DOM updates
// User sees row disappear (< 16ms for 60fps)

No waiting for:

✗ Server confirmation (we already have it)
✗ Re-fetching data
✗ Cache invalidation
✗ Page reload

2. Load More Integration

// Scenario: User deletes item "123", then clicks Load More

// Current state:
edges = [item1, item2, item3] // Page 1
deletedItemIds = Set(["123"])

// User clicks Load More:
fetcher.submit() → Server returns page 2: [item4, item5, item6]

// useEffect runs:
setEdges(prev => [...prev, item4, item5, item6])
// Now edges = [item1, item2, item3, item4, item5, item6]

// renderRow still filters:
rows = edges
  .map(edge => deletedItemIds.has(edge.id) ? null : <Row />)
  .filter(Boolean)
// Even if item "123" was in page 2, it stays filtered!

3. No State Sync Issues

// Old problem: Parent and child both had state
// Parent: deletedIds = ["123"]
// Child: edges = [item1, item2, item3] ← Includes item "123"!
// → Out of sync! Zombie row appears

// New solution: Only parent has state
// Parent: edges = [item1, item2, item3]
//         deletedIds = ["123"]
//         renderRow = filters using deletedIds
// Child: Just renders what parent gives
// → Always in sync!

4. Easy to Test

// Testing DataTable (presentational):
test('renders rows from edges prop', () => {
  const edges = [edge1, edge2, edge3];
  const renderRow = (edge) => <div>{edge.node.name}</div>;

  render(<DataTable edges={edges} renderRow={renderRow} ... />);

  expect(screen.getByText('Item 1')).toBeInTheDocument();
  expect(screen.getByText('Item 2')).toBeInTheDocument();
  expect(screen.getByText('Item 3')).toBeInTheDocument();
});

// No mocking fetchers, no mocking API calls, no complex setup!
// Just: props in → UI out

5. Completely Reusable

The same DataTable can now be used for ANY paginated list:

// For Items:
<DataTable
  edges={itemEdges}
  renderRow={(edge) => <ItemRow item={edge.node} />}
/>

// For Users:
<DataTable
  edges={userEdges}
  renderRow={(edge) => <UserRow user={edge.node} />}
/>

// For Permissions:
<DataTable
  edges={permissionEdges}
  renderRow={(edge) => <PermissionRow permission={edge.node} />}
/>

No item-specific logic in DataTable!

Performance Characteristics

// Deletion operation complexity:

// Adding to Set:
deletedItemIds.add("123") // O(1) - hash table insert

// Checking if deleted:
deletedItemIds.has("123") // O(1) - hash table lookup

// Filtering edges:
edges.map(renderRow) // O(n) - where n = number of edges
  .filter(Boolean)   // O(n) - linear pass

// Total: O(n) where n = visible edges
// For 100 items: ~1-2ms
// For 1000 items: ~10-20ms (still imperceptible)

Compare to alternatives:

// Re-fetching from server:
// Network latency: 100-500ms
// Server query: 10-50ms
// Total: 110-550ms (noticeable delay)

// Our local filtering:
// Computation: 1-20ms (instant)

The Final Architecture Diagram

┌─────────────────────────────────────────────────────────┐
│                     ItemsPage (Container)               │
│                                                         │
│  State:                                                 │
│  ├─ edges: ConnectionEdge<Item>[]                       │
│  ├─ pageInfo: PageInfo                                  │
│  ├─ deletedItemIds: Set<string>                         │
│  └─ showSuccessToast: boolean                           │
│                                                         │
│  Logic:                                                 │
│  ├─ handleDeleteSuccess()                               │
│  ├─ handleLoadMore() (via useEffect)                    │
│  └─ renderRow() (filtering logic)                       │
│                                                         │
│  ┌────────────────┐         ┌────────────────┐         │
│  │ DeleteDialog   │         │   DataTable   │         │
│  │ (Smart)        │         │ (Presentational│         │
│  │                │         │                │         │
│  │ - Manages      │         │ - No state     │         │
│  │   fetcher      │         │ - No effects   │         │
│  │ - Calls        │         │ - Just renders │         │
│  │   onSuccess    │         │ - Pure         │         │
│  └────────────────┘         └────────────────┘         │
│         ▲                           ▲                   │
│         │                           │                   │
│    props: { itemId,            props: { edges,         │
│             onSuccess }               pageInfo,         │
│                                       renderRow }       │
└─────────────────────────────────────────────────────────┘

Data flows DOWN (props)
Events flow UP (callbacks)

// OLD (Broken):
useEffect(() => {
  setEdges([...edges, ...newEdges]);
}, [edges]); // ❌ edges changes → setEdges → edges changes → infinite loop

// NEW (Fixed):
useEffect(() => {
  setEdges((prev) => [...prev, ...newEdges]); // ✅ Functional setState
}, [fetcher.data]); // ✅ No edges in deps

4. Single Source of Truth

Parent = Container = Owns ALL state
DataTable = Presentational = Just renders what parent gives
Clear separation of concerns
Easy to test, debug, and maintain

5. Reusability

DataTable is now 100% generic
No item-specific logic
Can be reused for any paginated list (users, permissions, etc.)
Parent controls filtering logic via renderRow

Key Learnings

1. State Ownership Matters

❌ Anti-Pattern:

// Child owns state → Parent can't control child
function Child({ initialData }) {
  const [data, setData] = useState(initialData);
  // Parent has NO way to update this
}

✅ Best Practice:

// Parent owns state → Parent has full control
function Parent() {
  const [data, setData] = useState(initialData);
  return <Child data={data} />; // Child just renders
}

2. Functional setState Prevents Loops

❌ Dangerous:

useEffect(() => {
  setData([...data, ...newData]); // Reading data
}, [data]); // ❌ data in deps → infinite loop

✅ Safe:

useEffect(() => {
  setData((prev) => [...prev, ...newData]); // Not reading data
}, [newData]); // ✅ data NOT in deps → no loop

3. Optimistic UI vs. Confirmed Updates

Optimistic UI (update before server confirms):

Best for: Likes, favorites, simple toggles
Fast perceived performance
Risk: Rollback on failure

Confirmed Updates (update after server confirms):

Best for: Deletions, critical operations
Safer, no rollback needed
Our choice: Wait for server, then filter locally

4. Container/Presentational Pattern

Container (Smart Component):

Manages state, effects, business logic
Handles API calls, data transformations
Owns the "how it works"

Presentational (Dumb Component):

Receives props, renders UI
Pure functions, no side effects
Owns the "how it looks"

Benefits:

Easier testing (presentational has no dependencies)
Reusability (presentational works anywhere)
Maintainability (clear responsibilities)

Performance Considerations

Why Local Filtering Is Efficient

const renderRow = (edge) => {
  if (deletedItemIds.has(edge?.node?.id)) return null; // O(1) Set lookup
  return <ItemTableRow edge={edge} />;
};

const rows = edges.map(renderRow).filter(Boolean);

Set lookup: O(1) - Instant hash lookup
Map operation: O(n) - Linear through edges
Filter operation: O(n) - Remove nulls

Total: O(n) where n = number of edges

Why not re-fetch?

Network request: 100-500ms latency
Our filtering: < 1ms for 100 rows
Plus: Works offline, no loading state needed

Testing Evolution

Initial Tests (Optimistic UI)

// Expected optimistic removal
cy.get('[data-testid="item-row"]').should("have.length", 19); // Before server response

Current Tests (Confirmed Updates)

// Wait for server confirmation
cy.wait("@deleteItem");
cy.get('[data-testid="delete-success-toast"]').should("be.visible");

// Then verify removal
cy.get('[data-testid="item-row"]').should("have.length", 19);

26 comprehensive test cases covering:

Dialog interaction
Success/error flows
Pagination integration
Load More after deletion
Admin item protection
Toast auto-dismiss (5s accessibility)
Page refresh persistence

💡 Chapter 6: The Lessons (Key Takeaways)

This journey demonstrates fundamental React concepts that every developer should understand when building interactive UIs.

Lesson 1: State Ownership is Everything

Common Mistake:

Many developers try to "tell" child components what to do, treating them like independent services receiving commands.

// ❌ Imperative Thinking:
// "Send a message to the Table telling it to delete row 123"
<DataTable deletingId="123" />

// The table receives the "command" but may ignore it
// because it has its own internal state

The React Way:

React components don't receive "commands." They receive data (props) and render that data.

// ✅ The React Way:
// "Give the Table the list of rows to display"
<DataTable edges={filteredEdges} />

// Parent does the filtering, child just displays

Backend Analogy:

❌ Bad: Microservice with internal database
API → Service A (has own DB) → Service B (has own DB)
Problem: Two sources of truth, sync issues

✅ Good: Shared database, stateless services
API → Service A (stateless) → Database ← Service B (stateless)
Solution: One source of truth

The Rule:

In React, data flows DOWN (via props) and events flow UP (via callbacks). Never try to make data flow sideways or let children own critical state.

Lesson 2: useEffect Dependencies Are Not Optional

Common Mistakes:

// Mistake #1: Missing dependency
useEffect(() => {
  fetchData(userId); // Using userId
}, []); // ❌ userId not in array - uses stale value

// Mistake #2: Wrong dependency
useEffect(() => {
  setData([...data, newItem]); // Reading data
}, [data]); // ❌ Infinite loop!

// Mistake #3: Function dependency
useEffect(() => {
  handleUpdate();
}, [handleUpdate]); // ❌ Function recreated every render

The Correct Patterns:

// ✅ Pattern 1: Include all used values
useEffect(() => {
  fetchData(userId);
}, [userId]); // userId changes → fetch again

// ✅ Pattern 2: Functional setState
useEffect(() => {
  setData(prev => [...prev, newItem]); // Not reading data
}, [newItem]); // Only newItem in deps

// ✅ Pattern 3: useCallback for functions
const handleUpdate = useCallback(() => {
  // logic
}, [deps]); // Stable function reference

useEffect(() => {
  handleUpdate();
}, [handleUpdate]); // handleUpdate only changes when deps change

Mental Model:

Think of useEffect like a database trigger:

-- This trigger fires when user_id changes
CREATE TRIGGER on_user_change
  AFTER UPDATE OF user_id ON users
  FOR EACH ROW EXECUTE FUNCTION fetch_user_data();

-- Your dependencies = what columns trigger the effect
-- Your effect body = the stored procedure that runs

The Rule:

If you use it inside useEffect, it goes in the dependency array. No exceptions. Use ESLint's exhaustive-deps rule.

Lesson 3: Refs vs State - Know When to Use Which

Understanding the Difference:

Aspect	useState	useRef
Triggers re-render?	✅ Yes	❌ No
Survives re-renders?	✅ Yes	✅ Yes
Shows in React DevTools?	✅ Yes	❌ No
Good for UI data?	✅ Yes	❌ No
Good for timers/DOM refs?	❌ No	✅ Yes

Use useState for:

Data that affects what the user sees
Form inputs, toggles, selected items
Lists, counts, status flags
Anything that should trigger UI updates

Use useRef for:

Timer IDs (setTimeout, setInterval)
DOM element references
Previous values for comparison
Tracking if something was already processed
Any value that doesn't affect rendering

Example:

function Component() {
  // ✅ State: User sees this count
  const [count, setCount] = useState(0);

  // ✅ Ref: User doesn't see this, it's just internal tracking
  const renderCountRef = useRef(0);

  useEffect(() => {
    renderCountRef.current += 1;
    console.log(`Rendered ${renderCountRef.current} times`);
  });

  return (
    <div>
      <p>Count: {count}</p> {/* Shows in UI */}
      <button onClick={() => setCount(c => c + 1)}>Increment</button>
    </div>
  );
}

The Rule:

If it affects what the user sees, use useState. If it's just internal bookkeeping, use useRef.

Lesson 4: Container/Presentational Pattern

The Epiphany:

This pattern is like the Repository Pattern in backend:

Backend (Repository Pattern):
├─ Controller (handles HTTP, delegates)
├─ Service (business logic)
└─ Repository (data access, no logic)

Frontend (Container/Presentational):
├─ Page/Route (handles state, effects)
├─ Container (business logic)
└─ Component (presentation, no logic)

The Split:

// CONTAINER (Smart) - Like a Service Layer
function UserListContainer() {
  // Has state
  const [users, setUsers] = useState([]);
  const [filter, setFilter] = useState("");

  // Has effects
  useEffect(() => {
    fetchUsers().then(setUsers);
  }, []);

  // Has business logic
  const filteredUsers = users.filter(u => u.name.includes(filter));

  // Delegates rendering
  return <UserListPresentation users={filteredUsers} />;
}

// PRESENTATIONAL (Dumb) - Like a View/Template
function UserListPresentation({ users }) {
  // No state, no effects, no logic
  // Just renders what it's given
  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

Benefits:

Testing: Test presentation with simple props, test container with mocked services
Reusability: Same presentational component works with different data sources
Maintainability: Clear separation - logic in one place, UI in another
Performance: Presentational components can be memoized easily

The Rule:

If a component needs useState or useEffect, it's a Container. If it only receives props and renders, it's Presentational.

Lesson 5: The Power of Functional setState

What I Didn't Understand:

// I thought these were the same:
setCount(count + 1);           // ❌
setCount(prev => prev + 1);    // ✅

// They're not! Here's why:

The Difference:

// Scenario: Rapid clicks (3 clicks within 1ms)

// ❌ Regular setState:
onClick={() => setCount(count + 1)}

Click 1: count = 0, sets to 0 + 1 = 1
Click 2: count = 0 (still!), sets to 0 + 1 = 1  // Lost update!
Click 3: count = 0 (still!), sets to 0 + 1 = 1  // Lost update!
Result: count = 1 (should be 3!)

// ✅ Functional setState:
onClick={() => setCount(prev => prev + 1)}

Click 1: prev = 0, sets to 0 + 1 = 1
Click 2: prev = 1, sets to 1 + 1 = 2  // Correct!
Click 3: prev = 2, sets to 2 + 1 = 3  // Correct!
Result: count = 3 ✓

When It Matters:

// useEffect appending to arrays:
useEffect(() => {
  setEdges([...edges, ...newEdges]); // ❌ Reads stale edges
}, [fetcher.data]); // edges NOT in deps

// Fix:
useEffect(() => {
  setEdges(prev => [...prev, ...newEdges]); // ✅ Uses latest
}, [fetcher.data]);

The Rule:

Always use functional setState when: (1) The new value depends on the old value, (2) You're calling setState multiple times, or (3) setState is in useEffect.

Lesson 6: Understanding React's Rendering

What Triggers a Re-Render:

// These trigger re-renders:
setState(newValue)          // ✓
parent re-renders           // ✓ (even if props unchanged)
context value changes       // ✓

// These DON'T trigger re-renders:
ref.current = newValue      // ✗
props change (same object)  // ✗ (React uses Object.is)
local variable changes      // ✗

Example:

function Parent() {
  const [count, setCount] = useState(0);

  return <Child data={{ count }} />; // ← Creates NEW object every render!
}

function Child({ data }) {
  // Child re-renders every time Parent renders
  // Even if count hasn't changed!
  // Because { count: 1 } !== { count: 1 } (different object refs)
}

// Fix with useMemo:
function Parent() {
  const [count, setCount] = useState(0);
  const data = useMemo(() => ({ count }), [count]); // Same object if count unchanged

  return <Child data={data} />;
}

// Or better: Don't pass objects, pass primitives
function Parent() {
  const [count, setCount] = useState(0);
  return <Child count={count} />; // Primitive value
}

The Rule:

React compares props with Object.is(). Primitives compare by value, objects/arrays/functions compare by reference.

Lesson 7: Debugging Strategies

Tools I Learned to Use:

React DevTools
- Components tab: See props, state, hooks
- Profiler tab: Find slow renders
- Highlight updates: Visual feedback when components re-render
Console Logging

   useEffect(() => {
     console.log('Effect ran!', { fetcher });
     return () => console.log('Effect cleanup!');
   }, [fetcher]);

useEffect Dependency Debugger

   useEffect(() => {
     console.log('deps changed:', {
       'fetcher.data': fetcher.data,
       'fetcher.state': fetcher.state,
     });
   }, [fetcher.data, fetcher.state]);

Why Did You Render

   import { whyDidYouUpdate } from '@welldone-software/why-did-you-render';

   whyDidYouUpdate(React, {
     trackAllPureComponents: true,
   });

The Rule:

When debugging React, check: (1) What state changed? (2) What effect ran? (3) What components re-rendered? (4) What props changed?

Lesson 8: Common Pitfalls for Backend Engineers

Pitfall #1: Treating Components Like API Endpoints

// ❌ Backend thinking:
// "Send a DELETE request to the Table component"
<Table action="delete" id="123" />

// ✅ Frontend thinking:
// "Give Table the data to display"
<Table rows={filteredRows} />

Pitfall #2: Expecting Immediate State Updates

// ❌ Doesn't work:
setCount(1);
console.log(count); // Still 0!

// ✅ Works:
setCount(1);
// ... wait for re-render ...
// Now count is 1

Pitfall #3: Mutating State Directly

// ❌ Mutating (BAD):
const newEdges = edges;
newEdges.push(newItem);
setEdges(newEdges); // React won't detect the change!

// ✅ Creating new array (GOOD):
setEdges([...edges, newItem]); // New array reference

Pitfall #4: Not Understanding Closures

// ❌ Stale closure:
const [count, setCount] = useState(0);

useEffect(() => {
  const interval = setInterval(() => {
    setCount(count + 1); // `count` is always 0!
  }, 1000);

  return () => clearInterval(interval);
}, []); // Empty deps = count never updates

// ✅ Fresh value:
useEffect(() => {
  const interval = setInterval(() => {
    setCount(prev => prev + 1); // Uses latest value
  }, 1000);

  return () => clearInterval(interval);
}, []);

Pitfall #5: Over-Engineering with Refs

// ❌ Using refs for everything:
const dataRef = useRef([]);
const filterRef = useRef("");
const loadingRef = useRef(false);

// ✅ Use state for UI data:
const [data, setData] = useState([]);
const [filter, setFilter] = useState("");
const [loading, setLoading] = useState(false);

The Most Important Lessons

The three most critical principles for React state management:

"Lift state to the parent"
When in doubt, move state up. Parent controls, child displays.
"Use functional setState in effects"
setState(prev => newValue) prevents 90% of bugs.
"Make children dumb"
Components with no state are easy to understand, test, and reuse.

Core Understanding:

React challenges aren't about complexity—they're about understanding the paradigm shift from imperative to declarative programming.

The zombie row bug wasn't caused by React being "weird." It was caused by fighting React's patterns instead of embracing them.

Once you understand that React is declarative ("here's what the UI should look like") rather than imperative ("do this, then do that"), everything becomes clear.

Appendix: Quick Reference Guide

When to Use Each Hook

Hook	Use When	Don't Use When
`useState`	Data affects UI	Internal tracking only
`useEffect`	Side effects (API, timers, subscriptions)	Calculating derived data
`useRef`	Timers, DOM refs, previous values	UI state
`useMemo`	Expensive calculations	Simple operations
`useCallback`	Passing callbacks to optimized children	Passing to unoptimized children
`useReducer`	Complex state logic, multiple related states	Simple toggles/counters

Common Patterns Cheat Sheet

Functional setState:

setCount(prev => prev + 1)
setEdges(prev => [...prev, ...newEdges])
setObj(prev => ({ ...prev, key: newValue }))

Effect with cleanup:

useEffect(() => {
  const timer = setTimeout(...);
  return () => clearTimeout(timer);
}, [deps]);

Conditional effect:

useEffect(() => {
  if (!shouldRun) return;
  doSomething();
}, [shouldRun, deps]);

Debounced effect:

useEffect(() => {
  const timer = setTimeout(() => {
    search(query);
  }, 500);
  return () => clearTimeout(timer);
}, [query]);

Filtering with renderRow:

const renderRow = (item) => {
  if (shouldHide(item)) return null;
  return <Row data={item} />;
};

const rows = items.map(renderRow).filter(Boolean);

Debugging Checklist

When something doesn't work:

[ ] Check React DevTools for current state/props
[ ] Add console.logs in render and effects
[ ] Verify useEffect dependencies are correct
[ ] Check if state updates are using functional setState
[ ] Confirm you're not mutating state directly
[ ] Look for stale closures in effects/callbacks
[ ] Check if components are keyed properly in lists
[ ] Verify parent is passing correct props
[ ] Use React DevTools Profiler for performance issues

🎯 Wrapping Up

This journey from zombie rows to a clean solution demonstrates that React bugs are often architecture problems, not coding problems.

The three failed attempts weren't failures—they were learning experiences that led to understanding:

✅ State ownership matters - Parent controls, child renders
✅ Functional setState prevents bugs - setState(prev => ...) is your friend
✅ Container/Presentational pattern works - Separate logic from presentation
✅ React is declarative - Tell it what to show, not what to do
✅ useEffect dependencies are critical - No shortcuts allowed

These principles apply far beyond delete operations—they're fundamental to building maintainable React applications.

What's Next?

If you found this helpful:

💬 Comment below with your own "zombie row" stories
❤️ Save this article for future reference
🔗 Share it with teammates struggling with React state
🐦 Follow me for more deep-dives into frontend patterns

Quick Reference Card

The Golden Rules:

Parent owns state, child renders
Use setState(prev => ...) in effects
Lift state when child can't control it
Keep components simple and focused
Separate business logic from presentation
Never mutate state directly
Include ALL dependencies in useEffect
Use refs for non-UI data only

Enjoyed this deep dive?* Consider buying me a coffee ☕ on Superprofile to support more independent technical writing.

Thinking Declaratively: Why Your React Components Should Be "Mirrors"

ICraftCode — Tue, 27 Jan 2026 10:29:55 +0000

In React, there are two ways to solve any problem: you can act like a Chef (Imperative) or you can act like a Customer (Declarative).

1. The Core Philosophy: "What" vs. "How"

Imperative (How): You provide step-by-step instructions. "Open the fridge, take two eggs, crack them into the pan, turn the heat to medium, flip after 2 minutes." If you miss a single step, the kitchen catches fire.

Declarative (What): You describe the end state. "I'd like two fried eggs, please." You don't care how the stove works or which spatula is used; you just describe what should be on the plate.

2. A Simple Example: Filtering an Array

Imagine you have a list of numbers. You want only the numbers greater than 2.
The Imperative Way (Giving Instructions)
You manually manage a new array and tell the computer exactly how to fill it.

const numbers =;
const filtered = [];

for (let i = 0; i < numbers.length; i++) {
  if (numbers[i] > 2) {
    filtered.push(numbers[i]); // "Do this, then do that"
  }
}

You are responsible for the loop index, the temporary state, and the logic. It's "noisy" code.

The Declarative Way (Describing the Result)
You describe the relationship between the input and the output.

const numbers =;

const filtered = numbers.filter(n => n > 2); // "Give me numbers > 2"

The Beauty: You describe the result you want. JavaScript handles the process.

3. The "Secret Truth": Abstraction

A common question arises: "But isn't someone still doing the manual work?"
Yes. Under the hood, the JavaScript Engine (V8) is running a for loop for that .filter(). When you render a React component, React's Reconciliation Engine is manually calling DOM APIs to update the screen.
Declarative programming is an abstraction built on top of imperative code. We outsource the "How" to the experts (the language and framework authors) so we can focus entirely on the "What" (our product logic).

4. The Real-World Chaos: Deleting a Role
❌ The Imperative Way (The "Instruction" Nightmare)
Imagine you just clicked "Delete" on a Role. In our old imperative code, we had to manage a complex chain of events:

The Parent starts the deletion.
The Table (the "Chef") is holding its own internal copy of the data.
The Conflict: Even though the Role is deleted on the server, it still stays on the screen because the Table’s internal useState hasn't been "told" to remove it yet.
The Fix (More Chaos): We then have to write a manual instruction: "Hey Table, I know you have your own state, but please run this filter function to remove ID #123."
The Result: You end up with "Zombie Rows"—items that are dead in the database but alive on your screen because the manual "sync" instruction failed or was delayed.
Code smell: We were writing useEffect blocks that looked like this:

useEffect(() => {
  // Manual instruction: "If props change, force my internal state to match"
  setLocalEdges(props.edges); 
}, [props.edges]);

This is where the Infinite Re-render lives. If setLocalEdges accidentally triggers a parent update, the loop never ends.

✅ The Declarative Way (The "Mirror" Solution)
In the refactored version, we removed the Table's "brain" (internal state). It became a Mirror.
The Parent simply keeps a list of deletedRoleIds.
The Rule: The Parent says: "If an ID is in this 'Deleted' list, it doesn't exist."
The Render: The Table just follows the rule.

// The Parent's "Rule"
const renderRow = (role) => {
  if (deletedRoleIds.has(role.id)) return null; // Declarative: "Deleted = Nothing"
  return <RoleRow data={role} />;
};


// The Table's "Reflection"
const visibleRows = edges.map(renderRow).filter(Boolean);

Why this solved our real-world problem:
No more "Zombie Rows": The moment the Parent adds an ID to the deletedRoleIds Set, the row disappears. There is no "syncing" needed **because the Table is just a direct **reflection of the Parent's truth.
Zero Sync Logic: We deleted the useEffect entirely. By Lifting State Up, we moved from a fragile "syncing" process to a Single Source of Truth.
Performance: React's Reconciliation Engine is built for this. It handles the "how" of removing that row from the DOM much faster than our manual useEffect logic ever could.

Enjoyed this deep dive?* Consider buying me a coffee ☕ on Superprofile to support more independent technical writing.

A verse for the blockchain technology

ICraftCode — Mon, 02 Jun 2025 08:04:11 +0000

A genesis
A spark ignites,
the laws of time bend
as the fabric of space stretches,
unfolding, yet destined.

It spins,
perfect in its motion, beyond any singular will
a force with no crown to control.

The first ripple,
a genesis born,
spreading through a vastness,
unbound by the very hands
that set it free!

From the void,
an immutable chain,
etched itself into existence.

Holding it all together
is a protocol,
nobly crafted
to be stronger than its creator,
like the laws of physics,
governing the universe itself.

Oh, the mighty Bitcoin,
though your creator remains unseen,
Can we dare say there is none
given the ‘proof of work’ this phenomenal?

Enjoyed this deep dive?* Consider buying me a coffee ☕ on Superprofile to support more independent technical writing.

Will Code Become the New Handloom?

ICraftCode — Mon, 02 Jun 2025 08:00:23 +0000

Once, we handcrafted everything — paintings, fabrics, furniture. Then came machines. Production scaled, costs dropped and the world moved faster. Yet, people still seek the handmade, pay more for it and value the story behind the stitches.

Is, coding heading down a similar path?
AI can now generate functional, production-ready code in seconds. It’s fast, efficient and good enough for most needs. But as mass-produced code becomes the norm — will we start valuing the “handwritten” again?

Just like in art or fashion, there may be value in being able to say:
“This was written by hand.”

(Originally written by me on medium.com : https://medium.com/@iswarya/will-code-become-the-new-handloom-bcca14cb4d97)

Nest.js api throttling with redis

ICraftCode — Thu, 22 Jun 2023 06:47:10 +0000

API throttling is an essential mechanism to control and limit the number of requests made to an API within a specified timeframe. It helps protect the API from abuse, ensures fair usage, and prevents server overload. In this tutorial, I will tell you how to implemented API throttling using NestJS, Redis, and Docker Compose.

Why API Throttling with Redis?

In a distributed architecture, it becomes challenging to synchronize throttling limits across instances. This is where a shared storage solution like Redis comes into play. Redis provides a centralized storage mechanism that allows all instances to access and update throttling information consistently.

Below are the steps I had to do to use a shared storage for api throttling (note - this uses a single redis instance not a cluster. Will come up with a separate post for using redis clusters for the same)

Step 1: Changes to Docker Compose

services:
  redis:
    image: 'redis:alpine'
    ports:
      - 6379:6379
  api:
    depends_on:
      - redis

Step 2: Install Required Packages
Install the necessary packages by updating the package.json file:

"dependencies": {
  "ioredis": "^5.3.2",
  "nestjs-throttler-storage-redis": "^0.3.3"
}

Run the command npm install to install the packages.

Step 3: Implement API Throttling in NestJS
In the app.module.ts file, update the imports and configuration:


import { ThrottlerStorageRedisService } from 'nestjs-throttler-storage-redis';
import Redis from 'ioredis';

@Module({
  imports: [
    // Other imports...


   ThrottlerModule.forRoot({
      ttl: 60,
      limit: 60,
      storage: new ThrottlerStorageRedisService(new Redis('redis://redis')),
    }),

  ],
  // Other module properties...
})

We configure the ThrottlerModule with the desired ttl (time to live) and limit values. the above means we allow 60 requests in 60 seconds.

The connection URL redis://redis consists of two parts. The first part, redis://, specifies the Redis protocol. It indicates that the connection is being made to a Redis server. The second part, redis, refers to the hostname of the redis service defined in the Docker Compose configuration.

Enjoyed this deep dive?* Consider buying me a coffee ☕ on Superprofile to support more independent technical writing.

DEV Community: ICraftCode

System Design - Building an Experiment Service

Vocabulary

Requirements

API design

POST /clients — sign up

POST /experiments — configure an experiment

GET /assignment — the hot path

POST /events — record an exposure or conversion

GET /results — reporting

High-level design

Design deep dive: the assignment API — sticky and deterministic

Design deep dive: idempotency and duplicate prevention

Data model (low-level design)

Scaling: where the real system design happens

Caching

Message queues, for the write path

Read replicas

Partitioning

Load balancing

Rate limiting, for multi-tenant fairness

Observability

Closing thought

Coffee?

Architecture Decisions Behind Building a Simple Personal Software Tool

The Idea

Tech Stack

Mobile Versions

Synchronization

Backwards Compatibility

Packaging

Closing Thoughts

Coffee?

Solving the Zombie Row Problem: A Deep Dive into React State Management

⚠️ A Confession Before We Begin

📖 What We'll Cover

🧟 Chapter 1: The Problem (The "Zombie Row")

The Backend Perspective

The Scenario

The Bug: The Zombie Row

Why Did This Happen?

The Real-World Impact

⚙️ Chapter 2: The Infrastructure (Understanding the Stack)

🏗️ The Data Flow Architecture

1. GraphQL with Relay-Style Connections

2. Remix: The Server-Client Bridge

Loaders (Read Operations)

Actions (Write Operations)

useFetcher (The Communication Robot)

3. React Component Architecture

🧰 Chapter 3: The Toolbox (React Hooks Explained)

🪝 1. useState (The State Box)

🪝 2. useEffect (The Side-Effect Runner)

🪝 3. useRef (The Persistent Box)

🪝 4. useMemo (The Cached Calculation)

🪝 5. useCallback (The Cached Function)

🪝 6. useFetcher (Remix-Specific)

⚔️ Chapter 4: The Battlefield (Failed Attempts)

Attempt #1: Optimistic UI with Intents (❌ Failed)

Understanding "Intent" Pattern

What is an Intent?

Understanding "Optimistic UI"

Understanding Common UI Component Patterns

Modal/Dialog Component Pattern

Table Component Pattern

Toast/Notification Component Pattern

My First Attempt: Intent-Based Optimistic Delete

What I Expected to Happen

What Actually Happened (The Bug)

Why It Failed: The Fetcher Lifecycle

Additional Problems I Encountered

Problem 1: The "Flicker"

Problem 2: Load More Confusion

Problem 3: Multiple Rapid Deletes

The Lessons I Learned

Attempt #2: The "Ref Jungle" (❌ Still Broken)

Understanding the Problem I Was Trying to Solve

Understanding useEffect Dependency Pitfalls

My Solution: The Ref Locks

What I Expected

`POST /clients` — sign up

`POST /experiments` — configure an experiment

`GET /assignment` — the hot path

`POST /events` — record an exposure or conversion

`GET /results` — reporting

Understanding `useEffect` Dependency Pitfalls

Understanding `useMemo` in This Context

Why This Works: The Magic of `renderRow`