--- title: "changelog" description: "Changelog for @reactuses/core — release notes and version history for the ReactUse collection of 110+ React hooks." canonical: https://reactuse.com/changelog/ --- # ChangeLog ## 6.5.9(Sep 17, 2026) - fix(useMobileLandscape): use an ASCII pipe in the user-agent regex. The alternation between `Android` and `iphone` was written with a fullwidth vertical line (U+FF5C) rather than `|`, so the two alternatives were one literal string that no user agent contains. An Android user agent without a `Mobi` token — a tablet — was therefore never detected as mobile, and the hook reported landscape only for the `Mobi` case it happened to match. Thanks to @rawsun007 (#228) - fix(useTextDirection): read the element's direction on the first render. `initialValue` was destructured with a default of `'ltr'`, so the `initialValue !== undefined` guard above it was always true and both the branch that reads the target element's `dir` and the server-side warning below it were unreachable. Every first render reported `ltr` and the effect corrected it afterwards, so a document with `dir="rtl"` rendered `ltr` once before settling, and server markup claimed `ltr` for a direction the hook had never read. The element now wins, falling back to `initialValue` and then `'ltr'` — what the unreachable branch already did. Two consequences worth knowing: `initialValue` is a fallback rather than an initial value now, and is documented as such; and the SSR warning is live again, so an app that server-renders without `initialValue` is told to set it instead of silently hydrating against a direction the server could not see. Adds `useTextDirection/index.spec.ts` — five tests, two of which fail on 6.5.8. Thanks to @rawsun007 (#230) ## 6.5.8(Sep 15, 2026) - docs(readme): show the sponsors on the npm package page. The README that ships inside the package had fallen behind the repository one and carried neither the Special Sponsors wall nor the sponsor badge, so npmjs.com showed no sponsors at all. It now has the same Sponsors section, badge and "Support ReactUse" closing as the GitHub README. No code changes ## 6.5.7(Sep 15, 2026) - fix(useObjectUrl): revoke the URLs it creates. The cleanup read `url` from the render closure, which belongs to the render before `setUrl` applied, so it was always `undefined` there and nothing was ever revoked: every object URL the hook created leaked for the lifetime of the page — on unmount and on every change of `object` — although the docs promised the opposite. The created URL is now held in a local `const` for the cleanup to release, and the hook returns `undefined` again once the object goes away instead of the URL of an object it no longer has. The argument is also typed as optional now (`object?: Blob | MediaSource`), so the documented `useObjectUrl(file)` with `file` from `useState()` typechecks. Adds `useObjectUrl/index.spec.ts` — five tests, three of which fail on 6.5.6. Thanks to @rawsun007 (#226) - fix(useKeyModifier): detach the listeners and follow a changed modifier. The four `document` listeners were registered through `useMount`, which discards the callback's return value, so their cleanup never ran — and even called directly it passed freshly built arrow functions to `removeEventListener`, which matches by reference. Every mount left four more listeners on `document`, each calling `setState` on an unmounted component whenever a key or button was pressed. `useMount`'s empty dependency list also froze the arguments, so going from `useKeyModifier('Shift')` to `useKeyModifier('Control')` kept reporting Shift, and the same held for `events`. Now registered in a `useDeepCompareEffect` keyed on `[modifier, events]` with one hoisted handler, the shape `useEventListener` already uses. Adds `useKeyModifier/index.spec.ts` — seven tests, three of which fail on 6.5.6. Thanks to @rawsun007 (#223) - fix(useDoubleClick): keep the click count across renders and cancel the timer. `handle(...)` ran during render, so the `let count = 0` inside it was rebuilt on every render while `useEventListener` dispatched to the newest closure: a re-render between two clicks reset the count and both reported as single clicks. The `setTimeout` id was never stored either, so nothing could cancel it and the callback ran after unmount. Count and timer now live in a ref, one pair per event type so `click` and `touchend` stay independent; only the first click arms a timer, the teardown clears it, the count is reset before the callbacks run so a throwing callback cannot wedge the hook, and both callbacks go through `useLatest`. Spec grown from a placeholder to twelve tests, five of which fail on 6.5.6. Thanks to @rawsun007 (#224) - fix(useMousePressed): attach the `touch` and `drag` listeners to a ref target. The target was resolved during render, where a ref handed to a child is still `null`, and the effect depended on that resolved element so it never re-ran to pick it up — with the usual `useRef(null)` pattern those listeners were never attached at all, while `mousedown` worked because it goes through `useEventListener`. The target now resolves inside the effect, keyed on `useStableTarget`. `onPressed` was also curried, so the add and the remove received different functions and `dragstart` and `touchstart` were never detached; there is one stable handler each now. Adds `useMousePressed/index.spec.ts` — six tests, two of which fail on 6.5.6. Thanks to @rawsun007 (#225) ## 6.5.6(Sep 7, 2026) - fix(useIdle): cancel the timers on unmount. The effect's cleanup removed the event listeners but left both timers running: the idle countdown, which is `ms` long and a minute by default, and the 50ms timer inside the throttled activity handler. The `mounted` flag stopped the state update, so nothing warned — the timers just kept the effect's closure alive until they fired, and `jest.getTimerCount()` still read 1 after unmount. Both are now cancelled in cleanup, matching how `useThrottleFn` and `useDebounceFn` already cancel theirs. The hook gains its first spec file — five tests, two of which fail on 6.5.5. Thanks to @rawsun007 (#222) - fix(useCycleList): derive the next index from the current state. `set` read `index` from the render closure, so two calls in the same batch both computed from the same value and the second overwrote the first — calling `next()` twice in one handler advanced a single step, and `next()` followed by `prev()` did not cancel out. An empty list also made `(index + i) % 0` NaN, which was stored as the index and never recovered. Both now go through the functional updater form, matching `useCounter`, and an empty list leaves the index untouched. Adds `useCycleList/index.spec.ts` — eight tests, three of which fail on 6.5.5. Thanks to @rawsun007 (#221) ## 6.5.5(Aug 20, 2026) - fix(useInfiniteScroll): stop firing `onLoadMore` on every render. The load-more effect listed `target` in its dependencies, and a getter target such as `() => element` — one of the documented `BasicTarget` forms — is a new function on every render, so the effect re-ran every render and called `onLoadMore` each time. Loading more data appends to state and renders again, so it never settled: three renders produced three loads, against zero for a ref target (the form the docs demo). The target now resolves through `useStableTarget`, so the effect is keyed on the element rather than on the identity of the getter. The hook gains its first spec file — nine tests covering both target forms - fix(useCssVar): stop rebuilding the MutationObserver and the returned setter on every render. `set` and `updateCssVar` were memoised on `[target, prop]`, and the effect that installs the observer depended on both plus `target`, so a getter target invalidated all of them every render. With `observe: true` the observer was disconnected and reconstructed each render — four observers across three renders, against one for a stable element — which both wastes work and leaves a gap where mutations go unseen; and the `set` handed back to callers changed identity every render, invalidating any consumer memo built on it. The target now resolves through `useStableTarget` and the callbacks read it from the ref, so `set` is stable for the hook's lifetime and the observer is built once per element. Spec grown from a stub to eleven tests - fix(useScrollLock): key the lock effect on the element rather than on the getter. Follow-up to the 6.5.4 snapshot fix, which made the effect idempotent but left it re-running on every render whenever `target` was the `() => document.body` getter the docs recommend — re-writing `overflow: hidden` each time, and a trap for anything added to that effect later. `useStableTarget` ties it to the element it actually locks; the element-keyed snapshot stays as the invariant that guarantees one read per lock - chore: audited every hook that accepts a `BasicTarget`. `useEventListener`, `useIntersectionObserver`, `useMutationObserver`, `useResizeObserver` and `useSticky` already resolved theirs through `useStableTarget`; the three above were the only ones depending on a raw target. The rest reach the DOM through `useEventListener`, `useResizeObserver` or `useEvent`, all of which are already stable ## 6.5.4(Aug 20, 2026) - fix(useEventListener): pass the listener options back to `removeEventListener`. Registration called `addEventListener(name, fn, options)` but cleanup called `removeEventListener(name, fn)` with the options dropped, and the DOM matches a listener for removal on (type, callback, capture) — so anything registered with `{ capture: true }` (or the boolean `true` form) was never detached. A capture-phase listener kept firing after the component unmounted, survived a change of `eventName` or `options`, and accumulated one live listener per mount: a modal that intercepts clicks on `document` in the capture phase went on intercepting them for the rest of the session. `passive`, `once` and `{ capture: false }` were unaffected, since only `capture` participates in the removal match. Verified in jsdom and Chrome 151 - fix(useScrollLock): snapshot the original `overflow` once per lock, not on every render. The effect that applies the lock lists `target` in its dependencies, and the `() => document.body` getter the docs recommend for SSR safety is a fresh function on every render, so the effect re-ran constantly and re-executed `initialOverflowRef.current = element.style.overflow`. While locked that reads back the `hidden` the hook itself just wrote, so a single unrelated re-render with the modal open poisoned the saved value: `unlock()` then restored `overflow: hidden` and the page never scrolled again, an existing inline value such as `overlay` was swallowed, and the v6.5.3 unmount cleanup restored the poisoned value too. Only the happy path — lock, then unlock with no render in between — behaved correctly, which is why hand testing never caught it. The snapshot is now keyed on the locked element, so it happens once per lock however often the effect re-runs; if the target moves while locked, the element being released is restored before the new one is captured ## 6.5.3(Aug 19, 2026) - fix(useScrollLock): release the lock when the owning component unmounts. The lock is an inline `overflow: hidden` written onto an element the hook does not own, plus an iOS `touchmove` guard registered with `passive: false`, and neither was ever cleaned up — unmounting while locked (a route change with the modal still open is the common one) left the page permanently unscrollable, and on iOS left a listener attached to `document.body` cancelling every touch scroll for the rest of the session. The hook now restores the exact inline `overflow` it replaced and detaches the guard on unmount, which is the behaviour the docs already promised. Unmounting while unlocked still touches nothing ## 6.5.2(Aug 17, 2026) - fix(useClipboard): work in non-secure contexts, and expose Clipboard API support (#218, #219). `navigator.clipboard` is `undefined` whenever `window.isSecureContext` is false — plain `http://`, LAN IPs, some embedded webviews — so `copy()` rejected and the hook was unusable there. Copying now falls back to a temporary `