Things to Know before Building Large-scale React.js Application

Transcript

1. Things to Know before Building Large-scale React.js Application Dafeng Guo (郭达峰), CTO of Strikingly
2. Who am I? • 郭达峰 (dfguo) • Have been hacking since 14 • CTO of Strikingly
5. Y Combinator W13 Class
6. Strikingly 4 Re-architecture • We have a pretty complex frontend • Demo • Why did we still decide to re-architect our app using React.js? • performance • code organization
7. Before we start Let’s review what React.js is about
8. State management problem • Server-side rendering • Rails, Django, php • Fresh state every time but not interactive Why is it hard to manage the states? • Client-side two-way binding • Angular.js, Ember.js, Knockout • Interactive but complex to manage the states
9. • We always juggle between changing state and then changing DOM • State and DOM changes over time make it hard to synchronize How do we make DOM the exact reflection of states?
10. • What if we can re-render the DOM all the time, like backend rendering? • state tracking will not be a problem • but it’s horribly slow
11. Virtual DOM • Virtual DOM • Keep a copy of the DOM in javascript memory • When DOM needs to change, get the diff by comparing virtual DOM • Update the diff to the real DOM
12. Virtual DOM Just like game rendering
13. Pre-rendering • because DOM can be generated with javascript runtime, you can render React.js from backend • Isomorphic javascript - run the same javascript from backend and frontend
14. Testing • SLOW - Most annoying thing about integration test or any test that requires browser • FAST - React.js tests just need javascript runtime
15. • Faster DOM changes • Server-side rendering out of the box • Faster testing virtual DOM enables all these
16. • But virtual DOM is not everything. I talked about it because it’s easier to understand. • The core of React.js is to to allow: • UI = f(states) • write declarative code that manages application state and DOM together!!
17. Unidirectional Data Flow • UI as state machine • Given data, display UI: f(states) = UI • Not two-way, but one-way • Data flow from top to bottom, parent to child
18. Ok, now you know React.js! Thanks for listening!
19. Things to Know before Building Large-scale React.js Application
20. 1. Use Flux Let the data flow, baby
21. Flux • Facilitate the unidirectional data flow for React.js
22. • Why use Flux? • Help you reason with unidirectional data flow • Avoid bunch of callback and data passing between components. Extract commonly used states to Stores. Flux FAQs
23. • Is Store the Model in MVC? • Not quite • Manage multiple models that belong to a domain. • Read domain-driven development Flux FAQs
24. • Where do I put my async calls? • Best practice in the community is in the Action and dispatch SUCCESS and FAILURE events that Stores can listen to Flux FAQs
25. • Many Flux variations, which one do I choose? • Flux, Fluxxor, Fluxible, Reflux, Alt, Flummox, Marty.js, McFly, Lux and etc. • Many ways to evaluate: • # of downloads on NPM: Flux > Reflux > Alt • Coding style • Server-side rendering? Flux FAQs
26. Flux FAQs • My recommendation? • Flexible or Alt if you want server-side rendering • Reflux if you want to save time • I like Flux as it is • Get over it. It’s not the point.
27. 2. Use Immutable.js Your mind at peace
28. Immutable.js • Immutable - changes create new copy on every change • Persistent - old copies will be kept • Structural sharing - new/old objects shares memory
29. Immutable.js • Om • a clojure port of React.js • faster than React.js?! Why?
30. Immutable.js FAQs • What good does it bring? • high performant React.js application
31. Immutable.js FAQs • shouldComponentUpdate simplified (code example)
32. Immutable.js FAQs • What good does it bring? • Undo/redo out of the box
33. 3. Use JSX Template engines are DSL that limit the power of javascript
34. JSX • Yes, it looks ugly at first • Why separate HTML and Javascript • Designers write HTML and FE write JS • Which world do you live in? • HTML in javascript is ugly? • Let’s face it. View and javascript are already tightly coupled in highly customized application • Separation of concerns • You can break down to smaller components • Templating language is a DSL that’s less powerful and less expressive than JS • scoping, variable definition and everything the language has!
35. JSX • Templating language lets you do 80% of the thing. JSX lets you to do everything! • It’s the 20% that will make your user WOW! • But I still want to use a f****** template engine… • react-template
36. 4. Don’t be afraid of integrating jQuery 1 + 1 > 2
37. jQuery Integration • you can access DOM after the DOM has been mounted • componentDidMount • componentDidUpdate • and all the UI triggered DOM events • example • It’s really really really really really simple! • JFDI!
38. Wrapping up • Use Flux • Use Immutable.js • Use JSX • Don’t be afraid of integrating jQuery • …. but there is more, we will talk about it in the future • Use Webpack • Rethink about state ownership, should really be props + store all the way
39. Strikingly 正在招聘 ⼩小⼲⼴广告 React China
40. References • Pete Hunt’s Rethinking Best Practices: https:// www.youtube.com/watch?v=DgVS-zXgMTk • Immutability and React: https:// www.youtube.com/watch?v=I7IdS-PbEgI