ReactUse: A 115-Hook Toolkit for React Browser, State, and Element Work
Project brief: 115+ production-ready React Hooks for sensors, UI, state & browser APIs. Tree-shakable, SSR-safe, TypeScript-first. Used by Shopee, PDD & Ctrip. Inspired by VueUse.
At a glance
- What is it?
- ReactUse (@reactuses/core) is a TypeScript-first, tree-shakable collection of over 115 React hooks for browser APIs, state, elements, and effects, inspired by VueUse and used by Shopee, PDD, and Ctrip. This review covers its architecture, setup, limitations, and alternatives.
- Who is it for?
- Adopt ReactUse if you want a broad, TypeScript-first hook collection for React projects, especially in SSR contexts like Next.js or Remix, and if you value the Unlicense's public-domain terms. Avoid it if you need a minimal dependency or if your team prefers a smaller, more opinionated set of hooks.
- Can I use it commercially?
- Yes. Unlicense is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly MDX, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What ReactUse Actually Solves
ReactUse addresses a recurring problem: React developers rewriting the same logic for browser APIs, UI state, and DOM interactions. Instead of hand-rolling a clipboard hook, a media query listener, or a debounced state, you import a named hook from a single package. The README lists over 115 hooks across categories: Browser (50), State (24), Element (19), Effect (20), and Integrations (1). This is aimed at mid-to-senior React developers who want to move faster without pulling in a dozen separate micro-libraries. The mention of Shopee, PDD, and Ctrip as users suggests it has seen production use in large e-commerce and travel applications, though the README does not specify which hooks those companies rely on. The library is inspired by VueUse, so if you have used that Vue utility collection, the API style will feel familiar.
How the Hooks Are Organized and What That Means
The hook categories show a deliberate structure. Browser hooks cover sensors and APIs like useGeolocation, useNetwork, useSpeechRecognition, and useWebNotification. State hooks handle common patterns: useToggle, useDebounce, useThrottle, and storage sync with useLocalStorage and useSessionStorage. Element hooks deal with DOM measurements and interactions: useElementBounding, useResizeObserver, useClickOutside, and useDraggable. Effect hooks wrap lifecycle and timing: useMount, useUnmount, useInterval, and useRafFn. This organization mirrors VueUse's own taxonomy, which means developers coming from Vue will find a familiar layout. The grouping is not just for show; it helps you guess where a hook lives. For example, if you need a hook for tracking online status, you look under Browser. That predictability lowers the search cost, but the README only gives a summary list. The full documentation at reactuse.com is where you get the actual API details, and the LLM-friendly docs at /llm.txt are a nod to AI-assisted development.
Installation and First Hook in Two Lines
Getting started is straightforward. The README gives a single install command: npm i @reactuses/core. Then you import a hook by name. The quick start example uses useToggle: const [on, toggle] = useToggle(true); and a button toggles the value. This is a minimal example, but it shows the core pattern: hooks are exported as named exports, and you destructure what you need. The package is tree-shakable, so bundlers like webpack or Rollup should drop unused hooks from the final bundle. TypeScript definitions are included for every hook, which is a strong selling point for type-safe codebases. The SSR compatibility claim is explicit, mentioning Next.js and Remix, but the README does not provide a concrete SSR example. You would need to test hooks like useWindowSize or useLocalStorage in a server-rendered component to confirm they do not throw on the server. The documentation site likely has notes, but the README leaves that verification to you.
MCP Support: A Novel Angle for AI Workflows
A distinctive feature is the MCP (Model Context Protocol) integration. The README shows a JSON configuration for an MCP server: @reactuses/mcp with command npx, args -y @reactuses/mcp@latest, and type stdio. This means you can connect an AI assistant to the hook library, allowing it to discover and suggest hooks based on your queries. The claim is 'AI-powered hook discovery.' This is not a common feature in React hook libraries; neither ahooks nor react-use offers MCP support out of the box. For teams using AI coding tools, this could lower the barrier to finding the right hook. However, the README does not explain what the MCP server actually returns or how it integrates with specific editors. It is a configuration snippet, not a tutorial. You would need to experiment to see if it adds real value or is just a novelty. The existence of a /llm.txt documentation file suggests the project is thinking about machine-readable docs, which aligns with the MCP push.
Licensing and Maintenance: Public Domain and Active Releases
ReactUse is released under the Unlicense, which means it is public domain. That is a permissive license, allowing you to use, modify, and distribute the code without attribution. This is a distinct advantage for commercial projects that want to avoid licensing headaches. The repository shows recent releases: v6.5.5 on 2026-08-20, with v6.5.4 and v6.5.3 just a day before. That indicates active maintenance, with frequent patch updates. The README mentions the project is 'maintained in spare time,' which raises a concern about long-term support. A single maintainer may not respond to issues as fast as a corporate-backed library. The changelog is available at packages/core/changelog.md, but the README does not summarize recent changes. You should check that file to see if any hooks have breaking changes between minor versions. The Unlicense is a double-edged sword: it gives you freedom, but it also means there is no warranty or liability protection, so you own the risk of using the code.
Where ReactUse Falls Short: Limitations and Wrong Use Cases
The biggest limitation is the sheer breadth. With 115+ hooks, the library is large, and even with tree-shaking, you have to learn the API surface. The README groups hooks but does not document each one; you must visit the website for details. That creates a documentation dependency. Another issue is the lack of a dedicated integration hook beyond useQRCode. If you need a hook for a specific third-party library, like a charting or animation library, ReactUse will not cover it. The README lists only one hook under Integrations, which is thin. Also, the SSR claim is not demonstrated. For example, useLocalStorage might need a guard to avoid accessing window during server render. Without a concrete example, you cannot assume it works out of the box. The wrong tool case is when you need a single hook for a narrow purpose; pulling in the entire @reactuses/core package, even with tree-shaking, adds a build dependency that a hand-written 10-line hook could replace. For a tiny project, that overhead might not be worth it.
Alternatives: ahooks and react-use
ReactUse is not the only game in town. The README itself credits streamich/react-use and ahooks as inspirations. react-use is an older, widely used library with a similar goal: a collection of React hooks. The key difference is that react-use has been around longer and has a larger community, but its maintenance has been sporadic. ahooks from Alibaba is another alternative, with a focus on enterprise use and a more opinionated set of hooks, often with Chinese documentation. The approach differs: ahooks tends to have more sophisticated state management hooks, like useRequest for async data fetching, which ReactUse does not appear to have. ReactUse's approach is broader but shallower, covering many browser APIs without deep integrations. If you need a hook for data fetching with request cancellation and polling, ahooks might be a better fit. If you want a minimal set and are comfortable writing your own, react-use might suffice. ReactUse positions itself as a comprehensive middle ground, but you should compare specific hooks you need against these alternatives.
Adoption Decision: What to Verify Before You Commit
Before adopting ReactUse, verify three things. First, check the documentation for the exact hooks you need; the README only lists names, so confirm the API signatures on reactuse.com. Second, test SSR behavior in your framework of choice, especially for hooks that touch the window object. The README claims SSR compatibility, but no example is given, so a quick smoke test in a Next.js or Remix app is wise. Third, review the changelog for recent breaking changes; the frequent releases suggest active evolution. If you are using TypeScript, the full type definitions are a plus, but ensure your TypeScript version is compatible. The Unlicense means you do not need to attribute, but you also get no guarantees. For a production app, the breadth of hooks can save time, but you must be willing to trust the documentation and test edge cases. If you need a hook that is not in the list, you might be better off with a smaller library or a custom solution.
Editorial conclusion
Adopt ReactUse if you want a broad, TypeScript-first hook collection for React projects, especially in SSR contexts like Next.js or Remix, and if you value the Unlicense's public-domain terms. Avoid it if you need a minimal dependency or if your team prefers a smaller, more opinionated set of hooks. Before adopting, verify the exact hooks you need in the documentation, check the changelog for recent API changes, and test SSR behavior in your specific framework. ReactUse's strength is its breadth, but that breadth comes with a learning curve and potential bloat if you import carelessly.
Community notes