React – What and why?

von Jan Hansen (Kommentare: 0)

Countless posts have been done about react so here goes another one. :) React is a framework for developing web applications by Facebook. BUT unlike Angular or Ember.js or others it features ONLY the view layer. This cannot be stressed enough when talking about which framework to use for a new project. React does not offer an MVC pattern or similar things. There is no data layer, no connection libraries to the backend, no wrapper functions to ajax calls, no promises and so on. React does however feature some interesting view layer features and architecture ideas.


Contrary to other approaches react encourages you to put the DOM structure AND the JavaScript functions in the same file. But you're not supposed to do that? Always separate functionality and views! Well, to be honest, it is quite nice to have everything of one component (textfield or whatever) in one place. It reduces the danger of manipulating DOM structures from functions not clearly associated with that structure (Why does the class of this node change when I click the button? There is no such function in the button related scripts???)

See for more info.


In order to support you with this approach react features a syntax extension to JavaScript called JSX streamlining the creation of HTML+JavaScript. without JSX:

class Hello extends React.Component {
    render() {
        return React.createElement(‘div’, null, `Hello ${this.props.toWhat`);
    React.createElement(Hello, {toWhat: ‘World’}, null),

with JSX:

class Hello extends React.Component {
    render() {
         return <div>Hello {this.props.toWhat}></div>;
<Hello toWhat="World" />,

The weird looking string in the last render function

return <div>Hello {this.props.toWhat}></div>;

is neither HTML nor JavaScript, it's JSX. See for more info.

Why the flux?

State management in frontend proves to be difficult. What buttons are active? What list items are selected? How do I guarantee all my interactive elements honour the app state correctly? The traditional way could be to use observers, which trigger on a state change. But constructing a large app requires a large number of observers. Such a structure can get confusing and error-prone.

Further more performance issues may arise. React suggests a new approach to state management called flux. See for more information.

What the flux?

What's new? The basic idea is having just just universal data flow through the app. It's important to notice that flux is an idea, a design pattern not a framework. You can write an app using the flux idea on your own or your can use implementations of that pattern like redux or other.


A flux pattern uses the following components:

  • dispatcher
    • There is only one global dispatcher. It broadcasts events and registers callbacks.
  • actions
    • an JavaScript object containing what we want to do and the data
  • action creator
    • a wrapper for the creation of actions
  • store
    • singleton containing the  app state
    • there may be several stores containing a part of the entire app state
    • the ONLY structure that can "edit" the data (make a copy and change that copy)

The flow

  1. A user clicks an a button.
  2. The component uses the action creator to create and emit an action.
  3. The store "edits" the app state.
  4. The store triggers a change event.
  5. The view receives the change event and refreshes.

2 Things are important:

1 The store does not edit data directly. It ALWAYS create a new copy with the changed values. This is very important as the speed of react dirty checking depends on that.

Traditional edit array/object and dirty check:
  • References of arrays and objects are saved on the stack, the content is saved on the heap.
  • If an array/object has changed content, the dirty check has to traverse the  content .
  • Worst case: no change -> entire content has to be traversed
react always copy and dirty check
  • A new array/object has a new reference in the stack (different memory address) therefore the check is really simple and fast.
  • Libraries like immutable-js can help with the "always-copy-approach"

2 The change event received by the view does not contain WHAT data has been changed. Therefore the view has to re-render completely. Wait, what? That must be horrible for the performance. Virtual Dom to the rescue!

Virtual DOM

The virtual dom is an abstraction of the real DOM. The rendering function in the JSX part above creates a ReactComponent which is re-rendered with each app state change. Basically react transforms this component into a ReactElement. This element is inserted into the virtual DOM and diffed against an existing element. This results in updating only the parts in the real DOM that really changed. For more info see