31–40 of 62 posts
How do these compare with the current heavyweight library? https://github.com/streamich/react-use
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.
Earlier quoted context omitted.
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.
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
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.
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.
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.
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.
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…
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
Earlier quoted context omitted.
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
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.