[HN Gopher] UseHooks - A Collection of Server Component Safe Rea...
___________________________________________________________________
UseHooks - A Collection of Server Component Safe React Hooks
Author : benadam11
Score : 88 points
Date : 2023-05-30 19:44 UTC (3 hours ago)
(HTM) web link (usehooks.com)
(TXT) w3m dump (usehooks.com)
| paulgb wrote:
| 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?
| terandle wrote:
| 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.
| tylermcginnis wrote:
| Yeah it's [poor phrasing](https://twitter.com/tylermcginnis/s
| tatus/1663648010558132224) on our part. How it's being
| interpreted vs how I thought it would be interpreted are
| different. We'll update it.
| technion wrote:
| 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.
| stephen123 wrote:
| 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.
| ricardobeat wrote:
| 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.
| Vinnl wrote:
| The problem of data fetching is basically the problem of
| caching, famously one of the two hardest problems in computer
| science.
| shmde wrote:
| Whats the other one ?
| toddmatthews wrote:
| naming things
| whatsdoom wrote:
| naming things and off-by-one errors
| toddmatthews wrote:
| 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
| ketzo wrote:
| It's not "unsolved" - it's just mostly left to the massive
| number of third-party data-fetching solutions built _on top of_
| React.
| bottlepalm wrote:
| How do these compare with the current heavyweight library?
|
| https://github.com/streamich/react-use
| tylermcginnis wrote:
| 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.
| tylermcginnis wrote:
| 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!
| tuukkah wrote:
| I see "MIT" in package.json - could you add a proper license
| file to the repo?
| tylermcginnis wrote:
| Missed that. Thank you.
| https://github.com/uidotdev/usehooks/blob/main/LICENSE
| benatkin wrote:
| 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.
| tylermcginnis wrote:
| I've never heard of VueUse (though I'm sure it's great). The
| original useHooks was released in January of 2019.
| benatkin wrote:
| 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/tr
| ee/main/packages/integrat...
| morley wrote:
| 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?
| benadam11 wrote:
| https://github.com/uidotdev/usehooks/blob/main/index.js
| tylermcginnis wrote:
| Good feedback. Yes they're all up on Github -
| https://github.com/uidotdev/usehooks
| ecuaflo wrote:
| 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.
|
| [0] https://github.com/xnimorz/use-debounce
| tylermcginnis wrote:
| That's good feedback. Thank you.
| andix wrote:
| 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.
| sattoshi wrote:
| 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.
| tylermcginnis wrote:
| Copy/pasting is fine. You do you.
| https://github.com/uidotdev/usehooks/blob/main/index.js
| sattoshi wrote:
| 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.
| ipaddr wrote:
| You realize that is a website you can browse. Having it on
| another domain doesn't make your search easier on google.
| technion wrote:
| 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.
___________________________________________________________________
(page generated 2023-05-30 23:00 UTC)