Patterns for Real-Time Data

Real-time features are usually added with good intentions: “keep the UI up to date.” A dashboard polls every few seconds. A feed subscribes to a stream. A status badge listens for updates. At first, the system feels alive. But as more real-time sources are added, the UI can become unstable. Lists flicker as new data arrives. Scroll positions jump. Inputs lose focus. A user clicks a button, and midway through the interaction, the screen subtly changes beneath them.

From the developer’s perspective, the data layer looks correct: updates are arriving on time, but the experience feels wrong. A common reaction is to add more control flags: pause updates while typing, debounce renders, memoize aggressively, or move everything into a global store. Those fixes treat real-time as a data-throughput problem, when the real issue is rendering coordination. React is doing exactly what it is told to do: re-render when state changes. The mistake is assuming that new data should always trigger an immediate UI update.

This problem exists because real-time data has a different urgency than user interaction. A click, a keystroke, or a drag must feel immediate. A background update does not. Users do not experience real-time systems as millisecond-accurate; they experience them as stable, predictable, and responsive. When every update is treated as equally urgent, React has less room to prioritize interactions, and the UI becomes noisy.

React 19 provides a missing lever. Instead of choosing between “live” or “not live,” updates can be controlled by when they are allowed to commit and where they are allowed to land. By aligning real-time updates with React’s scheduling model using tools like startTransition, interaction can remain responsive while data synchronizes in the background, and visual updates can commit only when they will not disrupt the user.

The above diagram shows a UI split into three regions. A small live indicator updates immediately as events arrive. A list region prepares updates in the background and commits them when ready. A detail panel remains stable while the user is interacting, only re-rendering when React decides it is safe. All regions read from the same evolving data source, but they commit at different times based on priority.

Using React 19 to schedule real-time updates safely

The first mental shift is to stop treating real-time ...