• Origin - XHP
  • No framework, UI Library, just the UI, the “View” of MVC.
  • Components.  Component-driven development.
  • Introduce the concept of Virtual DOM.
  • Uni-directional data flow.
  • Implementation - Client and server side.
  • JSX - Mixing HTML + JS
  • React doesn't have:
    • ... Controllers
    • ... Directives
    • ... Templates
    • ... Global events
    • ... Models
    • ... View Models
  •  Just Components
  • Separation of concerns for Conponents

How to use it?

  • In-browser transform
    • Using vanilla javascript directly
    • Using Babel transpiler - JSX
  • Build-time
    • Browserify
    • Webpack



  • Modular, reusable and composable
  • Parent/ children
  • Properties (Props).
    • Simple or JSON blob
    • Immutable
    • Validation by “propTypes”
    • Only change these by state.
  • State
    • ​Mutable
    • Here the changes.


  • Lifecycle
    • Mounting: A component is being inserted into the DOM.
      • getInitialState()
      • componentWillMount()
      • componentDidMount()
    • Updating: A component is being re-rendered to determine if the DOM should be updated.
      • componentWillReceiveProps(object nextProps)
      • shouldComponentUpdate(..)
      • componentWillUpdate(...)
      • ​componentDidUpdate(...)
    • Unmounting: A component is being removed from the DOM.
      • componentWillUnmount()

Virtual DOM

  • New concept, least amount of DOM manipulation. 
  • React uses a fake DOM, in memory. Two important things
    • when data has changed. (Observer model)
    • which DOM element(s) to be updated.

Virtual DOM

  • VDOM run “diffing” algorithm, later "reconciliation" to update the real DOM.
  • HTML markup contains data-reactid attributes to tracking DOM nodes

Virtual DOM


Example (ES6)



 Isomorphic App with React

  • Integration with Node
  • Shared JS that runs on both the client & server
  • Better overall user experience. Eliminate the FOUC
  • Search engine indexable
  • Easier code maintenance
  • Free progressive enhancements



  • Architecture that Facebook uses internally when working with React.
  • Components
    1. Actions
    2. Dispatcher
    3. Stores
    4. Controller-Views & Views

- Dispacher

  • It is basically the manager of this entire process.
  • Central Hub.
  • Receives Actions.
  • Callbacks.
  • Dependencies and marshall the callbacks on our Stores.
  • The Dispatcher’s waitFor method.
  • Manage the data, data retrieval methods and dispatcher callbacks. (Per app section)
  • Extend our store with EventEmitter. This allows our stores to listen/broadcast events
  • It Works with AppDispatcher broadcasts.

- Stores

  • Action Creators are collections of methods that are called within views to send actions to the Dispatcher.
  • Actions are the actual payloads that are delivered via the dispatcher.

- Actions

  •  Really just React components that listen to change events and retrieve Application state from Stores
  •  Pass that data down to their child components via props.

- Views

- All together

What do we should consider?

  • Popularity and support.
  • Stability.
  • Community.
  • Simplicity.
  • Functionality.
  • Documentation.
  • Github statistics.
  • Size & Fast.
  • Tied to React.
  • Can easily be used with ES5 and ES6.

Flux implementations

 Created by Dan Abramov

  • Dev tools - Hot reloading & time travel debugging
  • It is not that different from Flux.
  • Overall it's the same architecture.
  • Cut some complexity by using functional composition.
  • Single store (whole state of your app).
  • Reducers (Specify how the actions transform the state)
  • Containers & Components/ View layer binding.
  • Not have the concept of a Dispatcher.

 The Gist

  • The whole state of your app is stored in an object tree inside a single store.

  • The only way to change the state tree is to emit an action, an object describing what happened.

  • To specify how the actions transform the state tree, you write pure reducers.

    That’s it!