Case study
useThisHook
AuthorTyped React hooks you can drop into any app
2026–Present · Open Source · React · Developer Tools
Screenshots
useThisHook in the wild
useThisHook docs — typed hooks with live previews and API reference
useConfirm — await a yes/no dialog from a click handler
The choice
Copy the same hooks — or publish a library?
Every React app needs the same helpers: toggles, debounce, dialogs, local storage. I had to decide how to share them without slowing the apps that use them.
The easy option
- Copy the same toggle and debounce code into every project
- Install a popular hook kit that also installs extra libraries
- Worry about Next.js and bundle size after the API felt nice
What I chose
- Publish hooks that only need React — nothing else at runtime
- Let you import one hook without pulling in the other thirty-one
- Make every hook safe to run on the server, then connect to the browser after load
In short
If you only need one hook, your app should not pay for the rest.
What I checked first
Does install add extra libraries?
The package should not bring lodash, date tools, or other code the app did not ask for.
Can you import just one hook?
Unused hooks must stay out of the bundle. One import should not download the whole library.
Does it work in any React app?
The same import should work in Vite, Next.js, and Module Federation — no special setup.
The problem
Most teams rewrite the same React utilities in every app — toggles, debounce, overlays, local storage, and file pickers — or pull in a hook kit that arrives with lodash, date libraries, and a heavier node_modules than the feature deserves.
Copy-pasted snippets drift. Shared packages that are not tree-shakeable or SSR-safe become a tax on every host: Vite, Next.js, CRA, and Module Federation included.
What I built
useThisHook is an open-source, typed library of custom React hooks you can drop into any app. Thirty-two named, tree-shakeable hooks cover UI, state, forms, lists, overlays, and the browser — published as usethishook with generated TypeScript types and zero runtime dependencies.
Confirm, prompt, overlay, file pick, and step-flow resolve in the click handler — await confirm({ title, danger }) — instead of an effect machine. Put render() in the tree once. That is the overlay contract.
Approach
- React is the only peer. Hooks sit on
useState,useEffect, and browser APIs — no extra runtime package. - Named exports,
sideEffects: false, ESM + CJS +.d.ts. Import one hook; leave the rest out of the bundle. - Window, storage, and observers fall back on the server and subscribe after hydration so the same import works in SSR hosts.
- A live playground documents each hook with preview, API, and a copyable example — the docs site is the product surface.
Tools chosen
- React + TypeScript — the public API is typed at the import. No
@typespackage. No default export. - tsup — ESM, CJS, and declaration files from one build.
- Vitest — hook behavior under test before every commit and publish.
- Vite playground — docs you can try, not only read.
Outcomes
A MIT-licensed package teams can install without inheriting a dependency graph — and a public artifact of how I design reusable frontend foundations: small surface, strict types, and host-agnostic DX.