Gain insights into building reactive websites with RxJS. Delve into mastering observables and managing events efficiently to create fast, responsive applications while reducing bugs.

c.tar.gz

stopWatch2

codewidgetJobDetach

dcrx

stopWatch2-tmux

codewidgetJobDetach-copy

rx-photos-ng

Angular

rx-photos-ng-initial

rx-angular-pizza

rx-angular-perf

rx-angular-bad-perf

rx-angular-good-perf

rx-angular-pizza-copy

stopWatch2-tmux-serv2

fightergame

The list of requirements for frontend work keeps increasing. Websites that load quickly on shaky connections, render perfectly on mobile devices, and respond with lightning speed to user input are expected. All of these tasks require dealing with a high number of events from disparate sources, be it your Customer Relationship Management (CRM), late-breaking news, or just a chat room.

Observables is a new way of thinking about managing these events, even when they may occur sometime in the future.

In this course, you’ll learn how to delegate both the calls and control flow to RxJS, allowing you to focus on the rest of your application.

RxJS compartmentalizes eventing flows, encapsulating each action in a single function, providing many helper operators that keep an internal state, allowing you to outsource your state worries to the library.

By the end of this course, you will be able to build bigger, faster, and less-buggy applications for your users.

Build Reactive Websites with RxJS: Master Observables and Wrangle



 

# `ngrx` reducers</ii></i>



We need to define just how these state changes work.  In `state.ts`, we'll define the patient **reducer**, a function that handles the `UPDATE_PATIENT` and `ADD_PATIENTS` actions.  

This application has only one type of state (an array of patients), but more complex apps have many different values stored in `ngrx` (user data, form elements, and the like).





export function patientReducer(state = [], action: PatientAction) { // (1)
  switch (action.type) { // (2)
    case UPDATE_PATIENT:
      return state.map((item, idx) => // (3)
        idx === action.payload.index ? action.payload.newPatient : item
      );
    case ADD_PATIENTS: // (4)
      return [...state, ...action.payload];
    default: // (5)
      return state;
  }
}



- **Line 1:**    <hz points="-.15">Every **reducer** takes **two parameters**:the _current state_ and the _action_ to modify that state.  
It's good practice to include a default value for the state parameter, which becomes the initial application state. 
The <ic>`action`</ic> parameter might be undefined, when <ic>`ngrx`</ic> just wants to fetch the current state (this is why we have a default case in our <ic>`switch`</ic> statement).  Otherwise, the action is defined as one of the two actions you defined in the previous [lesson](https://www.educative.io/courses/reactive-websites-rxjs/actions).


- **Line 2:**  Speaking of the <ic>`switch`</ic> statement, eventually this reducer needs to handle several different types of state change events.  Reducers commonly include a <ic>`switch`</ic> statement to help organize all of the different goings-on that might occur with their slice of the overall state.
    


- **Line 4:**  Most importantly, we have the handler for the <ic>`UPDATE_PATIENT`</ic> event.  In this case, it returns a new array of patients.  This new array contains all the same patients as before, except for the one new patient containing the modified data from the event.  The reducer returns a new array every time an action is dispatched with the <ic>`UPDATE_PATIENT`</ic> event.  
</br>
Every reducer should be a pure function, not modifying anything, but creating new arrays and objects when needed.  Behind the scenes, <ic>`ngrx`</ic> uses object reference checks to determine what has changed.  If our reducer modifies an object in place (and therefore, returns the same object reference when called), ngrx thinks nothing has changed and doesn't notify listeners. 
(A common mistake: <ic>`Object.assign(currentState, { foo: "bar" }`</ic>).  This just updates <ic>`currentState`</ic> and does not create a new object.)  Function purity also allows tools like <ic>`@ngrx/store-devtools`</ic> to keep track of state change history while you're debugging.



- **Line 7:**  <hz points="-.2">Somehow we need to tell the reducer about all the patients in the ward.  The service that fetches the patients could loop through a succession of dispatches of <ic>`UPDATE_PATIENT`</ic>, but this is much simpler.  When the <ic>`ADD_PATIENTS`</ic> event is emitted, a new array containing both the old and new patients is returned.


- **Line 9:**  Every reducer should have a default case that returns the state as-is.  This default is triggered in **two cases**: When the application is first initialized, ngrx calls all reducers without any parameters.<br/>In this case, the state parameter defaults to an empty array, and the switch returns the empty array as the initial state.  The second case is when an action is dispatched to ngrx that this reducer doesn't handle.  While this won't happen in this application, it's common to have many reducers that handle all kinds of actions.

  


Now that you've defined how this application's state can be modified, it's time to implement these actions in a reducer.

Course Introduction

Creating Observables

Manipulating Streams

Managing Asynchronous Events

Advanced Async

Multiplexing Observables

Using HTTP in Angular

Building Reactive Forms in Angular

Advanced Angular

Reactive Game Development

Reducers

`ngrx` reducers

Reducers

ngrx reducers

`ngrx` reducers