$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
React+Redux @ Scale
Search
Daniel Cousineau
June 26, 2017
Programming
1
340
React+Redux @ Scale
Given at QCon NYC 2017
https://qconnewyork.com/ny2017/presentation/reactredux-scale-talk
Daniel Cousineau
June 26, 2017
Tweet
Share
More Decks by Daniel Cousineau
See All by Daniel Cousineau
Time is a Social Construct
dcousineau
1
600
React @ Scale
dcousineau
0
190
Frontend Performance & You
dcousineau
0
310
Feature Flags & You
dcousineau
2
100
Reframing The Problem - DCJS July 2016
dcousineau
0
140
YAFT
dcousineau
2
150
Queues and the beanstalkd
dcousineau
1
670
How Not Writing PHP Makes You Better At PHP
dcousineau
0
390
JavaScript for PHP Developers
dcousineau
4
700
Other Decks in Programming
See All in Programming
TVerのWeb内製化 - 開発スピードと品質を両立させるまでの道のり
techtver
PRO
3
1.4k
CloudNative Days Winter 2025: 一週間で作る低レイヤコンテナランタイム
ternbusty
7
1.9k
Full-Cycle Reactivity in Angular: SignalStore mit Signal Forms und Resources
manfredsteyer
PRO
0
180
AIエンジニアリングのご紹介 / Introduction to AI Engineering
rkaga
2
1.1k
バックエンドエンジニアによる Amebaブログ K8s 基盤への CronJobの導入・運用経験
sunabig
0
130
AIコーディングエージェント(NotebookLM)
kondai24
0
120
【CA.ai #3】ワークフローから見直すAIエージェント — 必要な場面と“選ばない”判断
satoaoaka
0
210
なあ兄弟、 余白の意味を考えてから UI実装してくれ!
ktcryomm
10
11k
モダンJSフレームワークのビルドプロセス 〜なぜReactは503行、Svelteは12行なのか〜
fuuki12
0
190
分散DBって何者なんだ... Spannerから学ぶRDBとの違い
iwashi623
0
170
大体よく分かるscala.collection.immutable.HashMap ~ Compressed Hash-Array Mapped Prefix-tree (CHAMP) ~
matsu_chara
1
210
tparseでgo testの出力を見やすくする
utgwkk
1
130
Featured
See All Featured
Code Review Best Practice
trishagee
73
19k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.8k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
The Cult of Friendly URLs
andyhume
79
6.7k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.3k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
Documentation Writing (for coders)
carmenintech
76
5.2k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Transcript
React+Redux @ Scale
@dcousineau
None
None
None
None
Rules
None
“Rules”
None
None
Scalability is the capability of a system, network, or process
to handle a growing amount of work, or its potential to be enlarged to accommodate that growth. – Wikipedia
Part 1: React
Rule: Components should be stateless
Reality: State is the enemy, but also inevitable
onClick(e) { const value = e.target.value; const formatted = value.toUpperCase();
this.setState({value: formatted}); }
onClick() { this.setState((previousState, currentProps) => { return { show: !previousState.show,
}; }); }
onClick(e) { this.setState({value: e.target.value}); this.props.onChange(this.state.value); }
onClick(e) { this.setState({value: e.target.value}, () => { this.props.onChange(this.state.value); }); }
Rule: Don’t use Context, it hides complexity
Reality: Sometimes complexity should be hidden
None
None
class TextCard extends React.Component { static contextTypes = { metatypes:
React.PropTypes.object, }; render() { const {cardData} = this.props; const {metatypes} = this.context; return ( <div> The following is either editable or displayed: <metatypes.text value={cardData.text} onChange={this.props.onChange} /> </div> ) } } function selectCardComponent(cardData) { switch (cardData.type) { case 'text': return TextCard; default: throw new Error(`Invalid card type ${cardData.type}`); } }
class TextCard extends React.Component { static contextTypes = { metatypes:
React.PropTypes.object, }; render() { const {cardData} = this.props; const {metatypes} = this.context; return ( <div> The following is either editable or displayed: <metatypes.text value={cardData.text} onChange={this.props.onChange} /> </div> ) } } function selectCardComponent(cardData) { switch (cardData.type) { case 'text': return TextCard; default: throw new Error(`Invalid card type ${cardData.type}`); } }
const metatypesEdit = { text: class extends React.Component { render()
{ return <input type="text" {...this.props} />; } } } const metatypesView = { text: class extends React.Component { render() { return <span>{this.props.value}</span>; } } }
class CardViewer extends React.Component { static childContextTypes = { metatypes:
React.PropTypes.object }; getChildContext() { return {metatypes: metatypesView}; } render() { const {cardData} = this.props; const CardComponent = selectCardComponent(cardData); return <CardComponent cardData={cardData} /> } }
class CardEditor extends React.Component { static childContextTypes = { metatypes:
React.PropTypes.object }; getChildContext() { return {metatypes: metatypesEdit}; } render() { const {cardData} = this.props; const CardComponent = selectCardComponent(cardData); return <CardComponent cardData={cardData} /> } }
Part 2: Redux
Rule: “Single source of truth” means all state in the
store
Reality: You can have multiple “single sources”
this.state.checked = true;
this.props.checked = true; this.props.checked = true; this.props.checked = true; this.state.checked
= true;
this.props.checked = true; this.props.checked = true; this.props.checked = true; this.props.checked
= true; checked: true connect()();
window.location.*
Rule: Side effects should happen outside the Redux cycle
Reality: This doesn’t mean you can’t have callbacks
function persistPostAction(post, callback = () => {}) { return {
type: 'PERSIST_POST', post, callback }; } function *fetchPostsSaga(action) { const status = yield putPostAPI(action.post); yield put(persistPostCompleteAction(status)); yield call(action.callback, status); } class ComposePost extends React.Component { onClickSubmit() { const {dispatch} = this.props; const {post} = this.state; dispatch(persistPostAction(post, () => this.displaySuccessBanner())); } }
class ViewPostPage extends React.Component { componentWillMount() { const {dispatch, postId}
= this.props; dispatch(fetchPostAction(postId, () => this.logPageLoadComplete())); } }
Rule: Redux stores must be normalized for performance
Reality: You must normalize to reduce complexity
https://medium.com/@dcousineau/advanced-redux-entity-normalization-f5f1fe2aefc5
{ byId: { ...entities }, keyWindows: [`${keyWindowName}`], [keyWindowName]: { ids:
['id0', ..., 'idN'], ...meta } }
{ byId: { 'a': userA, 'b': userB, 'c': userC, 'd':
userD }, keyWindows: ['browseUsers', 'allManagers'], browseUsers: { ids: ['a', 'b', 'c'], isFetching: false, page: 1, totalPages: 10, next: '/users?page=2', last: '/users?page=10' }, allManagers: { ids: ['d', 'a'], isFetching: false } }
function selectUserById(store, userId) { return store.users.byId[userId]; } function selectUsersByKeyWindow(store, keyWindow)
{ return store.users[keyWindow].ids.map(userId => selectUserById(store, userId)); }
function fetchUsers({query}, keyWindow) { return { type: FETCH_USERS, query, keyWindow
}; } function fetchManagers() { return fetchUsers({query: {isManager: true}}, 'allManager'); } function receiveEntities(entities, keyWindow) { return { type: RECEIVE_ENTITIES, entities, keyWindow }; }
function reducer(state = defaultState, action) { switch(action.type) { case FETCH_USERS:
return { ...state, keyWindows: uniq([...state.keyWindows, action.keyWindow]), [action.keyWindow]: { ...state[action.keyWindow], isFetching: true, query: action.query } }; case RECEIVE_ENTITIES: return { ...state, byId: { ...state.byId, ...action.entities.users.byId }, keyWindows: uniq([...state.keyWindows, action.keyWindow]), [action.keyWindow]: { ...state[action.keyWindow], isFetching: false, ids: action.entities.users.ids } }; } }
function reducer(state = defaultState, action) { switch(action.type) { case FETCH_USERS:
return { ...state, keyWindows: uniq([...state.keyWindows, action.keyWindow]), [action.keyWindow]: { ...state[action.keyWindow], isFetching: true, query: action.query } }; case RECEIVE_ENTITIES: return { ...state, byId: { ...state.byId, ...action.entities.users.byId }, keyWindows: uniq([...state.keyWindows, action.keyWindow]), [action.keyWindow]: { ...state[action.keyWindow], isFetching: false, ids: action.entities.users.ids } }; } }
function selectUsersAreFetching(store, keyWindow) { return !!store.users[keyWindow].isFetching; } function selectManagersAreFetching(store) {
return selectUsersAreFetching(store, 'allManagers'); }
function reducer(state = defaultState, action) { switch(action.type) { case UPDATE_USER:
return { ...state, draftsById: { ...state.draftsById, [action.user.id]: action.user } }; case RECEIVE_ENTITIES: return { ...state, byId: { ...state.byId, ...action.entities.users.byId }, draftsById: { ...omit(state.draftsById, action.entities.users.byId) }, keyWindows: uniq([...state.keyWindows, action.keyWindow]), [action.keyWindow]: { ...state[action.keyWindow], isFetching: false, ids: action.entities.users.ids } }; } }
function reducer(state = defaultState, action) { switch(action.type) { case UPDATE_USER:
return { ...state, draftsById: { ...state.draftsById, [action.user.id]: action.user } }; case RECEIVE_ENTITIES: return { ...state, byId: { ...state.byId, ...action.entities.users.byId }, draftsById: { ...omit(state.draftsById, action.entities.users.byId) }, keyWindows: uniq([...state.keyWindows, action.keyWindow]), [action.keyWindow]: { ...state[action.keyWindow], isFetching: false, ids: action.entities.users.ids } }; } }
function selectUserById(store, userId) { return store.users.draftsById[userId] || store.users.byId[userId]; }
function reducer(state = defaultState, action) { switch(action.type) { case UNDO_UPDATE_USER:
return { ...state, draftsById: { ...omit(state.draftsById, action.user.id), } }; } }
Part 3: Scale
Rule: Keep dependencies low to keep the application fast
Reality: Use bundling to increase PERCEIVED performance
class Routes extends React.Component { render() { return ( <Switch>
<Route exact path="/" component={require(‘../home').default} /> <Route path="/admin" component={lazy(require(‘bundle-loader?lazy&name=admin!../admin’))} /> <Route component={PageNotFound} /> </Switch> ); } }
require('bundle-loader?lazy&name=admin!../admin’)
const lazy = loader => class extends React.Component { componentWillMount()
{ loader(mod => this.setState({ Component: mod.default ? mod.default : mod }) ); } render() { const { Component } = this.state; if (Component !== null) { return <Component {...this.props} />; } else { return <div>Is Loading!</div>; } } };
None
Rule: Render up-to-date data
Reality: If you got something render it, update it later
None
None
None
None
None
None
Epilog: Scale?
Rule: Scale is bytes served, users concurrent
Reality: Scale is responding to bytes served and users concurrent
How fast can you deploy?
None
Pre: Clear homebrew & yarn caches 1. Reinstall node &
yarn via brew 2. Clone repo 3. Run yarn install 4. Run production build 1. Compile & Minify CSS 2. Compile Server via Babel 3. Compile, Minify, & Gzip via Webpack 190.64s ~3 min
<Feature name="new-feature" fallback={<OldFeatureComponent />}> <NewFeatureComponent /> </Feature>
None
Team 1 Team 2 Merge Feature A Merge Feature B
Deploy Deploy OMG ROLLBACK DEPLOY!!! Merge Feature C Merge Bugfix for A Deploy Deploy BLOCKED!!! Deploy
Team 1 Team 2 Merge Feature A Merge Feature B
Deploy Deploy Rollout Flag A Rollout Flag B OMG ROLLBACK FLAG A!!! Merge Feature C Deploy Merge Bugfix for A Deploy Rollout Flag A Rollout Flag C
Can you optimize your directory structure around team responsibilities? If
teams are organized by “product domain”, Can you organize code around product domain?
Final Thoughts
Strict rules rarely 100% apply to your application. Remembering the
purpose behind the rules is valuable.
Code behavior should be predictable and intuitable. Be realistic about
the problem you’re actually solving.
You will not get it perfect the first time. Optimize
your processes for refactoring.
Questions?