Fixing signatures and payload use (#6)

Co-authored-by: Alain Boudard <alain_boudard@groupe-sma.fr>

Author: aboudard

docs/chapter-5.mdx

@@ -27,14 +27,15 @@ This is an action that adds a category named `Food` to the list of all categorie
 ```ts
 // src/app/state/actions.ts
 import { createAction, props } from "@ngrx/store";
+import { Category } from "./state";
 
 export const addCategory = createAction(
   "[Category List] Add Category",
-  props<{ name: string }>()
+  props<{ category: Category }>()
 );
 ```
 
-Let's break down this example. First of all, the name `createAction` is a bit deceptive; it does not create an action; in fact, it creates a function which, when called, wil produce an action object. The first argument is the `type` of the action that will be produced. When called, the `addCategory` function will **always** create an action with type "[Category List] Create Category". The second argument uses the bizarre function `props`, which is a generic function that allows us to define the type of the `payload` which the created action will have. Essentially, it explains that in order to create the action using the `addCategory` function, we should call it and provide an object that has a property `name` which is a `string`. Let's do this and `console.log` the result.
+Let's break down this example. First of all, the name `createAction` is a bit deceptive; it does not create an action; in fact, it creates a function which, when called, wil produce an action object. The first argument is the `type` of the action that will be produced. When called, the `addCategory` function will **always** create an action with type "[Category List] Create Category". The second argument uses the bizarre function `props`, which is a generic function that allows us to define the type of the `payload` which the created action will have. Essentially, it explains that in order to create the action using the `addCategory` function, we should call it and provide an object that has a property `category` which is defined in the Interface Category defined in the AppState. Let's do this and `console.log` the result.
 
 ```ts
 // src/app/app.component.ts
@@ -47,15 +48,15 @@ import { addCategory } from "./state/actions.ts";
 })
 export class AppComponent implements OnInit {
   ngOnInit() {
-    console.log(addCategory({ name: "Food" }));
+    console.log(addCategory({category:{ name: "Food" }}));
   }
 }
 ```
 
 In the console, we will see the following:
 
 ```js
-{name: 'Food', type: '[Category List] Add Category'}
+{category: {name: 'Food', type: '[Category List] Add Category'}}
 ```
 
 So essentially, `createAction` provided us with an easy way of creating actions of the same type. `addCategory` in our case is an `ActionCreator`, a function which produces an action object whenever called, and `props` explained what argument that `ActionCreator` function expects.

docs/chapter-6.mdx

@@ -89,6 +89,8 @@ export function reducer(state: AppState, action: Action) {
 }
 ```
 
+> **_NOTE:_** Beware of the **payload** attribute of the Action, which only fits the "old" way to create actions. Next example will use the props and call directly the properties added to the Action.
+
 Now let's deconstruct this example. First of all, as you see, the `reducer` function is a pure function. Next, it differentiates between `Actions` using a `switch` statement and the `Action` types. On each different `Action`, our `Reducer` will return a slightly different version of a `State` to match that `Action`'s intent. As we have only one `Action` for now, we wrote only one `case` statement, and if the `Action` is not identified, we return the `state` without modifying it. As you can see, the practice is to copy the state, and return a new object. **Never modify the previous `state` object, always return a new one**.
 What will happen is when we dispatch the `addCategory` `Action`, the `reducer` function will be called, the new `State` (with the added category object in the `categories` array) will be returned, and then NgRx will propagate that change to all of our components.
 
@@ -106,9 +108,9 @@ import { AppState, initialState } from "./state";
 
 const _reducer = createReducer(
   initialState,
-  on(actions.addCategory, (state, action) => ({
+  on(actions.addCategory, (state, {category}) => ({
     ...state,
-    categories: [...state.categories, action.payload],
+    categories: [...state.categories, category],
   }))
 );
 
@@ -117,7 +119,7 @@ export function reducer(state: AppState, action: Action) {
 }
 ```
 
-Let's understand what goes on here. First of all, we have the `createReducer` function, which does exactly that - creates the resulting `Reducer` function. It receives the initial state of the application, and then an arbitrary amount of handlers for each action (we provided only one, but we can (and will!) have lots of `Actions`, and thus. lots of `on` function calls). The `on` function receives an `Action` as the first argument, and a callback function as a second one, which acts like a mini-`Reducer` for only that specific `Action`. Thus, the need to write huge `switch` statements is eliminated. Now let's understand two specific parts of this code:
+Let's understand what goes on here. First of all, we have the `createReducer` function, which does exactly that - creates the resulting `Reducer` function. It receives the initial state of the application, and then an arbitrary amount of handlers for each action (we provided only one, but we can (and will!) have lots of `Actions`, and thus. lots of `on` function calls). The `on` function receives an `Action` as the first argument, and a callback function as a second one, which acts like a mini-`Reducer` for only that specific `Action`. Thus, the need to write huge `switch` statements is eliminated. Note that the callback signature is (state, {category}) in which we [destruct](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#object_destructuring) the action passed in the second argument in order to only get the props. Now let's understand two specific parts of this code:
 
 1. _Why did we create a `_reducer` function only to call it in the `reducer` function?_ The thing is, in the next chapters we are going to register the `reducer` function in our `AppModule`, and because of how the Angular build process works, it does not allow including anonymous functions like the one returned by `createReducer`, only declared named functions. Thus we wrote a conventional function and called our `_reducer` from it. **Always create `Reducers` like this**.
 2. _Why didn't we `import` the `Action` we wanted by name, but rather did `import * as actions from './actions';`? Because we can easily have dozens of `Actions` that are handled in a single `Reducer` function, we would like to import them as a single object to avoid too cluttered imports.

docs/chapter-6/exercise-1/reducer.ts

@@ -1,10 +1,10 @@
 const _reducer = createReducer(
   initialState,
   // other handlers
-  on(deleteCategory, (state, action) => ({
+  on(actions.deleteCategory, (state, {name}) => ({
     ...state,
     categories: state.categories.filter(
-      (category) => category.name !== action.payload
+      (cat) => cat.name !== name
     ), // filter out the deleted category
   }))
 );

docs/chapter-6/exercise-2/reducer.ts

@@ -1,5 +1,5 @@
 const _reducer = createReducer(
   initialState,
   // other handlers
-  on(deleteAllCategories, (state, action) => ({ ...state, categories: [] })) // just assign a new empty array for categories
+  on(actions.deleteAllCategories, (state) => ({ ...state, categories: [] })) // just assign a new empty array for categories
 );