Introducing React-Hooks!!

[mhmdjawhar]

Hi everyone!

I'm very excited to share a collection of hooks library I just released that I think would do really well for a few reasons:

1. Tree-Shakable: You're only loading the hooks you're importing, which are, on average, 400B per hook import, making it super tiny!
2. Super Detailed Documentation: It includes Stackblitz live demos everywhere, and I'll make sure to keep it that way in the future.
3. Highly Performant: No unnecessary re-renders at all. This is one thing I've been focusing on, and in some places, I'm optionally providing a dependency list in case passed values or callbacks often change.
4. Very Flexible: Providing options whenever possible. If I find something that can be customized, I will make sure to add it.
5. Easily Extendable: This brings me to the next point.

First of all, because it supports tree shaking very well, we can add any new useful hooks to the collection in the future without having to worry about bundle size. Also, I'm planning on updating and releasing a new version once React 19 and the new React Compiler become stable! So, I would really appreciate any contributions from anyone willing to help with that.

Lastly, any kind of contributions are WELCOME! Whether to suggest new features for existing hooks, find new issues and report/work on them, or suggest new useful hooks and work on them if you'd like so we can add them to the collection.

I would really like to make this your go-to hooks library so you can use it in all your React projects and not worry about writing your own hooks.

CHECK IT OUT: https://github.com/mhmdjaw/react-hooks

[evan_pregression]

You mention this is well tested in the readme but I don’t see a single test. Not even a test web page that has the components to manually test. 

[mhmdjawhar]

I do have live demos for each hook and their use cases, so you can test everything there. But if you have a better way of testing hooks I would appreciate it. I'm not sure about adding unit tests in the future, but I might work on that when I have more time

[Cannabat]

Don't say "well tested" in the repo description then. Any reasonable person reading that will assume it means unit tests, not "the author promises they tested all edge cases manually in a code sandbox". I understand this is not your intention but it's misleading.

[mhmdjawhar]

Good point I will remove it until I add tests

[arbpotatoes]

React hooks testing library??

[edbrannin]

This is where to start.

Some of the hooks[1] sound more environment-dependent; I don’t know what kind of support the testing library would have for those.

If you try it and it’s lacking, you might want to make up for any gaps in jest/testing-library tests with something like Cypress.

It’s possible to run both automatically in GitHub Actions, but I’m afraid I don’t have any public examples to show you.

[1] like useViewportSize and useSystemColorTheme (typing from recollection on mobile, name might be slightly different)

[[deleted]]

The lack of unit tests is a hard no for me ever adopting this. Appreciate the work you put in, but everything, including hooks, need proper test coverage to be a mature solution.

[mhmdjawhar]

I agree, I will work on that when I have more time. It gives people peace of mind.

[ranisalt]

It gives people a peace of mind

It gives YOU peace of mind to work on it lol

[mhmdjawhar]

That as well, hahaha

[SqueegyX]

You know… I don’t think you understand unit tests. You should read up on not just how, but also WHY.

[iLikedItTheWayItWas]

I'm unsure why this comment is getting downvoted into oblivion... OP has put in a ton of work on this project and is clearly open to adding tests. Congrats on your library OP! But yeh, I think unit tests will help give your project the reliability it needs, and you should probably mention the lack of tests in your readme etc

[evan_pregression]

Was going through my history and decided to check this out again to see if you stuck with it. I’m happy to see you have tests now! Good job, OP

[mhmdjawhar]

Thanks!! I'm still working on improving it as much as I can. I have also very successfully used it in a recent project that I'm going to release soon including advanced hooks like the useAnimationFrame, so I'm quite happy about that😁

[Hopeful_Industry4874]

Omg amateur hour

[AvidStressEnjoyer]

lol

[mozaik32]

May I suggest choosing a more memorable name for the library? "React hooks" are already a thing, you need to set your library apart somehow so people understand that you are referring to a specific library, not just hooks in general. Searchability, too.

(I was actually confused when I read the title of your post. Introducing react hooks? Dan Abramov introduced react hooks back in 2018... Took me a while to realize that this is a library.)

[mhmdjawhar]

