$30 off During Our Annual Pro Sale. View Details »

React + Flux = Deadly Combination

React + Flux = Deadly Combination

r31gN_

July 25, 2016
Tweet

More Decks by r31gN_

Other Decks in Technology

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
  5. None
  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

  10. None
  11. None
  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

  14. None
  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
  25. None
  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?

  29. None
  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...

  44. None
  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_