I recently decided to check out Facebook Flux. At first, I was a bit confused: I assumed it was a library or framework, but it's actually a pattern for organizing the components that make up your web application (as well as a library, Dispatcher, that fills part of the pattern). There are several implementations of the different components needed to use the Flux pattern. However, to get a better understanding of Flux, I implemented the pattern myself. If you've checked out Flux and found it a bit confusing, maybe this will help.

Here's the data flow diagram that explains the Flux pattern:

Views  <--------------------------------------------------+
  -> (actions)                                            |
    -> Dispatcher                                         |
      -> (registered callback)                            |
        -> Stores                                         |
          -> (Stores emit "change" events)                |
            -> (Controller-Views "change" event handlers)-+

The part of the pattern that the Flux repository offers is the dispatcher, so let's start there. It's actually a very simple system: we can register callbacks that will be run when the dispatcher receives data (called a payload). Yeah, I thought it sounded a lot like pubsub, too. However, according to a comment in the code, there are two differences:

1) Callbacks are not subscribed to particular events. Every payload is dispatched to every registered callback.
2) Callbacks can be deferred in whole or part until other callbacks have been executed.

I'm not yet sure why these are important; the simple example I built will only handle point 1. So, here's how I implemented an extremely simple dispatcher:

var dispatcher = [];
dispatcher.register = dispatcher.push;
dispatcher.dispatch = function (payload) {
  this.forEach(function (fn) {
    fn(payload);
  });
};

It's actually just an array with an extra method, dispatch. The method takes a payload, loops over the array, and calls each function in the array. Also, we alias push to register.

Next, let's look at Stores. Stores only have two jobs. The first is obvious: it needs to manage data records (like Collections and Models in a Backbone app). The second job is to allow Controller-Views to listen for changes to the store, so they can update accordingly. Here's a really simple store for storing to-do list items:

var TodoStore = (function () {
  var _id = 1;
  var todos = [];
  var callbacks = [];

  function change() {
    callbacks.forEach(function (fn) {
      fn(); 
    });
  }

  return {
    getAll: function () {
      return todos;
    },
    create: function (data) {
      todos.push({
        id: _id++,
        text: data.text
      });
      change();
    },
    destroy: function (id) {
      todos = todos.filter(function (item) {
        return item.id !== id;
      });
      change();
    },
    onChange: function (fn) {
      callbacks.push(fn);
    }
  };
}());

Note the onChange method, which allows us to register callbacks, and the change method, which calls each of the callbacks after performing an operation (only create or destroy, in this example).

Let's go back to the dispatcher for a second. The way a dispatcher works is that all registered callbacks will receive each payload. Therefore, we need a way distinguish between types of payloads. All the Flux examples I've seen have done this through a property on the payload object. Then, we can perform different operations depending on the payload type. Here's how this could be done:

dispatcher.register(function (payload) {
  if (payload.type === 'CREATE_TODO') {
    TodoStore.create(payload.data);
  }
  if (payload.type === 'REMOVE_TODO') {
    TodoStore.destroy(payload.data.id);
  }
});

Now, if you look back at the diagram, you can see that the registered callbacks on the dispatcher will be called from the views. We could directly dispatch the payload from the views, but it's likely that in more advanced apps more things will be going on. This is where the "actions" part of the diagram comes in: actions are helper functions that will do the dispatching for us. For now, we'll just create two actions: one for creating new todos, and one for destroying todos.

var TodoActions = {
  create: function (text) {
    dispatcher.dispatch({
      type: 'CREATE_TODO',
      data: {
        text: text
      }
    });
  },
  destroy: function (id) {
    dispatcher.dispatch({
      type: 'REMOVE_TODO',
      data: {
        id: id 
      } 
    });
  }
};

As you can see, these helper functions will just take whatever information is required (the todo text, or the todo id), create the appropriate payload, and dispatch said payload.

The last part of the Flux pattern is the views. Facebook, of course, recommends that you use React (and you should check it out; I really like it), but you don't have to. I rolled some very simple views for this example:

function listView () {
  var el = document.createElement('ul');

  function fill () {
    el.innerHTML = '';
    TodoStore.getAll().forEach(add);
  }

  function handleClick(evt) {
    TodoActions.destroy(parseInt(evt.target.id, 10));
  }

  function add (item) {
    var li = document.createElement('li');
    li.id = item.id;
    li.innerText = item.text;

    li.addEventListener('click', handleClick, false);
    el.appendChild(li);
  }  

  fill();
  TodoStore.onChange(fill);

  return el;
}

function formView() {
  var el = document.createElement('input');

  el.addEventListener('change', function (evt) {
    TodoActions.create(evt.target.value);
    evt.target.value = '';
  }, false);

  return el;
}

var main = document.getElementById('main');
var form = formView();
var list = listView();

main.appendChild(form);
main.appendChild(list);

And that's the whole Flux pattern. You can see the example on JSBin. Obviously, in a real web app, things would be quite a bit different, but hopefully this helps you understand the components involved in the Flux architecture.