-
-
Save gastonmorixe/cf6f40578524ddd085dd to your computer and use it in GitHub Desktop.
import { combineReducers } from 'redux' | |
import reduceReducers from 'reduce-reducers' | |
import { invites } from './Invites' | |
import { claimInvite } from './ClaimInvite' | |
import { app } from './App' | |
import * as actions from '../constants/ActionTypes' | |
import {mapping, parseRemotePersonJSON} from './App' | |
const combinedReducer = combineReducers({ | |
invites, | |
app, | |
claimInvite, | |
}) | |
const rootAccessReducer = (state, action) => { | |
switch (action.type) { | |
case `${actions.REQUEST_INVITE}_FULFILLED`: | |
return { ...state, | |
app:{...state.app, | |
loggedPerson: {...state.app.loggedPerson, | |
...parseRemotePersonJSON(action.payload.person), | |
authToken: state.app.loggedPerson.authToken | |
} | |
}, | |
claimInvite:{...state.claimInvite, | |
inviteRequest: {...state.claimInvite.inviteRequest, | |
state: 'loaded' | |
} | |
} | |
} | |
default: | |
return state | |
} | |
} | |
const rootReducer = reduceReducers(combinedReducer, rootAccessReducer) | |
export default rootReducer |
@gaearon great, I get your points.
Still, one more thing.
If instead of solving this invite request thing using redux-promise-middleware
(REQUEST_INVITE_PENDING, REQUEST_INVITE_FULFILLED, REQUEST_INVITE_REJECTED), doing so using sagas and having one and only saga that takes care of the inviting stuff.
It would watch REQUEST_INVITE
and when resolved it would do something like this
yield put( appActions.preloadData( {personData: {firstName: "Jorge"}}) )
This way, the invitation thing is only managed and understood in one place. I still get the part that it might become a mess later on in big apps because you can not check the "app" reducer and instantly get "who changed this state".
So the question final question is, is a matter of preference or I am still missing a better approach?
Thank you so much. 🎄
for historical and educational reasons, the happy ending
from dan: @gastn___ I like the last approach you suggested.
I'm currently in the boat you were in during the time of this gist. I was hoping you could help shed some light. How did you handle higher order components/reducers that depended on other primitive reducers and do so with async fetch calls? Did redux-promise-middleware/redux-saga seem end up feeling like a good fit?
How different parts of state react to the same action is what Redux considers different concerns. This allows different people on the team to work on different parts of the app that may respond to or fire the same actions—but don't have to share any mutation logic, and thus avoid constant merge conflicts.
In the situation you describe the solution is to grep the code base for the action name you wish to remove. It's not really hard to remove a corresponding switch case from every reducer, and it's much less fragile to split that logic than to keep it in a single place. For example if you later want to change the state shape of one of the reducers that are currently invite-aware, your code won't break because some outer "cross-cutting" reducer relied on its state shape.