ReactUse: 115+ Hooks for React, Installed as @reactuses/core

The repeated hook folder ReactUse is trying to delete

Most React codebases end up with a hooks directory that nobody planned. Someone adds a resize listener, someone else adds a debounce, a third person writes a localStorage wrapper, and within a year you have four implementations of the same idea with different cleanup behaviour. ReactUse is a direct answer to that drift: a single package, @reactuses/core, that collects the hooks you would otherwise write yourself.

The README describes it as a collection of 100+ hooks for browser APIs, state management, sensors, animations and DOM elements, inspired by VueUse, and lists categories with counts: Browser at 50 hooks, State at 24, Element at 19, Effect at 20, plus a single Integrations entry, useQRCode. The audience is React application developers who already know how useEffect works and would rather not re-derive useIntersectionObserver for the fifth time. It is not a framework and it does not own your state tree.

Tree-shaking, SSR guards and the monorepo behind @reactuses/core

The mechanism is ordinary ESM, and that is the point. The root package.json sets "sideEffects": false, which tells bundlers that importing one hook will not pull in the rest. The README states the library is tree-shakable and that you import only what you need, so a Vite or webpack build should drop unused hooks rather than shipping the whole collection.

The repository is a pnpm workspace. package.json declares "packageManager": "[email protected]" and the scripts filter into specific packages: build and test both target @reactuses/core, while docs:dev runs a package named website-astro. Top-level entries include packages/, docs/, scripts/ and pnpm-workspace.yaml, so the library, the documentation site and the codegen scripts are separate units. The README also claims SSR compatibility with Next.js and Remix, which matters because hooks like useWindowSize or useMediaQuery touch window during render. The claim is in the feature list; the README does not show the guard, so if you render on the server, verify the specific hook you pick rather than assuming all 115 behave identically.

One more piece of architecture is unusual for a hook library: an MCP server. The README documents @reactuses/mcp, run through npx, for hook discovery from an AI client. That is a distribution decision, not a runtime one, and it does not affect your bundle.

Installing @reactuses/core and using useToggle

Installation is a single npm command. The README gives exactly this:

npm i @reactuses/core

After it completes you have the package in node_modules and can import named hooks from it. The README's quick start uses useToggle, which returns a boolean and a setter function. A minimal component looks like this:

import { useToggle } from "@reactuses/core";

const Demo = () => {
  const [on, toggle] = useToggle(true);
  return <button onClick={toggle}>{on ? "ON" : "OFF"}</button>;
};

The initial value passed to useToggle is true, so the first render shows ON, and clicking the button toggles the label. Nothing here is surprising, which is a fair description of the library's value: the hooks do the obvious thing and you stop maintaining them.

If you want hook discovery rather than reading the site, the README documents an MCP configuration block to add to your client config:

"@reactuses/mcp": {
  "command": "npx",
  "args": ["-y", "@reactuses/mcp@latest"],
  "type": "stdio"
}

That entry runs the MCP package over stdio. It is optional and unrelated to the runtime dependency.

Where ReactUse stops and you still write your own code

The category counts are the honest map of the library's edges. Browser has 50 hooks, Element has 19, Effect has 20, State has 24. Integrations has exactly one: useQRCode. There is no data-fetching category, no query cache, no request deduplication layer. The fetch-adjacent hooks listed are useEventSource and useFetchEventSource, which are server-sent event helpers, not a replacement for a request library.

That is a real boundary. If your application's hard problems are cache invalidation, background refetching and stale-while-revalidate, ReactUse will not solve them and was not built to. You can use it alongside a fetching library without conflict, because it does not intercept your network calls, but do not install it expecting it to become one.

The second limitation is the Unlicense and the maintenance model. The README says the project is "maintained in spare time" and asks for sponsorship, and the package.json license field is Unlicense. Public domain dedication removes the licensing friction but also removes any obligation on anyone to keep a hook working. The last push to the repository was on 2026-08-20, which is recent, so the project is not abandoned; the point is that the maintenance guarantee is sponsorship-funded goodwill, not a support contract. For a hook that wraps a stable browser API, that is usually fine. For a hook wrapping something that changes, read the source.

ReactUse against react-use and ahooks

The README names three inspirations: streamich/react-use, ahooks and VueUse. The difference between them is worth stating precisely.

react-use is the older, larger ancestor, and it is the project most people mean when they type react-use into a search box. ReactUse's stated design goals diverge on two axes: TypeScript-first typing for every hook, and explicit SSR compatibility with Next.js and Remix. If you have an existing react-use dependency in a client-only app, there is no urgent reason to migrate; if you are starting a server-rendered TypeScript project, the SSR claim is the reason to look at ReactUse first.

ahooks comes from Alibaba and is the closest in spirit, since both are large, category-organised collections with production users. The README lists Shopee, PDD and Ctrip as users, and those are the kind of teams ahooks was built for. The practical difference for a reader is scope and packaging: ReactUse ships as @reactuses/core with "sideEffects": false, so the tree-shaking argument is explicit in the manifest. Whichever you pick, the migration cost between them is low, because both expose named hooks that wrap the same browser APIs.

Licence, upgrade cost and what a version bump means here

The repository is Unlicense, and the root package.json repeats that in its license field. Unlicense is a public domain dedication, so it grants the widest possible permission and imposes no attribution requirement. That is a genuine advantage for teams whose legal review stalls on MIT notice files. It also means there is no copyright holder enforcing anything, which is a trade-off rather than a benefit, and it is not legal advice: read LICENSE yourself if your distribution model is unusual.

Upgrade cost depends on which hooks you use. The release history shows rapid patch releases, with v6.5.3, v6.5.4 and v6.5.5 all landing between 2026-08-19 and 2026-08-20. Patch-level churn at that rate suggests small fixes rather than a stable freeze, and the README points to packages/core/changelog.md for details. If you pin a version and read that changelog before bumping, the risk is manageable. If you float the version, you are accepting whatever lands. Note also that the README does not document a deprecation policy for hooks, so a hook you depend on could change semantics in a minor release without a stated removal window.

Editorial conclusion

Adopt ReactUse if you are rebuilding the same useEventListener, useLocalStorage and useIntersectionObserver hooks in every project and want them typed, SSR-guarded and documented in one place. Skip it if you need a data-fetching layer, since the README lists no caching or request-deduplication hook and the fetch-adjacent entries are event-stream helpers. Before adopting, open the source of the two or three hooks you would actually use and check the cleanup path, then read LICENSE to confirm the Unlicense terms suit your distribution.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes