Merge pull request #4 from aboudard/aboudard-patch-2

Author: LayZeeDK

docs/chapter-6.mdx

@@ -9,11 +9,11 @@ import Exercise2Reducer from "!!raw-loader!./chapter-6/exercise-2/reducer";
 
 ## How do we modify the State?
 
-So far, we have learned how to create `Actions`, the building blocks of NgRx, that signal the `Store` about what happened in the application and what needs to be done. But `Actions` are just objects, that don;t hold any functionality; they by themselves cannot make any `State` changes. To make those changes actually happen, we have to use a `Reducer`, next of the core most important concepts of NgRx.
+So far, we have learned how to create `Actions`, the building blocks of NgRx, that signal the `Store` about what happened in the application and what needs to be done. But `Actions` are just objects, that don't hold any functionality; they by themselves cannot make any `State` changes. To make those changes actually happen, we have to use a `Reducer`, next of the core most important concepts of NgRx.
 
 ## What are Reducers?
 
-Reducers are _pure functions_ that receiver two arguments, the current `State` of the application, an `Action` object, calculate the new state based on the `Action` that happened, and return that new `State`. Usually calculating involves determining which `Action` happened (sometimes via `switch-case` statements, but NgRx provides utilities that reduce boilerplate), copying the previous state into a new object while modifying the relevant properties of the `State`, and returning the new `State` object. Every time an `Action` is dispatched (we will learn more about dispatching in the next chapters, for now "dispatching" an `Action` means the `Action` has happened), NgRx will call the `Reducer` function, providing the old `State` and the `Action` object as arguments, get the returned new `State` and immediately notify all of our components about the change (how neat is that!). Essentially, `Reducers` are the central place where `State` changes happen.
+Reducers are _pure functions_ that receive two arguments, the current `State` of the application, an `Action` object, calculate the new state based on the `Action` that happened, and return that new `State`. Usually calculating involves determining which `Action` happened (sometimes via `switch-case` statements, but NgRx provides utilities that reduce boilerplate), copying the previous state into a new object while modifying the relevant properties of the `State`, and returning the new `State` object. Every time an `Action` is dispatched (we will learn more about dispatching in the next chapters, for now "dispatching" an `Action` means the `Action` has happened), NgRx will call the `Reducer` function, providing the old `State` and the `Action` object as arguments, get the returned new `State` and immediately notify all of our components about the change (how neat is that!). Essentially, `Reducers` are the central place where `State` changes happen.
 
 ## What are pure functions?
 
@@ -120,7 +120,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:
 
 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.
+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.
 
 ## Homework