Redux

Question 1

Redux uses pure functions heavily

Answer 1

Pure functions return a new value based on arguments passed to them. They don’t modify existing objects; instead, they return a new one. These functions don’t rely on the state they’re called from, and they return only one and the same result for any provided argument.

Question 2

Redux has three building parts

Answer 2

actions, store and reducers

Question 3

actions are events

Answer 3

{ type: LOGIN_FORM_SUBMIT, payload: {username: ‘alex’, password: ‘123456’} }

Question 4

Actions are created with action creators, which are just

Answer 4

functions that return actions function authUser(form) { return { type: LOGIN_FORM_SUBMIT, payload: form } }

Question 5

Calling actions anywhere in the app, then, is very easy. Use the

Answer 5

dispatch method, like so: dispatch(authUser(form));

Question 6

reducers have a somewhat different meaning from functional Javascript (where they take multiple values and consolidate to one, or act upon streams). In Redux . . .

Answer 6

reducers are functions (pure) that take the current state of the application and an action and then return a new state

Question 7

Here is a very simple reducer that takes the current state and an action as arguments and then returns the next state

Answer 7

function handleAuth(state, action) { return _.assign({}, state, { auth: action.payload }); }

Question 8

For more complex apps, it is recommended to use the

Answer 8

combineReducers() utility provided by Redux

Question 9

If an object (state) changes only some values, Redux creates a

Answer 9

new object, the values that didn’t change will refer to the old object and only new values will be created. That’s great for performance

Question 10

const rootReducer (example)

Answer 10

const rootReducer = combineReducers({ handleAuth: handleAuth, editProfile: editProfile, changePassword: changePassword });

Question 11

Store is the object that holds the application state and provides a few helper methods to

Answer 11

access the state, dispatch actions and register listeners. The entire state is represented by a single store

Question 12

Any action returns a

Answer 12

new state via reducers. That makes Redux very simple and predictable.

Question 13

(simple example of a store)

Answer 13

import { createStore } from ‘redux’; let store = createStore(rootReducer); let authInfo = {username: ‘alex’, password: ‘123456’}; store.dispatch(authUser(authInfo));

Question 14

Redux has a slightly different implementation of time travel than Flux. In Redux, you can

Answer 14

go back to a previous state and even take your state in a different direction from that point on

Question 15

Redux DevTools supports the following “time travel” features in the Redux workflow (think of them as Git commands for your state):

Answer 15

Reset: resets to the state your store was created with Revert: goes back to the last committed state Sweep: removes all disabled actions that you might have fired by mistake Commit: makes the current state the initial state

Question 16

The time-travel feature is not

Answer 16

efficient in production and is only intended for development and debugging. The same goes for DevTools

Question 17

Redux makes testing much easier because

Answer 17

it uses functional JavaScript as a base, and small independent functions are easy to test. So, if you need to change something in your state tree, import only one reducer that is responsible for that state, and test it in isolation.

Question 18

How to make the state available to components

Answer 18

A best practice is to push the state down to children components

Question 19

To make everything work together, we have to register the store listener with a

Answer 19

subscribe helper method

Question 20

ngrx/store

Answer 20

Store builds on the concepts made popular by Redux, a popular state management container in the React community, and supercharges it with the backing of RxJS.

Question 21

your store can be thought of as a

Answer 21

client side ‘single source of truth’, or database. By adhering to the 1 store contract when designing your application, a snapshot of store at any point will supply a complete representation of relevant application state

Question 22

reducer interface

Answer 22

export interface Reducer { (state: T, action: Action): T; }

Question 23

reducer (sample)

Answer 23

export const counter: Reducer = (state: number = 0, action: Action) => { switch(action.type){ case ‘INCREMENT’: return state + 1; case ‘DECREMENT’: return state - 1; default: return state; } };

Question 24

action interface

Answer 24

export interface Action { type: string; payload?: any; }

Question 25

how do we extract, combine, and project data from store for display in our views?

Answer 25

Because store itself is an observable, we have access to the typical JS collection operations you are accustom to (map, filter, reduce, etc.) along with a wide-array of extremely powerful RxJS based observable operators. This makes slicing up store data into any projection you wish quite easy

Question 26

projecting state data (sample)

Answer 26

//most basic example, get people from state store.select(‘people’) //combine multiple state slices Observable.combineLatest( store.select(‘people’), store.select(‘events’), (people, events) => { //projection here })

Question 27

A component invoking an action (sample)

Answer 27

increment(){ this.store.dispatch({type: ‘INCREMENT’}); }

Question 28

Because store provides an entry point both before and after dispatched actions hit application reducers

Answer 28

problems such as syncing slices of state to local storage, advanced logging, and implementing sagas are easily solved with a quick package include and a few lines of code

Question 29

All state updates are handled in reducers, which are pure functions

Answer 29

Pure functions are extremely simple to test, as it is simply input in, assert against output. This enables the testing of the most crucial aspects of your application without mocks, spies, or other tricks that can make testing both complex and error prone

Question 30

The two pillars of @ngrx/store, the store and dispatcher, both extend

Answer 30

RxJS Subjects

Question 31

Subjects are both Observables and Observers, meaning

Answer 31

you can subscribe to a Subject, but can also subscribe a Subject to a source. At a high-level Subjects can be thought of as messengers, or proxies; because Subjects are Observers, you can ‘next’, or pass values into the stream directly

Question 32

