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

060fffd6216660bf034bbdc68bec1dee?s=47 Dafeng
May 30, 2015

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



May 30, 2015


  1. 2.
  2. 3.
  3. 4.
  4. 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
  5. 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
  6. 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?
  7. 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
  8. 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
  9. 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
  10. 14.

    Testing • SLOW - Most annoying thing about integration test

    or any test that requires browser • FAST - React.js tests just need javascript runtime
  11. 15.

    • Faster DOM changes • Server-side rendering out of the

    box • Faster testing virtual DOM enables all these
  12. 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!!
  13. 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
  14. 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
  15. 23.

    • Is Store the Model in MVC? • Not quite

    • Manage multiple models that belong to a domain. • Read domain-driven development Flux FAQs
  16. 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
  17. 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
  18. 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.
  19. 28.

    Immutable.js • Immutable - changes create new copy on every

    change • Persistent - old copies will be kept • Structural sharing - new/old objects shares memory
  20. 30.
  21. 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!
  22. 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
  23. 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!
  24. 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
  25. 40.

    References • Pete Hunt’s Rethinking Best Practices: https:// •

    Immutability and React: https://