The stale closure is not React trivia, it is a correctness bug with a five-line fix

A dev.to walkthrough of a React autosave button ends with the UI reporting "saved" while the user's last three words are not saved, because the callback read text captured from the render where the click happened ^[1][2]. That deserves an operator's attention because the same failure mode is latent in every callback that outlives its render: setTimeout and setInterval, code after an await, listeners registered once, IntersectionObserver and ResizeObserver callbacks, WebSocket onmessage, and any third-party SDK that takes a callback at construction time ^[3].

Read the sequence as a timing defect rather than a framework quirk. save() sets status to "saving", awaits an 800 ms api.save call, then sets status to "saved"; the user types three more words while the request is in flight, and those words are neither sent nor flagged ^[1]. The function needs two different values: what it sent, and what the document contains when the promise resolves. A closure can only supply the first ^[4], and no amount of re-rendering rewrites it ^[2].

React's own FAQ answers the stale props and state question with a ref that always holds the latest value ^[5]. The package @reactuses/core ships that as useLatest: five lines, no re-renders, no dependency arrays ^[6]. It returns a MutableRefObject whose .current is the most recently rendered value, and the ref object's identity never changes, so it is safe to close over from a timer, a promise or a subscription ^[7]. The corrected example keeps both readings: a local snapshot for what was sent, and latestText.current === snapshot to choose between "saved" and "dirty" ^[8].

The part worth understanding is where the write happens. useLatest is useRef plus an isomorphic layout effect assigning ref.current = value keyed on [value] ^[9]. react-use and ahooks assign during render instead, which the post concedes works almost all the time ^[10]. The failure case is concurrent rendering: React's rules require render to be pure and forbid reading or writing ref.current during it, because a render can be started, paused and thrown away without committing, leaving a ref holding a value no committed UI ever showed ^[11]. A layout effect updates the ref exactly once per committed render, synchronously after the DOM update and before the browser paints ^[12]. A passive useEffect is not equivalent, per the post: passive effects run after paint, and within a commit React runs children's effects before parents' and earlier hooks before later ones, so another effect in the same commit can read the ref and get the previous render's value ^[14]. The post says the same trick underpins the React useEvent RFC, and that @reactuses/core builds useEvent, useInterval, useTimeoutFn and a dozen other hooks on top of useLatest ^[13], which puts roughly fifteen hooks on five lines of code ^[16].

Two things to watch before adopting it. This is a single post advocating a specific npm package, installed with npm install @reactuses/core ^[15][17], and at five lines the pattern is small enough to vendor rather than take as a dependency ^[6]. The excerpt also promises a comparison with useRef, useEvent and React's useEffectEvent plus "the one rule you must respect" ^[18], then cuts off before stating that rule ^[19]. The mechanical fix is cheap; the review question in your own codebase is which reads want then and which want now ^[20].