The State of State Management in React 2017

These days, managing state in web applications is increasingly difficult. Frameworks like Angular, Ember or Aurelia have some mechanism for managing state built in. But what if you're using React? How do you know which state management solution is right for you? In this session, we'll survey the landscape for managing state in React applications, and walk through some of the more popular solutions, such as Redux and MobX, as well as alternatives like Vue, RxJS and Elm.

Transcript

1. The State of State Management in React Jonathan Kemp
2. Managing state is hard
3. What is state?
4. Storing State in the DOM
5. MV-Whatever
6. Bidirectional Data Flow
7. Side effects
8. What are the Costs?
9. Costs - Hard to predict - Performance, memory, efficiency - Large JS payloads
10. React
11. React State
12. React Components - Class components have the ability to maintain internal state. - Functional components do not manage state.
13. 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> ); } }
14. What goes in state?
15. Unidirectional Data Flow
16. Because Performance
17. Easier to Reason About
18. Do Not Modify State Directly
19. Lifting State Up
20. Single source of truth
21. Reduce bugs
22. Example
23. Summary of React State - Data used for the visual output is stored in state - Unidirectional Data Flow - Performance, Easier to Reason about, Reduce Bugs
24. Flux
25. Unidirectional Data Flow
26. Flux Applications have three major parts: 1. the dispatcher 2. the stores 3. the views (React components)
27. Flux Data Flow
28. Flux Data Flow
29. Data Flow - Controller-views listen for these events and retrieve data from the stores in an event handler. - Views update themselves and all of their descendants.
30. Benefits of Flux - Makes it easy to reason about complex data changes - Opens up possibilities impossible with classic MVC, such as recording and replaying UI state - Easy Testability
31. Do I Need Flux?
32. Notable Flux implementations 1. Flummox 2. Alt 3. Fluxible 4. Reflux . . .
33. Changes in Flux pattern evolution - Have the action creators return the dispatched action. - Making the store stateless, a function telling the initial state and how the subsequent actions transform it.
34. Benefits 1. Stores and actions are just pure functions. 2. Hot reloading. 3. Easy transactions (history).
35. Redux
36. Reducers
37. 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()) );
38. store.dispatch({ type: 'INCREMENT' }) // 1 store.dispatch({ type: 'INCREMENT' }) // 2 store.dispatch({ type: 'DECREMENT' }) // 1
39. Things to understand:
40. Everything that happens in your app is an “action”.
41. One giant state object represents all the state in your app
42. You write “reducers” for everything that changes state
43. Transactional, deterministic state management
44. Do amazing things
45. Example
46. React not required
47. –Eric Elliott “Redux is mandatory learning, even if you never use Redux for a production project.”
48. Criticism - Too much boilerplate - Unnecessary complexity
49. Functional Reactive Programming
50. The introduction to Reactive Programming You've been missing
51. Actions = Event streams
52. Dumb Components
53. No need for separate actions and stores
54. Bacon.js / RxJS
55. MobX
56. The philosophy behind MobX
57. Core Concepts of MobX
58. Observable state
59. Computed values
60. Reactions
61. Actions
63. Becoming Reactive
64. Decorators
65. Observable state
66. MobX + React
67. 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();
68. @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);
69. More on Actions
70. Example
71. MobX is not a state container
72. Summary
73. Use the @observable decorator
74. The @computed decorator
75. Use the @observer decorator
76. Use @action to update state
77. MobX is simpler
78. Other Alternatives - Vue - Cycle.js - Elm - No framework
79. Vue.js
80. var app = new Vue({ el: '#app', data: { list: [] }, methods: { addTodo: function () { var input = document.getElementById('update'); this.list = this.list.concat(input.value); } } });
81. State management
82. Veux
83. Veux != Redux
84. Example
85. Cycle.js
86. Functional and Reactive
87. Simple and Concise
88. Cycle.js Supports - Virtual Dom Rendering - Server Side Rendering - JSX, Typescript - React Native - Time Traveling - Routing with the history API - And more
89. Learn it in 1h 37min https://egghead.io/courses/cycle-js-fundamentals
90. Elm
91. Features - Functional programming - pure function, immutable data - Statically typed - Compiler - descriptively tell what went wrong and in some cases even suggest a solution
92. No framework
93. React 16? (previously codenamed “Fiber”)
94. Jonathan Kemp @jonkemp https://github.com/jonkemp
95. Jonathan Kemp CodePen - https://codepen.io/jonkemp/pens/public/ Slides - https://speakerdeck.com/jonkemp