6 ms·

I love Redux but I am very frugal about what I put into the store and have come up with a strong set of design patterns with my team to know what should and sho

I love Redux but I am very frugal about what I put into the store and have come up with a strong set of design patterns with my team to know what should and should not go there. That, in conjunction with hooks for any other stateful concerns we have, makes for a sane and pleasant dev experience. IMO the biggest and best draw of Redux is how it allows you to completely separate your business logic from your UI layers. Your components only know about props and state and are rather trivial to test. Hooks are great for re-usable logic as well but my team made the choice to have hooks deal only with localized state concerns and have a robust Actions => Services => Reducer layer for everything that speaks to things outside that constraint. Its worked out wonderfully so far. Tests are a breeze and logic is highly portable. Our UI layer is thin and easy to change. Its not all roses of course. The Redux store can turn into a rats nest of keys and values with no obvious structure (or worse, duplicated structures). It's something that requires actually sitting down and modelling out your data structures. Sadly that's something I don't see very often (and I am just as guilty as anyone else). The Redux team came up with some good guidelines on this point (too lazy to track the link down but its on the main site) and I think they have some really good ideas. I think more than anything its important to consider your store in the same manner you would a database and approach it with that kind of mindset. As with all things JS, its easy to dive in, hard to untangle yourself! :)

acemarke 7y ago
That would be the "Style Guide" docs page: https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide
- vikingcaffiene 7y ago
  Thank you kind stranger :)
tracker1 7y ago
I do kind of violate this... I tend to use action creators that will accept an event from a component, and use e.target.dataset.someValue as necessary... it's not exactly a violation... but it's muddy... having clean action handler syntax in my Components though it better imho. I use createActionsHook below in every actions.js file... combined with thunks, it's awesome imho. https://www.npmjs.com/package/react-redux-actions-hook https://www.npmjs.com/package/react-redux-actions-hook
- vikingcaffiene 7y ago
  Thanks for the perspective. :) IMO the only downside to your approach is that it couples your action creators to the calling component. That isn't necessarily a bad thing but it all depends on what your particular goals are. If you intend to have your action creators as a kind of "super prop" that is specific to your caller and disposable and single purpose in nature, I think that works. To be successful (again IMHO) you'd want to segregate your business logic outside of that layer into either the reducer (as the redux team recommends) or in a service layer that the actions can talk to (my preferred approach). As always YMMV.
  - tracker1 7y ago
    Oh, the results are handled by the reducer... it's not that far off.. expecting an event with a given shape, as opposed to a direct argument. Can even be split, one for the view specifically another for the more pure actioncreator... with the thunks+async function, it's easy to have a start, await api call and finish/error events dispatched.
    - vikingcaffiene 7y ago
      Yep! :) Sounds like you've thought it through and I see your point.
bugeats 7y ago
> I think more than anything its important to consider your store in the same manner you would a database Yes and to keep it normalized. IMO, Redux is incomplete without some sort of selector layer, which acts as the metaphorical database views. https://github.com/reduxjs/reselect https://github.com/reduxjs/reselect
- acemarke 7y ago
  We've recommended normalizing data as a pattern for years [0], but never had any official tooling to support that use case. Redux Toolkit 1.3 now has a new `createEntityAdapter` API that can help with the process of inserting and updating normalized data [1]. [0] https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape https://redux.js.org/recipes/structuring-reducers/normalizin... [1] https://redux-toolkit.js.org/api/createEntityAdapter https://redux-toolkit.js.org/api/createEntityAdapter

acemarke 7y ago

That would be the "Style Guide" docs page: https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide

vikingcaffiene 7y ago
Thank you kind stranger :)

tracker1 7y ago

I do kind of violate this... I tend to use action creators that will accept an event from a component, and use e.target.dataset.someValue as necessary... it's not exactly a violation... but it's muddy... having clean action handler syntax in my Components though it better imho. I use createActionsHook below in every actions.js file... combined with thunks, it's awesome imho. https://www.npmjs.com/package/react-redux-actions-hook https://www.npmjs.com/package/react-redux-actions-hook

vikingcaffiene 7y ago
Thanks for the perspective. :) IMO the only downside to your approach is that it couples your action creators to the calling component. That isn't necessarily a bad thing but it all depends on what your particular goals are. If you intend to have your action creators as a kind of "super prop" that is specific to your caller and disposable and single purpose in nature, I think that works. To be successful (again IMHO) you'd want to segregate your business logic outside of that layer into either the reducer (as the redux team recommends) or in a service layer that the actions can talk to (my preferred approach). As always YMMV.
- tracker1 7y ago
  Oh, the results are handled by the reducer... it's not that far off.. expecting an event with a given shape, as opposed to a direct argument. Can even be split, one for the view specifically another for the more pure actioncreator... with the thunks+async function, it's easy to have a start, await api call and finish/error events dispatched.
  - vikingcaffiene 7y ago
    Yep! :) Sounds like you've thought it through and I see your point.

bugeats 7y ago

> I think more than anything its important to consider your store in the same manner you would a database Yes and to keep it normalized. IMO, Redux is incomplete without some sort of selector layer, which acts as the metaphorical database views. https://github.com/reduxjs/reselect https://github.com/reduxjs/reselect

acemarke 7y ago
We've recommended normalizing data as a pattern for years [0], but never had any official tooling to support that use case. Redux Toolkit 1.3 now has a new `createEntityAdapter` API that can help with the process of inserting and updating normalized data [1]. [0] https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape https://redux.js.org/recipes/structuring-reducers/normalizin... [1] https://redux-toolkit.js.org/api/createEntityAdapter https://redux-toolkit.js.org/api/createEntityAdapter