Scaling

Making changes to your applications can often be a daunting task. Especially changing the UI. With the strategies and patterns explained in this WIKI you can move any component to any part of your UI as it does only depend on your storage and the event hub.

But lets take a look at the previous example, where we had our addTodo function. We have decided to trigger a notification whenever a todo is added successfully or an error occurs. This means that our "addTodo" event has two different jobs. Lets see how we would scale this.

In addition to the three basic concepts, Storage, Event hub and Components, you will need business logic. This is the part that controls the state of your application. The business logic can listen to events triggered by components and it can reach into the storage to change the state.

Let us imagine we want to add new todos. When doing so we want to post them to the server and control the, pending, success and error of that operation.

We do not want to add this logic in our addTodo function, because that is not its job. What we want to do is to get a good overview of what actually happens when the event triggers.

main.js

var React = require('react');
var events = require('./events.js');
var App = require('./App.jsx');
var addTodo = require('./addTodo.js');
var notify = require('./notify.js');

// Since our addTodo function returns a promise we pass that
// to our notifier, setting a success and error message
events.on('addTodo', function (title) {
  notify(addTodo(title), {
    success: 'New todo added',
    error: 'Could not add new todo'
  });
});

React.render(<App/>, document.body);

The point of this example is to show how you think about scaling. Split up the logic and try at the best of your ability to give an overview of what happens when an event triggers. This makes your application code readable, as all intents to change state goes through this one file.