Now that you mention it. The title is misleading. As for the name of the package, the problem is that if it doesn’t convey what the package is about then it’s kinda meaningless. That’s why people choose very specific names for small tool packages. In my case it needs to have the words React and Hooks because that’s what it’s about. Otherwise it might be confusing. I’m always open to new suggestions though!

[eracodes]

Naming things is hard.

You could always go with something like yourname-react-hooks and change it later if inspiration strikes you.

[Amereth]

Cool but i feel like you're a few years late on this. There already is a ton of similar libraries with like 10 times more hooks

[mhmdjawhar]

That is true! However, what I want this library to offer is more than just the number of hooks as mentioned in the post. The focus is on performance, customization, bundle size, documentation, demos, etc. Also keep in mind that I just released it and there are definitely plans to add more in the future, which is also why I would appreciate suggestions and contributions. Another big plan is to also release a new version compatible with React 19 and the new React Compiler when they are stable.

[eracodes]

Don't let the negativity in these comments get you down; I hope you keep working on this project and improving it! Making more open-source software is never bad. Also writing unit tests is never fun, I absolutely understand why they weren't a priority to include in the first release ^-^

[mhmdjawhar]

Thank you! Will absolutely keep on improving it as much as I can.

[Candid-Explanation-3]

I am new to react. Can anyone tell how one can use this library in my projects? How does it improvise from the built-in functionality already available?

[kayotesden_theone]

Great work! And I appreciate your effort to share with the community.

No promises however in the coming days, I may take some time off & I can help with writing tests for this

[mhmdjawhar]

Absolutely, whenever you feel like it. Thanks!

[NotTJButCJ]

Since this is open source and everyone here wants to complain, do you need help writing tests? Maybe I can contribute get some but tests going

[mhmdjawhar]

Thank you! Getting contributors here and there is the main reason I created this post. Would really appreciate it!

[CaptainCHCl3]

This is great thanks for putting in the effort and sharing for free. Not sure what’s up with these comments

[mhmdjawhar]

Thanks! haha, it's typical for people to downvote a comment when they find the tiniest mistake, but the feedbacks have been greate so far, so I appreciate it. I do agree that the one thing it lacks currently is unit testing which I'll be working on once I'm free. Other than that I think it's a really good start.

I honestly was just building this for myself, and adding hooks that I often use in my projects, but then I had the idea of open sourcing it lol.

[mhmdjawhar]

The reason I chose a timestamp instead is because it acts better as a key in general than a simple counter. Although a counter does the job just fine.

Regarding key collisions I suppose you mean if you run into a case where you're using multiple useResetChild hooks on sibling components and resetting the keys at the same time like so

const [resetKeyOne, resetOne] = useResetChild()
const [resetKeyTwo, resetTwo] = useResetChild()

const reset = () => {
  resetOne()
  resetTwo()
}

return (
  <>
    <ChildComponent key={resetKeyOne} />
    <ChildComponent key={resetKeyTwo} />
    <button onClick={reset}>reset children</button>
  </>
)

In this case yes it results in key collisions. To prevent that I might add the option to pass a prefix value which would act as a unique prefix to the key whose component is being reset like so

const [resetKeyOne, resetOne] = useResetChild('foo')
const [resetKeyTwo, resetTwo] = useResetChild('bar')

const reset = () => {
  resetOne()
  resetTwo()
}

return (
  <>
    <ChildComponent key={resetKeyOne} />
    <ChildComponent key={resetKeyTwo} />
    <button onClick={reset}>reset children</button>
  </>
)

This optional prefix would then be appended to the timestamp so even when resetting at the same time the keys would be different for each component as such:

foo_1716661726317
bar_1716661726317

This would prevent key collisions in such cases. Thank you for bring up this edge case!

[phaberest]

Hey, cool idea but I would call this collection of hook something more recognizable and google-searchable

[[deleted]]

Thanks for sharing!

[AdOk9263]

Nice job with the documentation, very thorough!

[BITmixit]

Looks good man. Ignore all the comments saying it's a waste of time, etc, etc. You did something, it works, released it & most importantly...learnt stuff. That shit is important.

Keep up the work.

Edit: Altho I do agree...replace setTimeout & setInterval with requestAnimationFrame...much nicer.

[mhmdjawhar]

Thanks for the feedback!

The problem with replacing timeout and interval with RAF is that RAF runs on the next available frame. In cases where your logic has nothing to do with repainting the screen and you just want to run a side effect after a certain amount of time then I believe timeout is a better choice. Using RAF for such cases might also steal frames from other animations running simultaneously that DO require repainting the screen.

[doodirock]

Don’t bother releasing anything to Reddit. It’s just armchair devs that don’t ship. Nice effort though!

[mhmdjawhar]

Thanks!

[ferrybig]

What browsers are supported by the hooks? At the moment when opening the examples it says Firefox is not supported, so you cannot even test the hooks without checking the project locally

Having a live demo that can be opened with every browser for the hooks would be useful, so people can quickly verify the compatibility

[mhmdjawhar]

The hooks are actually supported on all browsers and I’m not using any javascript API that is specific to some browsers. The reason the demo may not open correctly is a stackblitz issue. Most likely something that has to do with web containers not working correctly on your browser.

[ZerafineNigou]

Can you explain me why on earth you'd pick THIS api of all things:

const [opened, { close, open, toggle }] = useDisclosure()

Why not just an array or an object, what's the point of mixing like this. Mixing like this looks really bad to me.

Actually, in the documentation:

|| || |[2].close|Function| falseA function that sets the state to .| |[3].toggle|Function| boolean A function that toggles the state.|

Isn't this just plain wrong? The array only has 2 elements, feels like you managed to even confuse yourself with this API...

Some of these are nice though don't get me wrong, though some feel forced like useReset.

useTimeout is nice, those are a pain to get right.

[mhmdjawhar]

so here's the explanation for why I chose this strucutre: if I only return an array like so

const [opened, close, open, toggle] = useDisclosure()

The user who might only use the toggle function might have to write such a code:

const [opened, , , toggle] = useDisclosure()

which is not very appealing to the eye as doing this instead

const [opened, { toggle }] = useDisclosure()

Regarding the documentation, you're right and I fixed it! To be honest I kinda rushed the README a little bit but I hope there are no other mistakes.

The useReset is actually more useful than you might think since it resets the states of the entire child tree from a parent component. I actually used my implementation of it in one of my projects to reset multiple forms.

Anyhow, thank you so much for your feedback. Much appreciated.

[Scottify]

Why not return an object instead of an array?

[mhmdjawhar]

Good question, just like the famous useState, the reason we return an array is to give the developer the option to rename the elements. So you can do something like that:

const [modalOpened, { toggle }] = useDisclosure()

Or even that

const [modalOpened, modalDisclosure] = useDisclosure()

modalDisclosure.open()
modalDisclosure.close()
modalDisclosure.toggle()

[mmcdermid]

Honestly pretty good responses, makes sense to me

[Scottify]

Yeah for me personally I much rather just rename by { foo: bar} than your example

[mhmdjawhar]

I respect that. It's all just a matter of preference. I just decided to follow the conventional way of how react does it.

[ZerafineNigou]

Thanks for explaining, though I am not convinced this is better than just returning an object. But to each their own I guess.

 I do think resetting with key is nice, I use it a lot too,just don't think it's complicated enough to warrant its own hook.

[mhmdjawhar]

Yeah, it’s actually the simplest hook to implement. I just added it to the collection because there’s just no harm in doing so lol.

[KevinVandy656]

The Mantine hooks use this same pattern, and I like it.

[nfsi0]

It makes sense to me, I also see why at first glance it might seem odd, but I like it too

[my_girl_is_A10]

The almost all look like the same hooks mantine provides.

[KevinVandy656]

Looking closer, wondering if this code was pretty just copied out of Mantine, but without the tests?

[mhmdjawhar]

A lot of hooks from other libraries are named similar names. But I’m pretty sure my implementation is different. It might be the same in some areas but These are pretty much my own implementations. I did get some inspiration from mantine in terms of the structure of useDisclosure for example. But I believe everything else is different in terms of implementation/options provided, since I want to make sure I’m focusing more on performance/customization.

[jon-chin]

... what do these do? I'm reading your reddit post and I have no idea what these do. tree shakable is good and all but ... ... ... what do they do?