React Getting Too Much Data?

This is another DILEMMA interview question.
Fallacy non causa pro causa — implying the cause.
It is not as legendary as the Sliding Window problem,
where only ONE option is clearly true:

• A) Code Warrior; Or,

• B) Whiteboard Warrior.

But it is equally amazing in its own way.
This time — two hackers talking:

What if you get too much data in single page React application?!
> We never do that: it breaches Boundary Contract.
But you have that in production! What can you do about it?
> I can implement an intermediate service to page and not have it happen?
But is there ANYTHING you can do in React to handle the situation?
> Potentially, I’d need to read the manual to see what new is available.
> Importantly: When we find ourselves searching outside framework,
> or component type boundary — we have already committed a mortal sin!

First, I will tell you WHY the interview went this way.
And then I will explain what to do in React to avoid the crisis.

Important Context:
  The interviewee is to raise a highly disciplined team, as many times before.

Breach of Architectural Boundary Contract:

The problem is NOT React having trouble with deeply nested DOM or too much data.

Any Data-Presenting Single-Page Application (SPA) is a Read Model (RM)^[1]
  — a concrete architectural archetype.
Its job is to only present the model to the actor
and never to process data. It must follow:

• Garbage-In — Garbage-Out;

• Read-only, side-effect free — no mutation;

• Declared staleness — a projection;

• Transparent — NO behavior ownership.

Fat SPAs do exist — Figma, spreadsheets, notebooks. Those are a different archetype with a different contract, and a separate article.

And to make good on these, all RM type components offer:

1. Limitations Contract: e.g., DOM object count upper boundary;

2. Service Level Agreement (SLA): durability contract / expectations.

NOTICE: Data concerns are OFF LIMITS — Paging, streaming, sizing are entirely Supplier Accountability: the Supplier presents a render-ready model — that is what makes a Read Model.

So, the only correct answer to:
"What do you do in Production"
    is Crash Loudly!

Figure 1. "Not the owl’s fault."

In fact, I had a massive platform with 56 tenants impose it: awarded the best architecture!

This question was a trap by a fallacy. But what we can do to avoid it is indeed interesting.

Why So Serious?!

Because a boundary contract that bends is not a contract — it is a suggestion.

An evolving team is exactly the team that cannot afford suggestions. Seniors rotate, juniors arrive, and the architecture is the only teacher on duty around the clock. When the Read Model quietly swallows a supplier’s failure, the lesson every new engineer learns is: boundaries are negotiable here. From that day, every component grows its own private coping layer, and in a year nobody can say where any problem actually lives.

Rigid discipline is not bureaucracy — it is how the team stays debuggable. A contract breach that crashes loudly is found in one Sev-One. A contract breach that is gracefully absorbed is found in an archaeology dig.

Defensive SPA with React:

So, this scenario is an architectural failure.
On a disciplined team it’s a Sev-One — highest severity outage,
and somebody is accumulating HR notes.
At least on my teams — core engineering contracts are never to be broken.

As a React / UX developer HOW do you safeguard yourself?!
The problem is not your UX — it’s above you — the Architecture.
Still there is one thing you must do — acknowledge the boundary.

Full disclosure: React is a very small and simple framework one can master, not just learn, over a weekend — in its entirety. And I don’t usually make software in React — I spend 99% of my time retiring React in favor of professional solutions like Ktor / Kotlin that come with a whole different set of limitations and abilities. But my advice here is basic and universal.

React offers the <Profiler> onRender budget hook — there since React 16.9, 2019. Its purpose is not to gracefully recover in production — no, that’s the worst sin one can commit: masking or Band-Aiding another sin. It’s for your local benching and CI/CD pipeline gate. There, I’d be making the largest meanest data frame I am willing to accept and benching myself on that. Up until recently the SLA DOM was small, only about 10,000 objects. That’s okay, it’s a Read Model, not a Jupyter Notebook. If I don’t fit — I might take one look at what’s available in the latest versions. I remember Lazy Evaluation and Partial Render being planned.

Importantly: It really doesn’t fit! This is where you go to Architecture. Problems can ONLY be reasonably solved at their source, not by stretching the wrong tool for the job. Some people might tell you — take a look at better solutions, like Ktor I mentioned earlier. Remember — that too is an Architecture Decision! I typically can — because I usually design from scratch. But if you already have an investment into React and too big of a data frame comes about — the problem is not your React.

Postproduction Update

I looked it up. Every rumor I remembered has landed:

• React.lazy + Suspense — the lazy loading (component code-splitting), in since React 16.6;

• Concurrent rendering — React 18: useTransition and useDeferredValue defer expensive re-renders of big lists off the urgent path;

• <Activity> and Partial Pre-rendering — shipped in React 19.2 — October 2025. <Activity> keeps off-viewport parts rendered-but-deprioritized with state preserved; Partial Pre-rendering serves a static shell early and resumes the render for dynamic data;

• And the classic big-list answer interviewers fish for — windowing / virtualization (react-window and friends) — is userland, NOT React. Which proves the point: the moment you reach for it, you are already outside the framework boundary.

AND REMEMBER! These are just trinkets. Discipline makes us WHOLE.

---

1. The Read Model is one half of Command Query Responsibility Segregation (CQRS): a denormalized projection shaped for presentation. See Martin Fowler’s CQRS and Greg Young’s CQRS Documents.