Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

useGlobalState #1119

Closed
jpwallace22 opened this issue Jan 31, 2023 · 6 comments
Closed

useGlobalState #1119

jpwallace22 opened this issue Jan 31, 2023 · 6 comments

Comments

@jpwallace22
Copy link
Contributor

jpwallace22 commented Jan 31, 2023

New Features

I would like to add a useGlobalState hook

What is the new or updated feature that you are suggesting?

Prop drilling is a pain and Context are not only start to get out of hand the way they are nested, but they cause a ton of rerenders and are a pain to configure. I propose a useGlobalState hook that can extend the features of useState, but globally.

function useGlobalState<T>(config: GlobalSateConfig<T>): readonly [T, (stateOrSetter: T) => void]

Why should this feature be included?

So people can seamlessly and easily add a legible and easy to manage state option for global state

🚨 I will implement this hook myself. I just want to run it by the team before I start 🚨

@xobotyi
Copy link
Contributor

xobotyi commented Jan 31, 2023

Why not to leave it to existing libraries?
redux/recoil/there is a ton others..

@jpwallace22
Copy link
Contributor Author

@xobotyi a simple useGlobalState hook will fill the gap between "context hell" and having to add a giant dependency for a couple of pieces of state. In smaller websites it's not unlikely to only need a couple of pieces of global state.

@ArttuOll
Copy link
Contributor

Client-state management libraries generally aren't that big (at least the ones I'm aware of), with the exception of Recoil (79 kB minified). Jotai, Zustand and Redux are all well below 10 kB minified.

In my opinion, useContext + useReducer combination gets you pretty far client-state management-wise. When that's not enough, a dedicated state management library comes into question. I don't think there's a middle ground between those, but let me know if you think I'm mistaken.

Implementing global state management is tricky business and I don't think we should duplicate the efforts those libraries are making. This is the same rationale we used when we decided not to port navigation-related hooks from react-use in #33 and head-element modifying hooks in #1004 .

@jpwallace22
Copy link
Contributor Author

@ArttuOll I guess more than the size of the dependency its the amount that goes into it. Its usually a couple of dependencies and at least a couple files in order to set up basic global state. For smaller websites that don't usually need something so robust, I think its useful. However, it's totally up to yall.

@jpwallace22
Copy link
Contributor Author

After more digging, I feel like you're right. I'm just too used to using Redux and hate it some much. Now that I am looking at other libraries, I would probably just use one of those instead.

@ArttuOll
Copy link
Contributor

ArttuOll commented Feb 2, 2023

Yeah, I feel like Jotai's atoms might be what you want if you only need a couple of pieces global state. Closing this now.

@ArttuOll ArttuOll closed this as completed Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants