Older React guidance says you must call e.persist() before using an event inside setTimeout or after an await. What was event pooling, and what is actually true from React 17 onward?

## What pooling actually did Up to React 16, React maintained a pool of SyntheticEvent instances per event type. Dispatching a click took an object from the pool, filled in `target`, `clientX`, and the rest, ran your handlers, and then called an internal release step that set every property back to `null` and returned the object to the pool for the next click. The consequence was that a synthetic event was only valid *during* the synchronous run of your handler: ```js // React 16 behaviour function handleClick(e) { setTimeout(() => { console.log(e.type); // null — the object was recycled }, 0); } ``` In development, React detected reads on a released event and warned: the event is reused for performance reasons and all properties have been nullified. The documented workaround was `e.persist()`, which removed that instance from the pool so it kept its data. This is why so many mid-2010s answers, Stack Overflow posts and course videos still repeat "remember to persist the event." ## Why it was removed React 17 removed pooling entirely. The stated reasoning was that the optimisation did not improve performance on modern browsers — object allocation and GC for a handful of short-lived event objects is cheap — while it created a steady stream of confusing bugs for everyone who touched an event asynchronously. React 19 inherits that removal; nothing has brought pooling back. So in current React: ```js async function handleClick(e) { await save(); console.log(e.type, e.target); // works, no persist() needed } ``` You can also put the event object in state, close over it, pass it to a reducer, or keep it in a ref. It is an ordinary JavaScript object with the ordinary lifetime any object has. ## What happened to persist() `e.persist()` was kept as a callable no-op so that older code and libraries do not crash. Calling it is harmless and pointless. If you are reading code that calls it, that is a fossil, not a requirement. ## The trap that survives: currentTarget Here is the nuance that separates a rehearsed answer from an understood one. Even with pooling gone, this still logs `null`: ```js async function handleClick(e) { await save(); console.log(e.currentTarget); // null } ``` That is **not** React. `currentTarget` is defined by the DOM to be meaningful only while the event is being dispatched — it names the node whose listener is currently running, so once dispatch finishes there is no such node and the browser resets it. The same is true of a plain `addEventListener` handler with no React involved. The fix is to read what you need synchronously and keep the value: ```js async function handleClick(e) { const form = e.currentTarget; // read now const data = new FormData(form); // or extract now await save(data); } ``` `e.target` behaves differently: it points at the node where the interaction originated, and that reference stays valid after dispatch — though the node may since have been unmounted, so treat it as possibly detached. ## How to answer this in an interview The question is really a dating check: it tells the interviewer whether your React knowledge is current or memorised from an old course. The strong answer has three beats — describe what pooling was and why the warning existed, state clearly that React 17 removed it and persist() is now a no-op, and add the currentTarget caveat to show you know which part of the old advice was React's and which part is the DOM's. ## A related habit worth dropping The pooling era also produced defensive code like `const { value } = e.target` at the top of every handler "in case the event goes away." Destructuring the one value you need is still fine style, but do not present it as a necessity — in React 19 it is a preference, not a workaround.