"Module functions" are more commonly known as "Action creators"
Is there a reason for AppContainer to have a shouldComponentUpdate() { return false; }? Is this a react-router thing? (note from Matthew: this is boilerplate from Redux-Starter-Kit... nothing we can do about it)
So your patientReducer holds patientInContext which gets set once the user selects a patient
and then all the other actions affect that patient - And as an opinionated nitpick: I'm not a fan of setting the current selected item in state and then performing operations without passing in an id, I'd suggest you modify youre reducer/actions to pass an id as part of the payload rather than rely on copy.patientInContext each time. - Your components can use a selector to get the current patientInContext from the store, and dispatch that in the actions (note from Matthew: I actually like the way we did this... there can only be one patient in context at a time so it's okay to assume that the store has that id)
So one thing to note is that every reducer will be called once any action gets dispatched, as your app grows this typically means that youre going to be hitting the reducer's switch statement's default case a lot more than any of your other cases. In those instances your let copy = clone(state) call at the start would be unecessary.
Another thing: Your setPatientInContext action dispatches SET_PATIENT_IN_CONTEXT on both resolve and reject of the Promise
And another nitpick would be about consistent action verb naming, you have: SET UPDATE START_ADDING and DELETING, which could be more consistent as SET UPDATE ADD and DELETE
And if this is a real app I'd say normalize a bit more by splitting the contacts out of the patients, that way the patient just has an array of contact ids (note from Matthew: this is not a big deal for our sample app)
Manuel Bieh's Review (STATUS: Review suggestions implemented)
"In React/Redux, components are introduced in the same way, however, a container must be placed in the middle so that the component can get application-wide state" - are you talking about smart/dumb components where smart components are often called "container" or what do you mean by "container"?
maybe you should add this (important) link to the additional resources: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.htl1bug49
in your example: basic: state.patient[state.patient.patientInContext].basic - it is recommended (not necessary though) to keep your redux state as flat as possible. i know that's not always easily possible and/or worth the effort but since it's a "getting started" guide i think it should at least be mentioned. (I didn't include this item... I'm not sure I agree with Manuel here, which is okay)
Victor Choueiri's Review (STATUS: Review suggestions implemented)
Manuel Bieh's Review (STATUS: Review suggestions implemented)