to make our reducers less brittle & easier to refactor, as well as reduce repeated code, we should provide selectors to get data out of our state tree, rather than doing deep queries like this all the time:
It's generally suggested that selectors are defined alongside reducers and exported, and then reused elsewhere (such as in mapStateToProps functions, in async action creators, or sagas) to colocate all the code that knows about the actual shape of the state tree in the reducer files.
bnchdrff
commented
6 years ago
what's wrong?
to make our reducers less brittle & easier to refactor, as well as reduce repeated code, we should provide selectors to get data out of our state tree, rather than doing deep queries like this all the time:
https://github.com/steemit/condenser/blob/1842b43aef55d58a089f7e2e735fd2c4c0885f31/src/app/components/cards/UserListRow.jsx#L28
https://github.com/steemit/condenser/blob/1842b43aef55d58a089f7e2e735fd2c4c0885f31/src/app/components/pages/CreateAccount.jsx#L477
https://github.com/steemit/condenser/blob/1842b43aef55d58a089f7e2e735fd2c4c0885f31/src/app/components/pages/PickAccount.jsx#L342
this is one obvious example, but there are many other similar instances.
if the state shape changes, it'd break all of its users which rely on a certain shape.
how do we fix it?
use selectors.
https://redux.js.org/docs/faq/CodeStructure.html#structure-file-structure :
or even use reselect -- see https://medium.com/@adamrackis/querying-a-redux-store-37db8c7f3b0f
as a start, we can target some glaring examples like "user is logged in".
also we should target any examples which might benefit from memoization.