Frequently asked questions

@danixsoft/hooks is an open-source React hooks library containing 44 production-ready hooks for state, storage, forms, data fetching, the DOM, timers and device sensors. It has no runtime dependencies, is written in TypeScript, is safe to render on a server, and is released under the MIT licence.

Run npm install @danixsoft/hooks (or pnpm add, yarn add, or bun add). There are no peer dependencies beyond React 18 or later, and no additional @types package to install — the type declarations ship with the library.

Every hook is a named export from the package root, for example: import { useLocalStorage } from '@danixsoft/hooks'. There is no deep-import path to remember; the package is tree-shakeable, so importing from the root is already optimal for bundle size.

No. There is no provider to mount, no context to set up and no build configuration to change. Import a hook and call it.

React 18 and above, including React 19. React is declared as a peer dependency, so your application controls which version is installed and there is no risk of two copies of React ending up in the bundle.

Yes, with both the App Router and the Pages Router. In the App Router, hooks must be called from Client Components, so add the "use client" directive to any file that uses one — the same requirement React places on useState. Every hook is written to render safely during the server pre-render pass.

Yes. The package is framework-agnostic and ships both ES module and CommonJS builds. Anywhere React runs in a browser environment, these hooks run.

Partially. Hooks that use only React primitives — useCounter, useToggle, usePrevious, useInterval, useDebounce and similar — work fine. Hooks that read browser APIs such as localStorage, matchMedia or the Geolocation API do not, because those APIs do not exist in React Native. React Native Web is fully supported.

Hooks by definition require client-side state, so they run in Client Components. Server Components cannot use any hook, including React's own useState. Mark the component that calls a hook with "use client" and keep that boundary as far down the tree as you can.

Only the hooks you import. The package is published as ES modules and marked sideEffects: false, so bundlers drop everything you do not use. A typical hook is well under a kilobyte gzipped, which makes the size of the full package irrelevant to your build.

No. Importing from the package root already tree-shakes correctly with webpack, Vite, Rollup, esbuild and Turbopack. Deep import paths are not supported and are not needed.

Yes. Returned callbacks are wrapped in useCallback or backed by refs so their identity is stable across renders, which means they will not invalidate React.memo, useMemo or effect dependency arrays downstream.

No. Every hook that reads a browser API returns a server-safe value during the initial render and only reads the real value in an effect, which runs exclusively in the browser. That is what guarantees the server HTML and the first client render agree.

Because the server has no window and cannot know the viewport size. Returning undefined until after hydration is what prevents a mismatch. Render a placeholder of the final dimensions while the value is undefined so the swap does not shift your layout.

Because localStorage is only readable after hydration, so the server necessarily renders the default. For a theme, where the flash is very visible, add a small blocking script in the document head that applies the stored value before the first paint. The full technique is documented in our Next.js SSR guide.

Not from this library. Hooks that need synchronous measurement use useIsomorphicLayoutEffect, which resolves to useLayoutEffect in the browser and useEffect on the server.

Yes. The library is released under the MIT licence, which permits commercial use, modification, distribution and private use. There is no paid tier, no usage limit and no attribution requirement beyond retaining the licence notice.

Yes — the MIT licence allows it. The source is on GitHub and each hook is a single self-contained file. If you only need one or two hooks and want no dependency at all, vendoring them is a perfectly reasonable choice.

Open an issue on the GitHub repository. Bug reports are most useful with a minimal reproduction; hook requests are most useful with a description of the problem you are solving rather than a proposed API.

Yes. Check the repository's commit and release history for the current cadence — that is a more reliable signal than any claim on a documentation page.

Yes. The repository accepts pull requests. New hooks should be dependency-free, SSR-safe, fully typed and covered by tests, matching the conventions of the existing hooks.

Yes. The site publishes llms.txt and llms-full.txt, machine-readable summaries containing every hook name, signature and description. Pointing Claude, ChatGPT, Copilot or Cursor at those files means generated code uses the real API rather than invented signatures.

At react-hooks.danixsoft.com/llms.txt for the concise version and react-hooks.danixsoft.com/llms-full.txt for the complete reference including descriptions and examples. Both are plain text and are regenerated from the source on every release.

Paste the llms.txt URL into the conversation, or add it to your project rules file (CLAUDE.md, .cursorrules, or the equivalent). The signatures are generated from the TypeScript source, so they are accurate for the current release.