Slide 1

Slide 1 text

summit 2017 Erik Grijzen Lisbon, Portugal 04/02/2017 Building Highly Scalable, Robust & Fast Single Page Web Apps

Slide 2

Slide 2 text

Struggles building large-scale Single Page Web Apps.

Slide 3

Slide 3 text

Traditional MVC architecture. Controller Model View

Slide 4

Slide 4 text

View View Model Model MVC doesn’t scale. Controller Model View

Slide 5

Slide 5 text

View View Model Model Infinite loops. Controller Model View

Slide 6

Slide 6 text

View View Model Model Duplicated state. Controller Model View

Slide 7

Slide 7 text

View View Model Model Hard to track errors. Controller Model View

Slide 8

Slide 8 text

View View Model Model Expensive change detection. Controller Model View

Slide 9

Slide 9 text

Data changes over time.

Slide 10

Slide 10 text

Work in isolation.

Slide 11

Slide 11 text

Super Hero developer. S

Slide 12

Slide 12 text

Framework size. Framework Performance Target

Slide 13

Slide 13 text

The more features, the bigger the size. Framework Feature Feature Feature Performance Target

Slide 14

Slide 14 text

Share components between projects. Project 1 Project 2

Slide 15

Slide 15 text

Ideas & concepts to solve these problems.

Slide 16

Slide 16 text

Erik Grijzen Senior Frontend Software Engineer

Slide 17

Slide 17 text

Components are the fundamental building blocks of the user interface.

Slide 18

Slide 18 text

Component tree structure.

Slide 19

Slide 19 text

Root component. App

Slide 20

Slide 20 text

View components for routing. App View 1 View 2

Slide 21

Slide 21 text

Components to compose your user interface. App View 1 View 2 Component Component Component Component Component Component Component Component

Slide 22

Slide 22 text

Container & Presentational components.

Slide 23

Slide 23 text

Container Smart Stateful Unpure Fat Presentational Dumb Stateless Pure Skinny

Slide 24

Slide 24 text

Presentational components.

Slide 25

Slide 25 text

Presentational components are concerned how things look.

Slide 26

Slide 26 text

Everything is a component. Label text: Placeholder text Title LABEL INPUT BUTTON

Slide 27

Slide 27 text

Composing components together. Phone number: Enter your phone number... Send

Slide 28

Slide 28 text

Component folder structure. / button button.html button.scss button.js button.test.js index.js

Slide 29

Slide 29 text

(props) => markup;

Slide 30

Slide 30 text

Presentational component example. // Header.js function(text) { return `

${text}

`; }

Slide 31

Slide 31 text

Presentational components. ﹡ Nearly all markup. ﹡ No app dependencies. ﹡ Receives data from parent. ﹡ Not aware of app state. ﹡ Rarely contain state.

Slide 32

Slide 32 text

Container components.

Slide 33

Slide 33 text

Concerned how things work.

Slide 34

Slide 34 text

Views are typically the first layer of container components. App View 1 View 2 Component Component Component Component Component Component Component Component

Slide 35

Slide 35 text

Example container component.

Slide 36

Slide 36 text

Little to no markup of its own.

Slide 37

Slide 37 text

Contains other components.

Slide 38

Slide 38 text

Passes data down.

Slide 39

Slide 39 text

Aware of application state.

Slide 40

Slide 40 text

Provides callbacks.

Slide 41

Slide 41 text

Reusing components with different data. App View 1 View 2 Component Component Component Component Component Component Component Component

Slide 42

Slide 42 text

Share components between projects. Container 1 Project 1 Container 2 Project 2

Slide 43

Slide 43 text

Separate the presentational components from your app. / Project A / app / common / containers / users / products / ... / Component Library / components / accordion / button / input / label / message-box / radio-buttons / select-box / table / text-area / ...

Slide 44

Slide 44 text

Moving to a Living Style Guide.

Slide 45

Slide 45 text

Showcasing / Testing with mock data. Container 1 Project 1 Container 2 Living Style Guide Container 3 UI Testing

Slide 46

Slide 46 text

Why split components up in two categories? ﹡ Reusability. ﹡ Testability. ﹡ Easier to reason about. ﹡ Easier to distribute. ﹡ Separation of concerns. ﹡ Work in isolation.

Slide 47

Slide 47 text

Styling components.

Slide 48

Slide 48 text

What part of the box model is the component? ? Margin Border Padding

Slide 49

Slide 49 text

Only style within the component boundaries. Component Margin Border Padding

Slide 50

Slide 50 text

Extended boundaries if it’s part of the design. Component Margin Border Padding

Slide 51

Slide 51 text

Don’t use vertical or horizontal spacing inside components. Project 1 Project 2

Slide 52

Slide 52 text

Avoiding global CSS pollution.

Slide 53

Slide 53 text

CSS Modules.

Slide 54

Slide 54 text

CSS files in which all class names and animation names are scoped locally. // Header.css .title { background-color: red; } // Header.js import styles from "./styles.css"; element.innerHTML = `

An example heading

Slide 55

Slide 55 text

The classes are dynamically generated, unique, and mapped to the component. // bundled css .Header__title_n6slD { background-color: red; } // rendered html

An example heading

Slide 56

Slide 56 text

The magic happens at build time.

Slide 57

Slide 57 text

Production build. // bundled css .n6slD { background-color: red; } // rendered html

An example heading

Slide 58

Slide 58 text

Why use CSS Modules? ﹡ True encapsulation. ﹡ The power of JavaScript. ﹡ No specificity conflicts. ﹡ No naming conflicts. ﹡ No BEM/SUIT conventions. ﹡ Forces best practices. ﹡ Explicit dependencies. ﹡ Dead code elimination. ﹡ File size.

Slide 59

Slide 59 text

Component communication.

Slide 60

Slide 60 text

Direct communication is a poor practice.

Slide 61

Slide 61 text

The Flux design pattern.

Slide 62

Slide 62 text

Unidirectional data flow. Action Dispatcher Store View

Slide 63

Slide 63 text

Components dispatch actions to the store. Store

Slide 64

Slide 64 text

Components subscribe to changes. Store

Slide 65

Slide 65 text

Why use unidirectional data flow? ﹡ Separation of concerns. ﹡ Easier to reason about. ﹡ More predictable. ﹡ Easy to keep UI in sync. ﹡ Debugging.

Slide 66

Slide 66 text

Facebook Flux Fluxible Reflux Alt Flummox Marty.js McFly Lux Fluxette Fluxxor Fluxury Freezer

Slide 67

Slide 67 text

A predictable state container.

Slide 68

Slide 68 text

Single Source of Truth.

Slide 69

Slide 69 text

The state of your whole application is stored a single store. { todos: [ { id: 3, completed: false, text: 'Three' }, { id: 2, completed: false, text: 'Two' }, { id: 1, completed: false, text: 'One' } ] }

Slide 70

Slide 70 text

State is Read-Only.

Slide 71

Slide 71 text

The only way to change the state is to emit an action. { type: 'ADD_TODO', text: 'Build my first Redux app' }

Slide 72

Slide 72 text

Typically we use action creators for better reusability. export const ADD_TODO = 'ADD_TODO' export function addTodo(text) { return { type: ADD_TODO, text, } }

Slide 73

Slide 73 text

Changes are made with Pure Functions.

Slide 74

Slide 74 text

(previousState, action) => newState

Slide 75

Slide 75 text

To specify how the state tree is transformed by actions, you write pure reducers. import { ADD_TODO } from './actions' function todosReducer(state = [], action) { switch (action.type) { case ADD_TODO: return [...state, { text: action.text, completed: false }] default: return state } }

Slide 76

Slide 76 text

Each reducer manages its own part of the global state. import { combineReducers } from 'redux'; const todoApp = combineReducers({ todosReducer, visibilityReducer, });

Slide 77

Slide 77 text

Easy to test isolated state changes.

Slide 78

Slide 78 text

What about asynchronous logic?

Slide 79

Slide 79 text

Redux middleware.

Slide 80

Slide 80 text

Middleware example. const logger = store => next => action => { console.log('dispatching', action); let result = next(action); console.log('next state', store.getState()); return result }

Slide 81

Slide 81 text

Adding middleware to the store. import { createStore, combineReducers, applyMiddleware, } from 'redux'; const todoApp = combineReducers(reducers); const store = createStore( todoApp, applyMiddleware(logger) );

Slide 82

Slide 82 text

Asynchronous actions.

Slide 83

Slide 83 text

Asynchronous action middleware. ﹡ redux-thunk ﹡ redux-promise ﹡ redux-observable ﹡ redux-saga

Slide 84

Slide 84 text

redux-promise example. export const LOAD_DATA = 'LOAD_DATA' export function load() { return { type: LOAD_DATA, payload: fetch('api/v1/data'), } }

Slide 85

Slide 85 text

Redux DevTools demo.

Slide 86

Slide 86 text

How is the user interface updated on state changes?

Slide 87

Slide 87 text

Change detection.

Slide 88

Slide 88 text

What happens if data changes? DOM MODELS

Slide 89

Slide 89 text

Model gets mutated. DOM MODELS

Slide 90

Slide 90 text

Projecting the data on the user interface. DOM MODELS change

Slide 91

Slide 91 text

Components abstract the DOM rendering. Component

Slide 92

Slide 92 text

Data is passed from top to bottom. View 1 Component Component Component Component Component Component Component Component Component Component Component Tree

Slide 93

Slide 93 text

Change! Component Tree When a change occurs...

Slide 94

Slide 94 text

Every component re-renders itself. Component Tree

Slide 95

Slide 95 text

Every component re-renders itself. Component Tree

Slide 96

Slide 96 text

Every component re-renders itself. Component Tree

Slide 97

Slide 97 text

Every component re-renders itself. Component Tree

Slide 98

Slide 98 text

Mutable data structures.

Slide 99

Slide 99 text

Example container component. class PersonDetailsContainer { constructor() { this.personData = { firstName: 'John', lastName: 'Doe', } } changeFirstName() { this.personData.firstName = 'Jane'; } }

Slide 100

Slide 100 text

Passing the data down. PersonalDetailsContainer PersonalDetailsComponent { firstName: 'John', lastName: 'Doe', }

Slide 101

Slide 101 text

Mutating the data object. PersonalDetailsContainer PersonalDetailsComponent { firstName: 'Jane', lastName: 'Doe', } Click! oldPersonData === newPersonData // true

Slide 102

Slide 102 text

Frameworks have to conservatively render the whole tree. Component Tree

Slide 103

Slide 103 text

DOM mutation are expensive.

Slide 104

Slide 104 text

Smarter change detection.

Slide 105

Slide 105 text

Immutable data structures.

Slide 106

Slide 106 text

Making a change always creates a new reference. import Immutable from 'immutable'; class PersonDetailsContainer { constructor() { this.personData = Immutable.Map( firstName: 'John', lastName: 'Doe', }); } changeFirstName() { this.personData.set('firstName','Jane'); } }

Slide 107

Slide 107 text

Passing the data down. PersonalDetailsContainer PersonalDetailsComponent { firstName: 'John', lastName: 'Doe', }

Slide 108

Slide 108 text

Passing the data down. PersonalDetailsContainer PersonalDetailsComponent oldPersonData === newPersonData // false { firstName: 'Jane', lastName: 'Doe', } Click!

Slide 109

Slide 109 text

Change! Component Tree When a change occurs...

Slide 110

Slide 110 text

When the reference is the same it won’t rerender. Component Tree

Slide 111

Slide 111 text

How can we deliver fast mobile experiences?

Slide 112

