added more content to steps 2.4 and 2.5

step2-04/README.md

@@ -57,7 +57,7 @@ describe('TestMe Component', () => {
 
 ## Mocking
 
-Mocking functions is a large part of what makes `jest` a powerful testing library. `jest` actually intercepts module inclusion process in `node.js` allowing it to mock entire modules if needed.
+Mocking functions is a large part of what makes `jest` a powerful testing library. `jest` actually intercepts module inclusion process in `node.js` allowing it to mock entire modules if needed. There are many ways to mock as you can imagine in a language as flexible as JS. We only look at the simplest case but there's a lot of depth here.
 
 To mock a function:
 
@@ -78,7 +78,7 @@ Read more about jest mocking here: https://jestjs.io/docs/en/mock-functions.html
 
 ```ts
 it('tests callback functions', (done) => {
-  someFunctionThatCallsbackWhend(done));
+  someFunctionThatCallsDone(done));
 })
 ```
 

step2-05/README.md

@@ -2,6 +2,8 @@
 
 [Lessons](../) | [Exercise](./exercise/) | [Demo](./demo/)
 
+# Discussion on Flux
+
 Ideally React gives us a mental model of:
 
 ```
@@ -46,6 +48,56 @@ From the official documentation site:
 
 **Mental Model**: think of Reducer as part of the store and should have no side effects outside of defining how data can change from one state to next given action messages.
 
+# Getting Started with Redux
+
+We begin the journey into Redux by looking at the store. The store consists of several parts
+
+1. the state or the data - we represent this both with an initial state and with a TypeScript interface
+2. the reducers - conceptually this should be very close to the shape to the store. One reducer should be responsible for reacting to action messages to change the state from a previous to the next state.
+3. the dispatcher - there should be only one dispatcher and the store exports this. We'll look at this in Step 6!
+
+## Create Store
+
+The `createStore()` takes in several arguments. The simplest for just takes in reducers. Reducers are the means by which the state changes from one snapshot to another.
+
+```ts
+const store = createStore(reducer);
+```
+
+`createStore()` can take in an initial state - the initial state can come from any source. There are two use cases:
+
+1. load initial data from an API server
+2. load data that is generated from a server side rendering environment
+
+```ts
+const store = createStore(reducer, {
+  /* the initial state */
+});
+```
+
+`createStore()` also takes in a third argument that injects **middleware**. From the documentation site:
+
+> [Redux Middleware] provides a third-party extension point between dispatching an action, and the moment it reaches the reducer.
+
+## Reducers
+
+Remember that the reducers are **pure**. Pure functions have no side effects. They always return the same output given the same input (idempotent). They are easily testable.
+
+Reducers' only job is to change the state from one snapshot to another. They are simple functions that take in the state and an action message. These reducers looks at the action message to decide what to do to the state. A convention that has been established in the Flux community is the `type` key in the action message. Another convention is using switch statements against the `type` key to trigger further reducer functions.
+
+```ts
+function reducer(state: Store['todos'], payload: any): Store['todos'] {
+  switch (payload.type) {
+    case 'addTodo':
+      return addTodo(state, payload.id, payload.label);
+  }
+
+  return state;
+}
+```
+
+In these demo and exercises, I separated out the pure & reducer functions to make it cleaner. The tests inside `pureFunctions.spec.ts` should describe the behavior of the individual functions. They are easy to follow and easy to write.
+
 # Exercise
 
 1. First, take a look at the store interface in the `exercise/src/store/index.tsx` - note that the `Store` interface has two keys: `todos` and `filter`. We'll concentrate on the `todos` which is an object where the keys are IDs and the values are of an `TodoItem` type.