I said this in another comment, but similarly to this, check out Redux Toolkit ( https://redux-toolkit.js.org ), the `slices` feature changed my view on Redux entirely. Basically you can have a per-feature slice of functionality rather than having actions, reducers, and constants spread around your code. It's analogous to what hooks did, encapsulating similar functionality.
Show HN: Redux with a UseState Hook
11–20 of 24 posts
Re: Show HN: Redux with a UseState Hook
#12I said this in another comment, but similarly to this, check out Redux Toolkit ( https://redux-toolkit.js.org ), the `slices` feature changed my view on Redux entirely. Basically you can have a per-feature slice of functionality rather than having actions, reducers, and constants spread around your code. It's analogous to what hooks did, encapsulating similar functionality.
This is similar to how I've always implemented Redux before using some of my own utilities, but it's nice they have an "official" way to do it now. Does it work well with TypeScript?
Re: Show HN: Redux with a UseState Hook
#13Looks great. Is there any convenient way to persist data?
Re: Show HN: Redux with a UseState Hook
#14I said this in another comment, but similarly to this, check out Redux Toolkit ( https://redux-toolkit.js.org ), the `slices` feature changed my view on Redux entirely. Basically you can have a per-feature slice of functionality rather than having actions, reducers, and constants spread around your code. It's analogous to what hooks did, encapsulating similar functionality.
Re: Show HN: Redux with a UseState Hook
#15Won't using string paths like lodash makes it hard to use this library with typescript?
Probably a fair point. I hadn't really taken typescript into account for the purposes of this library.
// instead of
useHookedOnState('app.components.counterValue', 0)
// maybe
useHookedOnState(state => state.app?.components?.counterValue, 0)
edit: on second thought, you're probably using that string in the setter as well. dang.Re: Show HN: Redux with a UseState Hook
#16The biggest issue is that it goes directly against the principles I listed in the Redux Style Guide [0], particularly:
- put as much logic as possible in reducers [1]
- reducers should own the state shape [2]
- model actions as "events", not "setters" [3]
Also, Dan pointed out early on in Redux's development that "cursor"-style approaches to state updates are not how he intended people to use Redux [4].
Will it run? Sure. Is it something I'd actually recommend? Definitely not, and especially given the existence of our official Redux Toolkit package [5] and the React-Redux hooks API [6].
[0] https://redux.js.org/style-guide/style-guide
[1] https://redux.js.org/style-guide/style-guide#put-as-much-log...
[2] https://redux.js.org/style-guide/style-guide#reducers-should...
[3] https://redux.js.org/style-guide/style-guide#model-actions-a...
[4] https://github.com/reactjs/redux/issues/155#issuecomment-113...
Re: Show HN: Redux with a UseState Hook
#17I said this in another comment, but similarly to this, check out Redux Toolkit ( https://redux-toolkit.js.org ), the `slices` feature changed my view on Redux entirely. Basically you can have a per-feature slice of functionality rather than having actions, reducers, and constants spread around your code. It's analogous to what hooks did, encapsulating similar functionality.
Re: Show HN: Redux with a UseState Hook
#18I said this in another comment, but similarly to this, check out Redux Toolkit ( https://redux-toolkit.js.org ), the `slices` feature changed my view on Redux entirely. Basically you can have a per-feature slice of functionality rather than having actions, reducers, and constants spread around your code. It's analogous to what hooks did, encapsulating similar functionality.
This is similar to how I've always implemented Redux before using some of my own utilities, but it's nice they have an "official" way to do it now. Does it work well with TypeScript?
See the "Usage with TypeScript" docs page:
Re: Show HN: Redux with a UseState Hook
#19Considering how verbose the current UX of Redux is, this needs to be merged into mainline React. Are there any significant performance overhead? This is a really great library, the ergonomics look amazing and the documentation is just gorgeous.
Thanks. It uses useDispatch behind the scenes which I believe has a bit more overhead compared to using connect. It should be comparable performance-wise to using the normal react-redux hooks.
`useDispatch` has absolutely no overhead whatsoever. It's literally just `return store.dispatch`.
There's also less "overhead" in the sense that it's not pre-binding action creators.
If you meant to say `useSelector` here, that also has less overhead than `connect` because it's having to select less state and do fewer comparisons.
Re: Show HN: Redux with a UseState Hook
#20I said this in another comment, but similarly to this, check out Redux Toolkit ( https://redux-toolkit.js.org ), the `slices` feature changed my view on Redux entirely. Basically you can have a per-feature slice of functionality rather than having actions, reducers, and constants spread around your code. It's analogous to what hooks did, encapsulating similar functionality.
It gets messy once you want to do anything advanced. And even when slices depend on each other (circular dependencies will arise).
Circular dependencies are indeed a potential issue, but most people are unlikely to run into that, and we talk about ways to handle that in the docs:
https://redux-toolkit.js.org/usage/usage-guide#exporting-and...