Comment by Kamran Khan on "How to prevent re-renders on deeply nested state objects in React "

Good survey of the standard toolkit. The one I'd add from production experience: all of these fixes are discipline-dependent, and the silent failure modes are what actually hurt. The nastiest one I keep seeing is selector equality in external stores — someone writes a zustand selector that returns a fresh object and wonders why every listener re-renders. The Object.is contract is the real API surface, and it's invisible.

Sharp question on the worker kernel: every write crosses the worker boundary with [path, value] pairs. What's the practical write-throughput ceiling before the message queue itself becomes the bottleneck? For high-frequency data like cursor position, you mention refs on the React side — but the kernel still sees every write, and structured cloning of those messages at 60Hz across a worker boundary is doing a lot of work. Where does that design start to cost more than the re-renders it avoids?

Thanks, and agreed on selector equality. The Object.is contract is invisible until it bites.

On the worker: I haven't measured a throughput ceiling, so I won't guess a number. The demos sidestep the 60 Hz case rather than survive it. Cursor-like data never goes through the kernel; it stays in refs. In the Fan-Out demo the page doesn't stream values to the worker at all: a write is a tiny command, normal writes wait for the reply before the next one is sent, and the stress loop runs entirely inside the worker. Replies are counts plus transferable Uint32Arrays, and the page paints at most 4 times a second, only while visible. Coalescing writes per frame is the next step if a page ever needs to stream values in. Where it starts to cost more: frequent writes that each touch only a few values. There the cloning overhead can outweigh the re-renders it saves, and the kernel belongs on the main thread. I'll benchmark that crossover and add it to the post.

Search Hashnode