React + Flux = Deadly Combination

Transcript

1. React + Flux = deadly combination
2. Who am I? • SFS • TUGM • CC • ARJSL
3. Who am I? • SFS (Senior Facebook Scroller) • TUGM (Twitter Usability Group Member) • CC (Caffeine Consumer) • ARJSL (All Round JS Lover)
4. Goals • Embarrass myself while talking about React and Flux • Help people learn/consolidate
6. React
7. “A JavaScript library for building user interfaces.” Facebook
8. React • People see React as the V in MVC • JSX (optional) • Forces a component based approach (remember directives?) • Server-side rendering (isomorphic apps) • Virtual DOM • Component lifecycle hooks • One way data flow (state, props)
9. JSX
12. JSX • Optional (you can write JS on your own) • Can be done in browser or at build time • In browser = SLOW (you need JSX transformer script) • Build time through Babel (or others)
13. Component based approach
15. Component based approach • Enforces modularity • Makes you think about the data flow from the beginning • Makes it easy to identify reusable components • Makes testing easier • Smart/Dumb
16. Virtual DOM
17. Virtual DOM • DOM operations are THE MOST EXPENSIVE thing you can do in JS • Minimizes that by working with an in-memory representation of the DOM (virtual) • Computes the minimal amount of changes • Batches updates to DOM • Borrowed concept from the gaming world
18. Component lifecycle hooks
19. Component lifecycle hooks • render() - mandatory • getInitialState() • componentWillMount() • componentDidMount() • componentWillReceiveProps() • shouldComponentUpdate() - friend and foe • componentWillUpdate() • componentDidUpdate() • componentWillUnmount()
20. One way data flow
21. One way data flow • State, props - generate component re-rendering • State is individual to a component • Props are passed down through component hierarchy • Keep state as high as possible • Pass everything to children via props: data, event handlers, etc. • Smart components are state aware • Dumb components are pure and predictable • Few Smarts, lots of Dumbs • Keep utils, data processing methods, business logic, etc. elsewhere
22. React approach and best practices
23. React approach • Reason about your application’s structure (routes included) • Clearly define your application’s state and what is the data flow • Identify components (macro/micro level or generic/specific) • Implement
24. React best practices • State as high as possible • Pass data down to components via props (handlers included) • XHR calls, event listeners (except Stores subscription) in componentDidMount() • Return null or false when you don’t want to render (cheap because of VDOM; don’t write custom logic or do dynamic component injection yourself) • render() must be pure • Use shouldComponentUpdate() only if you know what you’re doing • Always define types for your props • Make use of defaultProps when needed
26. React cons
27. React cons • State as high as possible means triggering render on large component trees • State inside components • Easy to run into “render storms” (coined and derived that from “paint storms” : D) • HTML in JS? (sry Paul, can’t do anything here…)
28. Can we do something about all that?
30. Flux
31. “Application architecture for building user interfaces.” Facebook
32. Flux • Is more of a pattern than a framework • It’s not “React specific” but they do complement each other • Proposes a unidirectional data flow model • Event based communication • Dispatcher, Stores, Views, Actions • Much like the human body
33. Watching a drama/romance movie on TV...
34. Switching to comedy....
35. Dispatcher
36. Dispatcher • It’s the central hub, that manages all data flow • A registry of callbacks • It’s dumb • His only purpose is to distribute the actions to the stores (forward logic) • As the application grows, it becomes vital (think custom logic, interceptor-like pattern from angular, manage dependencies and callbacks order, etc.)
37. Stores
38. Stores • Contain application state and logic • Manage multiple objects (domain driven) • Single source of truth for state (component/page/etc.) • Stores register themselves with the dispatcher and provide callbacks for different action types (the ones they are interested in) • After logic is executed, they broadcast an event declaring the state has changed (this impacts the view)
39. Views
40. Views • React components • More like Controller-Views because they provide the glue code to get data from stores and manage how that data is passed to their children • They listen to the stores’ events • When the event happens, they query the store for new data and re-render themselves (via setState())
41. Actions
42. Actions • Some data payload (simple JS objects that get forwarded to stores) • Usually wrapped in semantic helper methods, to make them easier to be called from within views • Eg: talkAboutReact(time, place) in a file called ReignActions.js • They also have a type, so they can be filtered out by stores • User interactions trigger actions (eg: button click then fetch new data) • Some actions may come from the server (eg: during initialization)
43. Recap now...
45. Reflux Fluxxor Redux etc.
46. https://github. com/r31gN/react-es6- starter-kit
47. “Keep on smiling. You are the most beautiful people when you do.” Reign
48. Thank you! @r31gN_