Show HN: Redux with a UseState Hook(hooked-on-redux.js.org)
hooked-on-redux.js.org
Show HN: Redux with a UseState Hook
https://hooked-on-redux.js.org
23 comments
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.
RTK is great! The only thing I wish was a bit different is the `createAsyncThunk` function. It feels dirty providing the action-type string manually, when for all the other actions, this is essentially invisible.
The idea of having some kind of special syntax in `createSlice` to support declaring thunks has definitely been suggested, and there's other libraries out there that do similar things. But, anything we add to our API has to be supported indefinitely. Because of that, I wanted to release `createAsyncThunk` and `createEntityAdapter` as "standalone" utilities first and see how they actually get used by the community.
I'm definitely open to potentially integrating them together down the road, but I'd rather take it one step at a time and make sure that we're really solving the right problems the right way.
If you do have any further feedback on RTK, please feel free to file issues for discussion!
I'm definitely open to potentially integrating them together down the road, but I'd rather take it one step at a time and make sure that we're really solving the right problems the right way.
If you do have any further feedback on RTK, please feel free to file issues for discussion!
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?
Yep, RTK is specifically written in TypeScript, and I have a co-maintainer (Lenz Weber) who has done an amazing job working on the TS typedefs to make sure it works well.
See the "Usage with TypeScript" docs page:
https://redux-toolkit.js.org/usage/usage-with-typescript
See the "Usage with TypeScript" docs page:
https://redux-toolkit.js.org/usage/usage-with-typescript
That's great!
It does indeed. If you check out the advanced tutorial on the site you'll see it's in TypeScript.
Great, glad to hear RTK is working well for you!
It gets messy once you want to do anything advanced. And even when slices depend on each other (circular dependencies will arise).
Can you clarify what you mean by "messy" and "advanced"?
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...
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...
I'm a Redux maintainer. As I said over on Reddit when this was posted:
The 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...
[5] https://redux-toolkit.js.org
[6] https://react-redux.js.org/api/hooks
The 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...
[5] https://redux-toolkit.js.org
[6] https://react-redux.js.org/api/hooks
Considering 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.
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.
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.
Uh... wait, _what_?
`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.
`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.
Won'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.
Since in TS you can guarantee the user has optional chaining, so it may not be that big a change
// instead of
useHookedOnState('app.components.counterValue', 0)
// maybe
useHookedOnState(state => state.app?.components?.counterValue, 0)
Yup, that's the "magic" part.
Looks great.
Is there any convenient way to persist data?
Yep, typically you'd do it by persisting the Redux state. redux-persist is a popular library to do that to localstorage and other backends: https://github.com/rt2zz/redux-persist
Looks similar to Recoil (https://recoiljs.org/). How does it differ?
It's redux under the hood so with this library you'd be able to use existing redux tooling such as redux dev tools. Usually that's not possible with bespoke state management libraries (although I'm not familiar with Recoil)