React
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
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
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
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
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
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
The State Management Problem
The Flux Architecture
The Flux Architecture
Library written by Dan Abramov (@gaeron)
Built on a reducer abstraction
Redux: Reducer + Flux
Redux: Reducer + Flux
Reducer
Action
Reducer
Action
State State State
Action
...
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
Redux: Reducer + Flux
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
New
State
Side Effects with Redux: Middleware
Middleware 1 Middleware 2Action ...
Side effect?
Dispatch action?
Reducer
Store Store
Side effect?
Dispatch action?
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
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
Side Effects with Redux: Thunks
How do we test this? Action creators no longer pure functions
Could mock Redux store and API call?
Middleware that deals only with making API requests.
Many existing examples. Will use “redux-api-middleware” as example.
Side Effects with Redux: API middleware
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
Side Effects with Redux: API middleware
Side Effects with Redux: Sagas
Warning:
Can be overkill for your app
Significant additional abstraction
Additional learning curve
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
Side Effects with Redux: Sagas
Side Effects with Redux: Sagas
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
Side Effects with Redux: Sagas
Side Effects with Redux: Sagas
Side Effects with Redux: Sagas
Utilise helper functions from redux-saga for:
Delays
Debouncing
Throttling
Dynamically creating new sagas
Cancelling existing sagas
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
Thank You
Elias Malik
elias@foundersandcoders.com
Github: @eliascodes

React gsg presentation with ryan jung & elias malik

  • 1.
  • 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 YouUse 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 havestate A complex UI usually introduces dependencies between components Parent -> Child dependencies are easy Child -> Parent and Sibling dependencies are harder The State Management Problem
  • 8.
  • 9.
  • 10.
  • 11.
    Library written byDan 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
  • 14.
  • 15.
    Redux reducers shouldbe 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 withRedux: Middleware Middleware 1 Middleware 2Action ... Side effect? Dispatch action? Reducer Store Store Side effect? Dispatch action?
  • 17.
    Many different solutionsexist, 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 withRedux: 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 withRedux: Thunks How do we test this? Action creators no longer pure functions Could mock Redux store and API call?
  • 20.
    Middleware that dealsonly with making API requests. Many existing examples. Will use “redux-api-middleware” as example. Side Effects with Redux: API middleware
  • 21.
    All API-related sideeffects isolated in (fully tested!) middleware Only need to check: Correct actions are being created Payload correctly processed Side Effects with Redux: API middleware
  • 22.
    Side Effects withRedux: API middleware
  • 23.
    Side Effects withRedux: Sagas Warning: Can be overkill for your app Significant additional abstraction Additional learning curve
  • 24.
    Side Effects withRedux: 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
  • 25.
    Side Effects withRedux: Sagas
  • 26.
    Side Effects withRedux: Sagas
  • 27.
    Side Effects withRedux: 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
  • 28.
    Side Effects withRedux: Sagas
  • 29.
    Side Effects withRedux: Sagas
  • 30.
    Side Effects withRedux: Sagas Utilise helper functions from redux-saga for: Delays Debouncing Throttling Dynamically creating new sagas Cancelling existing sagas
  • 31.
    Summary Thunks Specific MiddlewareSagas 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
  • 32.

Editor's Notes

  • #8 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.
  • #9 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?
  • #10 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
  • #11 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.
  • #12 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
  • #13 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.
  • #15 So after implementing redux, you might end up with code that looks like this Action creator, reducer, component
  • #17 Middleware intercepts actions Hold references to store Can hold arbitrary code, so good place to isolate side effects Can have early returns from middleware
  • #18 Look at redux-api-middleware to illustrate focussed API of a middleware that is intended for specific purpose
  • #19 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
  • #20 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
  • #23 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
  • #27 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...