2. What is React?
• Client-side library made and open-sourced by Facebook
• Much simpler than Angular (fast learning curve)
• Main goal is to be fast, scalable, and simple
• React Native allows you to port over code to native iOS
or Android apps
3. Why Would You Use React?
• Fast Learning Curve
• Reusable Components which manage state
• Ability to use JSX which reduces risk of XSS
• Abstraction
o View in MVC as opposed to client-side MVC
o Use Flux/Redux as single source of truth
4. React Basics – Virtual DOM / Components
• Virtual DOM
o React keeps an abstraction of the DOM; when changes are made, it will only re-render the elements
that were changed, not the entire DOM
o Makes it very fast from a performance perspective
• Components
o React allows you to create your own HTML elements and then define logic and state variables for
these elements
o 2 key methods to know:
o React.Component:
o Allows us to define new Components
o Must have render() method
o ReactDOM.render:
o Lets us place Component in DOM
5. React Basics - State
• As noted, each Component maintains its own set of
variables which programmer defines
• We can set and get these state variables; when we set
them, it causes the Component to re-render
• We will talk about this more later, when we discuss Redux
6. React Basics – Events and JSX
• Components have lifecycle methods and event-based
methods that will update state and re-render
• For events (such as onClick or onSubmit), we access value
through event.target.value -> pass this to child components
if necessary, and then update state
• JSX
o React allows you to write HTML-like code mixed with JS to define how to
render or manipulate Components
7. Components can have state
A complex UI usually introduces
dependencies between
components
Parent -> Child dependencies are
easy
Child -> Parent and Sibling
dependencies are harder
The State Management Problem
11. Library written by Dan Abramov (@gaeron)
Built on a reducer abstraction
Redux: Reducer + Flux
12. Redux: Reducer + Flux
Reducer
Action
Reducer
Action
State State State
Action
...
13. Redux: Reducer + Flux
Flux Redux
Update logic in stores Update logic in reducers
Multiple stores Single store, multiple reducers
Multiple state trees Single state atom
Easy state reconstruction
15. Redux reducers should be pure functions
This makes testing Redux based code really easy, right?
...But how do we handle side effects?
AJAX calls
Web Sockets
Integrating 3rd party libraries
Side Effects with Redux
16. New
State
Side Effects with Redux: Middleware
Middleware 1 Middleware 2Action ...
Side effect?
Dispatch action?
Reducer
Store Store
Side effect?
Dispatch action?
17. Many different solutions exist, variously opinionated
Look at three different middlewares, and their impacts on testing:
redux-thunk (@gaeron)
redux-api-middleware (@agraboso)
redux-saga (@yelouafi)
Standard example: making an API call
Side Effects with Redux: Middleware
18. Side Effects with Redux: Thunks
Redux-thunk allows action creators to return functions
Those functions can be impure, and also dispatch other actions
Generalised solution to side effects, can be used for API calls
19. Side Effects with Redux: Thunks
How do we test this? Action creators no longer pure functions
Could mock Redux store and API call?
20. Middleware that deals only with making API requests.
Many existing examples. Will use “redux-api-middleware” as example.
Side Effects with Redux: API middleware
21. All API-related side effects isolated in (fully tested!) middleware
Only need to check:
Correct actions are being created
Payload correctly processed
Side Effects with Redux: API middleware
23. Side Effects with Redux: Sagas
Warning:
Can be overkill for your app
Significant additional abstraction
Additional learning curve
24. Side Effects with Redux: Sagas
Generators:
May be familiar from other languages (e.g. Python)
Allow function execution to be paused
Allow information to be passed in and out
27. Side Effects with Redux: Sagas
Question:
So what? Added additional complexity, what have we won?
Answer:
Further decoupling of components
Declarative actions
Complex sequences of effects
Easier testability of those complex sequences
30. Side Effects with Redux: Sagas
Utilise helper functions from redux-saga for:
Delays
Debouncing
Throttling
Dynamically creating new sagas
Cancelling existing sagas
31. Summary
Thunks Specific Middleware Sagas
General & flexible Allows building focussed
API
Powerful & flexible
Testing requires mocking Small learning overhead Significant learning
overhead
Logic in action creators Easy testing Easy testing
Suitable for smaller or
simpler apps
Suitable for most apps Suitable for large & complex
apps
A React app consists of a component tree. Each component can have a child or a parent, and maintain own state.
In apps with a relatively complex UI, there will usually be dependencies between the states of various components.
Parent-child dependencies, easy. React provides solution: props
More complex case: sibling dependency; state of a component depends on another not directly above it in the component hierarchy.
Used to often end up in situations like this.
Dependencies are managed ad-hoc, components are coupled & hold references to each other.
Example: user button click should update notification bar state
This is problem, what is solution?
Facebook's answer to the state management problem
Stores manage and reconcile state for a given _domain_ (e.g. UserStore, MapStore)
Actions describe changes
Dispatcher sends actions to all stores
Views subscribe to store
Uni-directional data flow
Why is that good? Decouples components from each other. All now only depend on the store
End up in situation like this
Only one store here for clarity.
Cleaner, and not every component needs to subscribe to the store.
So that’s Flux, but this talk isn’t about Flux, it’s about Redux.
Inspired by Flux, along with many other patterns; like those used in Elm and Om (ClojureScript)
Built on a reducer abstraction
Anyone use reduce regularly?
Reducer is just a function; takes old state, and a new piece of information, returns new state
Applied to collections of items
Key insight of redux is to view sequences of actions as a collection in time, which can be reduced over.
Same structure as reducing array of elements to single element
Just that in redux, the reduction operation is never complete, because new actions can be dispatched all the time.
So after implementing redux, you might end up with code that looks like this
Action creator, reducer, component
Middleware intercepts actions
Hold references to store
Can hold arbitrary code, so good place to isolate side effects
Can have early returns from middleware
Look at redux-api-middleware to illustrate focussed API of a middleware that is intended for specific purpose
Pros:
> general
> lightweight
> sufficient for most small React apps
Cons:
> Inconsistent action creator return types
> Tend to put a lot of logic in action creators
Explain test…
This is OK, but lots of mocking is (1) annoying, (2) code smell: too much coupling / mixing of concerns
Nonetheless, thunks are adequate solution for many
Explain test…
This is easier to test that the equivalent thunk code.
Having a specific middleware focussed on isolating one class of side effect is a useful pattern in general.
Also used for websockets, I’ve used it when integrating 3rd party libraries into a Redux app
So what is a saga? A saga is just a generator that yields objects to the redux-saga middleware.
These objects are instructions for the middleware.
They come in two types: watcher sagas and worker sagas. Watchers listen for dispatched actions, while workers react to them. You can think of these sagas as daemons, or long-running processes in your app, that listen for changes.
Explain example...