the Dispatcher extends Subject, adding

Answer 32

a dispatch method as a passthrough to the classic next method

Question 33

While vanilla Subjects work perfectly as a ‘dispatcher’, they have one issue that prevents them from being a good fit for store

Answer 33

When subscribing to a Subject, only values emitted after the subscription are received. This is unacceptable in an environment where components will be consistently added and removed, requiring the latest, on-demand sections of state from the application store at the time of subscription

Question 34

RxJS offers a convienant extension of Subject to handle this problem, the BehaviorSubject. BehaviorSubjects encapsulate all of the functionality of Subject, but also

Answer 34

return the last emitted value to subscribers upon subscription. This means components and services will always have access to the latest (or initial) application state and all future updates

Question 35

In a Store application, all dispatched actions must be passed through a specific pipeline before a new representation of state is passed into store, to be emitted to all observers. You can think of this as a factory assembly line, in this case the stations on the line are

Answer 35

pre-middleware -> reducers -> post-middleware -> store

Question 36

Reducers are the foundation of any Store or Redux-based application, describing sections of state and their potential transformations based on dispatched action types

Answer 36

Like a snowball rolling down hill, reducers accumulate value through iteration…

Question 37

Inspired by Redux, @ngrx/store has the concept of

Answer 37

Reducer functions used to manipulate specific slices of state. Reducers accept a state and action parameter, exposing a switch statement (generally, although this could be handled multiple ways) defining action types in which the reducer is concerned

Question 38

Each time an action is dispatched, each reducer registered to store will be called through . . .

Answer 38

the root reducer (created during provideStore at application bootstrap), passed the current state for that state slice (accumulator) and the dispatched action

Question 39

Scan behaves in a similar fashion to reduce, except

Answer 39

the accumulator value is maintained over time, or until the observable with scan applied has completed. For instance, as actions are dispatched and new state output, the accumulator in the scan function will always be the last output representation of state

Question 40

the store’s “select” method

Answer 40

select(key : string) { return this .map(state => state[key]) .distinctUntilChanged(); }

Question 41

the store’s “select” method

Answer 41

select(key : string) { return this .map(state => state[key]) .distinctUntilChanged(); }

Question 42

role of store vs reducers

Answer 42

As the application store maintains state, reducers are the workhorse behind the manipulation and output of new state representations as actions are dispatched. Each reducer should be focused on a specific section, or slice of state, similar to a table in a database

Question 43

chief idiom when working on reducers

Answer 43

never mutate previous state and always return a new representation of state when a relevant action is dispatched. Instead of using mutative methods like push, or reassigning values to previously existing objects, you will instead lean on none mutating methods like concat and Object.assign to return new values

Question 44

People reducer (sample)

Answer 44

const personDetails = (state, action) => { switch(action.type){ case ADD_GUEST: if(state.id === action.payload){ return Object.assign({}, state, {guests: state.guests + 1}); } return state;

Question 45

action constants

Answer 45

//Person Action Constants export const ADD_PERSON = ‘ADD_PERSON’; export const REMOVE_PERSON = ‘REMOVE_PERSON’;

Question 46

smart components

Answer 46

Smart, or Container components should be your root level, routable components. These components generally have direct access to store or a derivative. Smart components handle view events and the dispatching of actions, whether through a service or directly. Smart components also handle the logic behind events emitted up from child components within the same view.

Question 47

dumb components

Answer 47

dumb, or Child components are generally for presentation only, relying exclusively on @Input parameters, acting on the receieved data in an appropriate manner. When relevant events occur in dumb components, they are emitted up to be handled by a parent smart component. Dumb components will make up the majority of your application, as they should be small, focused, and reusable.

Question 48

when do you need to unsubscribe to a store?

Answer 48

/* if you do not use async pipe and create manual subscriptions always remember to unsubscribe in ngOnDestroy */ ngOnDestroy(){ this.subscription.unsubscribe(); }

Question 49

sample of a dumb component

Answer 49

export class PersonList { /* “dumb” components do nothing but display data based on input and emit relevant events back up for parent, or “container” components to handle */ @Input() people; @Output() addGuest = new EventEmitter(); @Output() removeGuest = new EventEmitter(); @Output() removePerson = new EventEmitter(); @Output() toggleAttending = new EventEmitter(); }

Question 50

AsyncPipe is

Answer 50

a unique, stateful pipe in Angular 2 meant for handling both Observables and Promises. When using the AsyncPipe in a template expression with Observables, the supplied Observable is subscribed to, with emitted values being displayed within your view. This pipe also handles unsubscribing to the supplied observable, saving you the mental overhead of manually cleaning up subscriptions in ngOnDestroy. In a Store application, you will find yourself leaning on the AsyncPipe heavily in nearly all of your component views

Question 51

using AsyncPipe

Answer 51

You can pipe any Observable (or promise) through async and a subscription will be created, updating the template value on source emission

Question 52

Redux (visual)

Answer 52

Question 53

Redux in motion

Answer 53

Question 54

The concept behind onPush

Answer 54

The concept behind OnPush is straightforward, when components rely solely on inputs, and those input references do not change, Angular can skip running change detection on that section of the component tree. As discussed previously, all delegating of state should be handled in smart, or top level components. This leaves the majority of components in our application relying solely on input, safely allowing us to set the ChangeDetectionStrategy to OnPush in the component definition. These components can now forgo change detection until necessary