Cross-Framework Patterns in State Management

These days, managing state in front end applications is increasingly difficult. Depending on the approach to this problem, how do you know which front end framework is right for you? In this session, we'll survey the landscape for managing state in front end applications, and compare state management patterns in two of the major front end frameworks, React and Vue.

Transcript

1. CROSS-FRAMEWORK PATTERNS IN STATE MANAGEMENT JONATHAN KEMP
3. IF YOU’RE WORKING WITH REACT OR VUE AND YOU’RE FRUSTRATED WITH STATE MANAGEMENT PROBLEMS, YOU’RE NOT ALONE.
4. THROUGH EXPOSURE TO STATE MANAGEMENT PATTERNS ACROSS DIFFERENT FRAMEWORKS
5. YOU’LL GAIN MORE INSIGHT INTO PROBLEMS WITH STATE MANAGEMENT AND HOW THEY CAN BE SOLVED IN DIFFERENT WAYS.
6. OVERVIEW •What is State? •Two Frameworks •Common patterns
7. MANAGING STATE IS HARD
9. WHAT IS STATE?
10. BACK END DATA + UI STATE
11. STATE IS DATA IN YOUR APPLICATION THAT CHANGES OVER TIME
12. A COMMON BEST PRACTICE IS TO ONLY PUT DATA INTO STATE THAT IS REPRESENTED IN THE VIEWS.
13. WHAT IS STATE MANAGEMENT?
14. HOW TO MANAGE STATE, WHICH IS THE DATA REPRESENTED IN THE VIEW LAYER OF THE APPLICATION
15. WHAT ARE THE DIFFERENT APPROACHES TO STATE MANAGEMENT?
16. TWO FRAMEWORKS REACT + VUE
17. REACT
18. COMPONENT BASED UI
19. REACT STATE
20. class Clock extends React.Component { constructor(props) { super(props); this.state = {date: new Date()}; } render() { return ( <div> <h1>Hello, world!</h1> <h2>It is {this.state.date.toLocaleTimeString()}.</h2> </div> ); } }
21. WHAT GOES IN STATE?
22. UNIDIRECTIONAL DATA FLOW
23. EASIER TO REASON ABOUT
24. DO NOT MODIFY STATE DIRECTLY
25. class TodoApp extends React.Component { constructor(props) { super(props); ... this.state = { items: [], text: '' }; } onChange(e) { this.setState({text: e.target.value}); }
26. SINGLE SOURCE OF TRUTH
27. LIFTING STATE UP
28. LIFTING STATE UP => REDUCE BUGS
29. EXAMPLE
30. SUMMARY OF REACT STATE •Data used for the visual output is stored in state •Unidirectional Data Flow •Performance, Easier to Reason about, Reduce Bugs
31. FLUX
32. WITH FLUX, THE APPLICATION STATE LIVES OUTSIDE OF THE UI-COMPONENTS, IN THE STORE(S).
33. THE CENTRAL IDEA OF THE FLUX PATTERN IS UNIDIRECTIONAL DATA FLOW
34. FLUX PARTS •Dispatcher •Store •Action •View
35. DATA FLOW •Views send actions to the dispatcher. •The dispatcher sends actions to every store. •Stores send data to the views.
36. REDUX
37. REDUX HELPS MANAGE STATE IN YOUR APPLICATIONS BY MAKING STATE CHANGES MORE PREDICTABLE.
38. THREE PRINCIPLES OF REDUX 1. Single source of truth 2. State is read-only 3. Changes are made with pure functions
39. PURE FUNCTIONS
40. PURE FUNCTIONS •Given the same input, will always return the same output. •Produces no side effects (does not alter or depend on any external state).
41. REDUCERS
42. THINGS TO UNDERSTAND:
43. ONE GIANT STATE OBJECT REPRESENTS ALL THE STATE IN YOUR APP
44. EVERYTHING THAT HAPPENS IN YOUR APP IS AN “ACTION”.
45. YOU WRITE “REDUCERS” FOR EVERYTHING THAT CHANGES STATE
46. TRANSACTIONAL, DETERMINISTIC STATE MANAGEMENT
47. DO AMAZING THINGS
48. function counter(state = 0, action) { switch (action.type) { case 'INCREMENT': return state + 1; case 'DECREMENT': return state - 1; default: return state; } } let store = createStore(counter); store.subscribe(() => console.log(store.getState()) );
49. store.dispatch({ type: 'INCREMENT' }) // 1 store.dispatch({ type: 'INCREMENT' }) // 2 store.dispatch({ type: 'DECREMENT' }) // 1
50. REDUCER COMPOSITION
51. export default theDefaultReducer = (state = 0, action) => state; export const firstNamedReducer = (state = 1, action) => state; export const secondNamedReducer = (state = 2, action) => state; const rootReducer = combineReducers({ theDefaultReducer, firstNamedReducer, secondNamedReducer }); const store = createStore(rootReducer); console.log(store.getState()); // {theDefaultReducer : 0, firstNamedReducer : 1, secondNamedReducer : 2}
52. EXAMPLE
53. CRITICISM •Too much boilerplate •Unnecessary complexity
54. AUTODUX https://github.com/ericelliott/autodux
55. AUTOMATE THE REDUX BOILERPLATE
56. EXAMPLE
57. IMMUTABILITY
58. IMMER https://github.com/mweststrate/immer
59. IMMUTABILITY IN REACT AND REDUX
60. import produce from "immer" const baseState = [ { todo: "Learn typescript”, done: true }, { todo: "Try immer”, done: false } ] const nextState = produce(baseState, draftState => { draftState.push({todo: "Tweet about it"}) draftState[1].done = true })
61. CONTEXT https://reactjs.org/docs/context.html
62. CONTEXT PROVIDES A WAY TO PASS DATA THROUGH THE COMPONENT TREE WITHOUT HAVING TO PASS PROPS DOWN THROUGH EVERY LEVEL
63. class App extends React.Component { render() { return <Toolbar theme="dark" />; } } function Toolbar(props) { return ( <div> <ThemedButton theme={props.theme} /> </div> ); } function ThemedButton(props) { return <Button theme={props.theme} />; }
64. const ThemeContext = React.createContext('light'); class App extends React.Component { render() { return ( <ThemeContext.Provider value="dark"> <Toolbar /> </ThemeContext.Provider> ); } }
65. // A component in the middle doesn't have to // pass the theme down explicitly anymore. function Toolbar(props) { return ( <div> <ThemedButton /> </div> ); } function ThemedButton(props) { return ( <ThemeContext.Consumer> {theme => <Button {...props} theme={theme} />} </ThemeContext.Consumer> ); }
66. EXAMPLE
67. REACT CONTEXT ISN'T FOR STATE MANAGEMENT
68. UNSTATED https://unstated.io
69. MANAGE STATE WITHOUT ALL THE CEREMONY (FLUX) AROUND STATE MANAGEMENT IN REACT
70. UNSTATED IS DESIGNED TO BUILD ON TOP OF THE PATTERNS ALREADY SET OUT BY REACT COMPONENTS AND CONTEXT.
71. import React from 'react'; import { render } from 'react-dom'; import { Provider, Subscribe, Container } from 'unstated'; class CounterContainer extends Container { state = { count: 0 }; increment() { this.setState({ count: this.state.count + 1 }); } decrement() { this.setState({ count: this.state.count - 1 }); } }
72. function Counter() { return ( <Subscribe to={[CounterContainer]}> {counter => ( <div> <button onClick={() => counter.decrement()}>-</button> <span>{counter.state.count}</span> <button onClick={() => counter.increment()}>+</button> </div> )} </Subscribe> ); } render( <Provider> <Counter /> </Provider>, document.getElementById('root') );
73. MOBX
74. MOBX IS INFLUENCED BY OBJECT- ORIENTED PROGRAMMING, BUT ALSO BY REACTIVE PROGRAMMING
75. MOBX WRAPS YOUR STATE INTO OBSERVABLES
76. YOU CAN LISTEN TO AN OBSERVABLE AND AUTOMATICALLY TRACK CHANGES THAT OCCUR TO THE DATA
77. MOBX USES MULTIPLE STORES
78. @OBSERVABLE, @COMPUTED DECORATORS
79. MOBX + REACT
80. class ObservableTodoStore { @observable todos = []; constructor() { mobx.autorun(() => console.log(this.report)); } addTodo(task) { this.todos.push({ task: task, completed: false, assignee: null }); } } const observableTodoStore = new ObservableTodoStore();
81. @observer class TodoList extends React.Component { render() { const store = this.props.store; return ( <ul> {store.todos.map(todo => ( <li key={todo.id}>{todo.text}</li> ))} </ul> ); } } ReactDOM.render(<TodoApp store={ observableTodoStore } />, mountNode);
82. IN MOBX YOUR STATE IS MUTABLE THUS YOU MUTATE THE STATE DIRECTLY
83. IT IS A BEST PRACTICE THOUGH TO KEEP YOUR STATE MUTATIONS MORE EXPLICIT WITH ACTIONS
84. ACTIONS MODIFY THE STATE
85. ENFORCEACTIONS FORCES YOU TO USE ACTIONS TO UPDATE SO IT IS NO LONGER MUTABLE
86. class ObservableTodoStore { @observable todos = []; constructor() { mobx.autorun(() => console.log(this.report)); } @action.bound addTodo(task) { this.todos.push({ task: task, completed: false, assignee: null }); } } const observableTodoStore = new ObservableTodoStore();
87. MORE ON ACTIONS •Actions should always be used on functions that modify state. •Using actions yields performance benefits •action provides useful debugging information with devtools. •Strict mode enforces all state modifications are done by an action.
88. EXAMPLE
89. MOBX IS NOT A STATE CONTAINER
90. MOBX IS SIMPLER
91. VUE.JS
92. A PROGRESSIVE FRAMEWORK FOR BUILDING USER INTERFACES
93. STATE MANAGEMENT IS SIMPLE AND INTUITIVE
94. var app = new Vue({ el: '#app', data: { list: [] }, methods: { addTodo: function () { var input = document.getElementById('update'); this.list = this.list.concat(input.value); } } });
95. VUE STATE IS MUTABLE
96. VUE USES A NEARLY IDENTICAL REACTIVITY SYSTEM TO MOBX
97. VUE COMPONENTS
98. COMPONENTS CAN PASS DATA TO CHILD COMPONENTS THROUGH PROPS
99. VUE ENFORCES A ONE-WAY DATA FLOW BETWEEN COMPONENTS
100. COMMUNICATE BETWEEN COMPONENTS USING EVENTS
101. COMPONENTS CAN ALSO SEND DATA TO THE PARENT THROUGH EVENTS
102. A GLOBAL EVENT BUS ALLOWS US TO EMIT AN EVENT IN ONE COMPONENT AND LISTEN FOR THAT EVENT IN ANOTHER
103. var eventHub = new Vue() // NewTodoInput methods: { addTodo: function () { eventHub.$emit('add-todo', { text: this.newTodoText }) this.newTodoText = '' } } // Todos created: function () { eventHub.$on('add-todo', this.addTodo) eventHub.$on('delete-todo', this.deleteTodo) },
104. CAN BE CONVENIENT FOR VERY SIMPLE CASES, BUT ARE NOT APPROPRIATE FOR MOST APPLICATIONS
105. EXAMPLE
106. SIMPLE GLOBAL STORE
107. SIMPLE STATE MANAGEMENT CAN BE PERFORMED BY CREATING A STORE PATTERN THAT INVOLVES SHARING A DATA STORE BETWEEN COMPONENTS
108. THE STORE CAN MANAGE THE STATE OF OUR APPLICATION AS WELL AS THE METHODS THAT ARE RESPONSIBLE IN CHANGING THE STATE
109. export const store = { state: { numbers: [1, 2, 3] }, addNumber(newNumber) { this.state.numbers.push(newNumber); } };
110. <template> <div> <h2>{{ storeState.numbers }}</h2> </div> </template> <script> import { store } from "../store.js"; export default { name: “NumberDisplay", data() { return { storeState: store.state }; } }; </script>
111. <template> <div> <input v-model="numberInput" type="number" /> <button @click="addNumber(numberInput)"> Add new number </button> </div> </template>
112. import { store } from "../store.js"; export default { name: "NumberSubmit", data() { return { numberInput: 0 }; }, methods: { addNumber(numberInput) { store.addNumber(Number(numberInput)); } } };
113. THANKS TO VUE’S REACTIVITY, WHENEVER DATA IN STORE STATE GETS CHANGED, THE RELEVANT DOM THAT DEPENDS ON THIS VALUE AUTOMATICALLY UPDATES
114. COMPONENTS AREN’T INTERACTING WITH EACH OTHER BUT INSTEAD INVOKE CHANGES TO ONE ANOTHER THROUGH THE STORE
115. VUEX https://vuex.vuejs.org/
116. VUEX IS A STATE MANAGEMENT PATTERN + LIBRARY FOR VUE.JS APPLICATIONS
117. ENSURES THAT THE STATE CAN ONLY BE MUTATED IN A PREDICTABLE FASHION
118. INSPIRED BY FLUX , REDUX AND THE ELM ARCHITECTURE
119. INTEGRATES WITH VUE •Official devtools extension to provide advanced features •Zero-config time-travel debugging •State snapshot export/import
120. VUEX USES A SINGLE STATE TREE
121. SERVES AS A CENTRALIZED STORE FOR ALL THE COMPONENTS IN AN APPLICATION
122. VUE COMPONENTS REACTIVELY AND EFFICIENTLY UPDATE IF THE STORE'S STATE CHANGES
123. THE ONLY WAY TO ACTUALLY CHANGE STATE IN A VUEX STORE IS BY COMMITTING A MUTATION
124. (YOU CANNOT DIRECTLY CALL A MUTATION HANDLER)
125. TO INVOKE A MUTATION HANDLER, YOU NEED TO CALL STORE.COMMIT WITH ITS TYPE
126. EXAMPLE
127. COMPARISON WITH REDUX •Unlike Redux, Vuex mutates the state •Rather than actions, the only way to change the state tree in Vuex is with Mutations. •Instead of breaking down state logic with specialized reducers, Vuex is able to organize its state logic with stores called modules.
128. COMMON PATTERNS •Unidirectional data flow •Lifting state up •Single source of truth •Centralized store
129. FUNCTIONAL PROGRAMMING •Pure functions •Immutability
130. MOBX => VUE
131. REDUX => VUEX
132. JONATHAN KEMP @jonkemp https://github.com/jonkemp
133. JONATHAN KEMP CODESANDBOX - HTTPS://CODESANDBOX.IO/U/JONKEMP SLIDES - HTTPS://SPEAKERDECK.COM/JONKEMP