UseHooks – A Collection of Server Component Safe React Hooks
usehooks.comI think it's great to have a repo of all the hooks, but I wonder if implementing each from scratch is the right approach. For example, there is an exceptional useDebounce package [0] that handles many more cases than the simplified one on UseHooks, and I think it could be even more useful to highlight exceptional work that has already been done and maintained in the community rather than in-housing everything. I also think there is more potential in that approach to further React as a whole as the community converges on agreed-upon utilities that become so integral to the way people write and discuss code they make it into the core library.
I don’t want to pull in one package for every little piece of functionality. I prefer a package, that includes a bigger set of hooks that I can use. For example like date-fns for date/time.
I agree with you. We will actually start playing around with use hooks. One package that has multiple utilities maintained by one entity is great. When you have multiple dependencies from multiple entities in your code, the surface area for supply chain attack is larger.
It's not just about supply chain attacks. It's also about convenience and practicality. After a few months or years there will be some major dependency version updates to do, and often there is some manual work associated with that. Maybe reading changelogs and documentation, or checking if the package is still maintained and looking for alternatives. Doing that for 5 packages is reasonable, doing it for 20 or 30 packages is a liability.
I agree with you
This. In combination with tree shaking, I think this approach covers most of the use cases.
Some companies have strict policies on adding new dependencies to an existing project (no matter how small), so packages like this provides tens of hooks with the effort of a single arguing session about one dependency. It's very useful for those cases.
That's good feedback. Thank you.
Hi everyone!
You old heads may remember the original usehooks. It was built when hooks were first released in 2019. We just rebuilt it from scratch, added about 40 more hooks, made it compliant with Server Components, and launched it as a standalone lib.
Hope you all enjoy!
Was this inspired at all by VueUse? After the windicss/tailwind and Remix/Next.js scuffles it's become clear that it's good to get acknowledgement.
Either way, I hope it's as well documented and well maintained as VueUse. That has been pretty sweet. I wanted something like it for React a few months ago and useHooks was the closest thing I found but not nearly as good. Hopefully this relaunch will be.
I've never heard of VueUse (though I'm sure it's great). The original useHooks was released in January of 2019.
Yeah, I figured useHooks was created without knowing about VueUse, but thought the useHooks maintainer(s) might have become aware of it sense then. It makes sense, because though the code is heading in the direction of VueUse in terms of being maintained and well rounded, the structure of useHooks is quite a bit different. VueUse has the code alongside the Markdown: https://github.com/vueuse/vueuse/tree/main/packages/integrat...
Are all the hooks on the site made by ui.dev?
It'd be great if each hook linked to the Github code for that hook, as the first thing I thought of was (a) what is the hook doing, and (b) is it easier to adapt my existing hook and reduce the number of dependencies I have to track?
Good feedback. Yes they're all up on Github – https://github.com/uidotdev/usehooks
I haven't tried the package yet, but at first glance it is missing the .d.ts file. Is this package type safe?
Left another main comment, however you may not see it, where is useLocalStorage implementation for example?
I see "MIT" in package.json - could you add a proper license file to the repo?
Missed that. Thank you. https://github.com/uidotdev/usehooks/blob/main/LICENSE
Nicely done!
Dumb question, but as someone who is aware of server components but hasn't used it, what makes a hook “server component safe”? I assume it doesn't necessarily mean that you can use it on the server (e.g. useMouse), but that if you use it it will not break server-side rendering or complain about a DOM diff?
Not a dumb question. I think calling any hooks server component safe is going to mislead and add confusion to a lot of developers for this very new tech. Hooks are not allowed in server components. This library is SSR safe which has been a concern since before server components were ever a thing.
Yeah it's [poor phrasing](https://twitter.com/tylermcginnis/status/1663648010558132224) on our part. How it's being interpreted vs how I thought it would be interpreted are different. We'll update it.
I don't blame you for this. The React team recently talking about "React Server Components" as though most React users are running it on NodeJS backends and introducing magic "use client" strings is putting everyone in a confused position and I don't think there's a good phrasing for you.
Something like "compatible for server-side rendering in non react server components" :)
And people suggest juniors to start on the front-end because it's less complicated...
I've read "Server component safe" and thought that doesn't make sense from the get go. It's 100% only bad communication here
How telling is it that a basic core function like useFetch has a warning that it “depends on React’s experimental useEffectEvent”?
Almost a decade later and simple data fetching is still an unsolved “problem” in React land.
react is a rendering engine, not a framework; there is no opinionated way to fetch data.
react-query is a delightful library that has made data fetching/cacheing a breeze for me - https://tanstack.com/query/v3/docs/react/overview
That ceased to be true long ago. How do you use native fetch() with a functional component achieving correct/expected behaviour? It’s not possible without buying into react’s [very opinionated] hooks.
In fact, the toolbox this whole HN entry is about is a great example of how React is not just a rendering engine. It wouldn’t even be necessary otherwise. Peek at the code and what you’ll see is intense use of a DSL and built-in methods provided by React, to wrap native APIs that are otherwise usable without any wrappers.
I’m also a happy user of react-query, but it uses the same underlying hooks which are a moving target.
I'm quite experienced with React itself (and have given RSC a spin more recently) - but I've been trying to understand, aside from using a top-level `await fetch` in a server component, is there a possible route to implementing this in client components themselves? Without using a useEffect to call the fetch and populate state with a DIY / ReactQuery style error/loading/component, that is.
My understand was previously that it wasn't really feasible, but seeing the RSC additions (as well as Next's own explorations into calling Server-side code from client components) I was wondering if it wasn't just avoided to go the route away from hooks since they're such a large 'caveat' already that it's only worth doubling down on them.
This may very well change. I won't be surprised to see react have to become more opinionated about days fetching now that they are dancing between client and server with some form of an rpc.
For performance and security I could see them pushing for all data loading to be done on the server, complete with helpers and server-only hooks for fetching and streaming data from the server.
> This may very well change. I won't be surprised to see react have to become more opinionated about days fetching
This is already happening, as I understand it they're even going as far as monkey-patching the Fetch API: https://nextjs.org/docs/app/building-your-application/data-f...
(But maybe let's leave discussion on that particular approach to different posts, we're going off-topic enough as it is.)
The problem of data fetching is basically the problem of caching, famously one of the two hardest problems in computer science.
Whats the other one ?
naming things and off-by-one errors
naming things
I guess you are thinking that because it has a simple name on the website, "useFetch", that it's some sort of canonical http client for React, but it's not.
The only thing it telegraphs is that the ui.dev people built an http client hook (with opinionated features like caching) that uses cutting edge features to do things that people are already doing in React without experimental features.
It’s not “unsolved” - it’s just mostly left to the massive number of third-party data-fetching solutions built on top of React.
How does this suggest, in any way, that fetching is an “unsolved problem” in “React land”?
I can’t seem to even find useFetch in the source….
It's not ideal, but on the website if you open the sources you can search for them (You'll need to click on the hook first so it loads the demo). However they're not typed of course. On Chromium it's just control+p then useFetch and you should see it.
How do these compare with the current heavyweight library?
From what I've been able to tell, that lib is unmaintained and one of the original authors left and created this – https://github.com/react-hookz/web.
A lot of older hook libs "break the rules" of React by doing some weird stuff like silencing useEffects deps array, reading refs in render, etc. We tried to avoid that so useHooks will be future proof.
I saw `useDebounce` and thought "what the hell does debounce have anything to do with react render cycle?". When I check the code, `useDebounce` does... I don't even know what it does, delayed set state?
https://github.com/uidotdev/usehooks/blob/380e83fa267157832e...
If you have state that changes too quickly (like the value of an input field), then you can use `useDebounce` to derive a state that only changes every `n` milliseconds.
Nice, thank you. It was only the other day I was copy and pasting from the old site. Looking forward to installing the lib and deleting some code.
That old site was rough . Hopefully this one is a much better experience for you.
I don't know if I'm being silly, but I'm trying to find the source behind useLocalStorage
https://usehooks.com/uselocalstorage
On their main website Nada, within the github, searching for it only turns up the docs implementation and not the actual source?
It’s in the experimental branch - https://github.com/uidotdev/usehooks/blob/d7483140ee803826c3...
looks like it's in the experimental branch https://github.com/uidotdev/usehooks/blob/experimental/index...
The landing page has 'useFetch' in the list but they're actually in the experimental branch. I personally think they should be removed from the landing page or somehow marked to let the users know they're only available at the experimental release.
I don’t understand why this should be distributed as a package of many hooks.
Unless if a hook is unusually complicated, I much rather copy-paste it into my code.
You should really share the implementations of each of them on the website. I don’t want to pull in 100 hooks just because I don’t want to write 1 from scratch.
Copy/pasting is fine. You do you. https://github.com/uidotdev/usehooks/blob/main/index.js
I understand the source is available. I’m saying I would enjoy seeing the source on the website as I browse it. Much easier to search up on Google that way.
You realize that is a website you can browse. Having it on another domain doesn't make your search easier on google.
Actually, the repository has an MIT license. You can't copy/paste them without also including the license file.
I think that boat has sailed with javascript. I don't understand why leftpad is a module but much of the community disagrees with me on that.
I like how TailwindUI does it. Provides nice examples/source code and easy to copy/paste
Does this work with React-Native? Hard to tell from a quick scan
I strongly dislike having to think about the color of functions while I’m programming. I want the type system to know
Are you referring to this https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...?
Yeah vaguely