Slide 112 text

Key user moments.

Slide 113

Slide 113 text

Source: http://bit.ly/2kIzs58

Slide 114

Slide 114 text

Source: http://bit.ly/2kIzs58

Slide 115

Slide 115 text

Optimizing Perceived Performance.

Slide 116

Slide 116 text

Offline first approach.

Slide 117

Slide 117 text

Source: http://bit.ly/2jLxkcP

Slide 118

Slide 118 text

App Shell architecture.

Slide 119

Slide 119 text

Source: http://bit.ly/2jLxkcP

Slide 120

Slide 120 text

Universal JavaScript.

Slide 121

Slide 121 text

Source: http://bit.ly/2jMByAZ

Slide 122

Slide 122 text

Server-rendered application shell. Source: http://bit.ly/2jMByAZ

Slide 123

Slide 123 text

Source: http://bit.ly/2kIzs58

Slide 124

Slide 124 text

Optimizing Time To Interactive.

Slide 125

Slide 125 text

Avoid serving large, monolithic bundles.

Slide 126

Slide 126 text

Load your app like a video game.

Slide 127

Slide 127 text

Separate the bootstrap logic. App View 1 View 2 Component Component Component Component Component Component Component Component Component Component Component Component

Slide 128

Slide 128 text

Route-based chunking.

Slide 129

Slide 129 text

Views are easy split points. App View 1 View 2 Component Component Component Component Component Component Component Component Component Component Component Component

Slide 130

Slide 130 text

Loading routes on demand. [ { path: 'home', getComponent(location, cb) { System.import('./containers/Home') .then(loadRoute(cb)); }, }, { path: 'products', getComponent(location, cb) { System.import('./containers/Products) .then(loadRoute(cb)); }, }, { path: 'shopping-cart', getComponent(location, cb) { System.import('./containers/ShoppingCart') .then(loadRoute(cb)); }, }, ]

Slide 131

Slide 131 text

Separate code that is unlikely to change. App View 1 View 2 Component Component Component Component Component Component Component Component Vendor Polyfills Component Component Component Component

Slide 132

Slide 132 text

Bundle common logic together. App View 1 View 2 Component Component Component Component Component Component Component Component Vendor Polyfills Component Component Component Component

Slide 133

Slide 133 text

Deliver the minimal functionality for a view.

Slide 134

Slide 134 text

As more resources arrive, the app progressively unlocks more features.

Slide 135

Slide 135 text

Optimizing bootstrapping.

Slide 136

Slide 136 text

Source: http://bit.ly/1PE8g4r

Slide 137

Slide 137 text

Source: http://bit.ly/1PE8g4r

Slide 138

Slide 138 text

Frameworks are slow by default. Framework Size (min) Size (min + gzip) Ember 2.2.0 435kb 111kb Ember 1.13.8 486kb 123kb Angular 2 566kb 111kb Angular 2 + RxJS 766kb 143kb Angular 1.4.5 143kb 51kb React 0.14.5 + React DOM 143kb 40kb React 0.14.5 + React DOM + Redux 133kb 42kb React 15.3.0 + React DOM 139kb 23kb

Slide 139

Slide 139 text

Source: http://bit.ly/1PE8g4r

Slide 140

Slide 140 text

Source: http://bit.ly/1PE8g4r

Slide 141

Slide 141 text

Are frameworks viable for mobile use?

Slide 142

Slide 142 text

User Interface libraries.

Slide 143

Slide 143 text

We can render the whole app inexpensively.

Slide 144

Slide 144 text

Virtual DOM Source: http://bit.ly/2jsDBy5

Slide 145

Slide 145 text

The ability to re-render at will allows for a fundamentally lighter approach.

Slide 146

Slide 146 text

Benefits of this lighter approach? ﹡ No observable models. ﹡ No data binding. ﹡ No templating system ﹡ Less framework features. ﹡ Less code. ﹡ Less memory usage. ﹡ Less computations.