I 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.
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.
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.
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.
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...
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?
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.
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.
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.
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 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.
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?
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.
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.
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.
[0] https://github.com/xnimorz/use-debounce