diff --git a/docs/_posts/2014-05-06-flux.md b/docs/_posts/2014-05-06-flux.md index a852ab380dc..688c5c45053 100644 --- a/docs/_posts/2014-05-06-flux.md +++ b/docs/_posts/2014-05-06-flux.md @@ -14,4 +14,4 @@ In Flux, the Dispatcher is a singleton that directs the flow of data and ensures When a user interacts with a React view, the view sends an action (usually represented as a JavaScript object with some fields) through the dispatcher, which notifies the various stores that hold the application's data and business logic. When the stores change state, they notify the views that something has updated. This works especially well with React's declarative model, which allows the stores to send updates without specifying how to transition views between states. -Flux is more of a pattern than a formal framework, so you can start using Flux immediately without a lot of new code. An [example of this architecture](https://github.com/facebook/react/tree/master/examples/todomvc-flux) is available, along with more [detailed documentation](http://facebook.github.io/react/docs/flux-overview.html) and a [tutorial](http://facebook.github.io/react/docs/flux-todo-list.html). Look for more examples to come in the future. +Flux is more of a pattern than a formal framework, so you can start using Flux immediately without a lot of new code. An [example of this architecture](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) is available, along with more [detailed documentation](http://facebook.github.io/react/docs/flux-overview.html) and a [tutorial](http://facebook.github.io/react/docs/flux-todo-list.html). Look for more examples to come in the future. diff --git a/docs/docs/flux-overview.md b/docs/docs/flux-overview.md index e02339401b3..c93feee34e2 100644 --- a/docs/docs/flux-overview.md +++ b/docs/docs/flux-overview.md @@ -29,67 +29,67 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores --- +-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+ -A unidirectional data flow is central to the Flux pattern, and in fact Flux takes its name from the Latin word for flow. In the above diagram, the dispatcher, stores and views are independent nodes with distinct inputs and outputs. The actions are simply discrete, semantic helper functions that facilitate passing data to the dispatcher. +A unidirectional data flow is central to the Flux pattern, and in fact Flux takes its name from the Latin word for flow. In the above diagram, the dispatcher, stores and views are independent nodes with distinct inputs and outputs. The actions are simply discrete, semantic helper functions that facilitate passing data to the dispatcher. All data flows through the dispatcher as a central hub. Actions most often originate from user interactions with the views, and are nothing more than a call into the dispatcher. The dispatcher then invokes the callbacks that the stores have registered with it, effectively dispatching the data payload contained in the actions to all stores. Within their registered callbacks, stores determine which actions they are interested in, and respond accordingly. The stores then emit a "change" event to alert the controller-views that a change to the data layer has occurred. Controller-views listen for these events and retrieve data from the stores in an event handler. The controller-views call their own `render()` method via `setState()` or `forceUpdate()`, updating themselves and all of their children. -This structure allows us to reason easily about our application in a way that is reminiscent of functional reactive programming, or more specifically data-flow programming or flow-based programming, where data flows through the application in a single direction — there are no two-way bindings. Application state is maintained only in the stores, allowing the different parts of the application to remain highly decoupled. Where dependencies do occur between stores, they are kept in a strict hierarchy, with synchronous updates managed by the dispatcher. +This structure allows us to reason easily about our application in a way that is reminiscent of functional reactive programming, or more specifically data-flow programming or flow-based programming, where data flows through the application in a single direction — there are no two-way bindings. Application state is maintained only in the stores, allowing the different parts of the application to remain highly decoupled. Where dependencies do occur between stores, they are kept in a strict hierarchy, with synchronous updates managed by the dispatcher. We found that two-way data bindings led to cascading updates, where changing one object led to another object changing, which could also trigger more updates. As applications grew, these cascading updates made it very difficult to predict what would change as the result of one user interaction. When updates can only change data within a single round, the system as a whole becomes more predictable. -Let's look at the various parts of the Flux update cycle up close. A good place to start is the dispatcher. +Let's look at the various parts of the Flux update cycle up close. A good place to start is the dispatcher. -### A Single Dispatcher +### A Single Dispatcher -The dispatcher is the central hub that manages all data flow in a Flux application. It is essentially a registry of callbacks into the stores. Each store registers itself and provides a callback. When the dispatcher responds to an action, all stores in the application are sent the data payload provided by the action via the callbacks in the registry. +The dispatcher is the central hub that manages all data flow in a Flux application. It is essentially a registry of callbacks into the stores. Each store registers itself and provides a callback. When the dispatcher responds to an action, all stores in the application are sent the data payload provided by the action via the callbacks in the registry. As an application grows, the dispatcher becomes more vital, as it can manage dependencies between stores by invoking the registered callbacks in a specific order. Stores can declaratively wait for other stores to finish updating, and then update themselves accordingly. -### Stores +### Stores -Stores contain the application state and logic. Their role is somewhat similar to a model in a traditional MVC, but they manage the state of many objects — they are not instances of one object. Nor are they the same as Backbone's collections. More than simply managing a collection of ORM-style objects, stores manage the application state for a particular __domain__ within the application. +Stores contain the application state and logic. Their role is somewhat similar to a model in a traditional MVC, but they manage the state of many objects — they are not instances of one object. Nor are they the same as Backbone's collections. More than simply managing a collection of ORM-style objects, stores manage the application state for a particular __domain__ within the application. -For example, Facebook's [Lookback Video Editor](https://facebook.com/lookback/edit) utilized a TimeStore that kept track of the playback time position and the playback state. On the other hand, the same application's ImageStore kept track of a collection of images. The TodoStore in our [TodoMVC example](https://github.com/facebook/react/tree/master/examples/todomvc-flux) is similar in that it manages a collection of to-do items. A store exhibits characteristics of both a collection of models and a singleton model of a logical domain. +For example, Facebook's [Lookback Video Editor](https://facebook.com/lookback/edit) utilized a TimeStore that kept track of the playback time position and the playback state. On the other hand, the same application's ImageStore kept track of a collection of images. The TodoStore in our [TodoMVC example](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) is similar in that it manages a collection of to-do items. A store exhibits characteristics of both a collection of models and a singleton model of a logical domain. -As mentioned above, a store registers itself with the dispatcher and provides it with a callback. This callback receives the action's data payload as a parameter. The payload contains a type attribute, identifying the action's type. Within the store's registered callback, a switch statement based on the action's type is used to interpret the payload and to provide the proper hooks into the store's internal methods. This allows an action to result in an update to the state of the store, via the dispatcher. After the stores are updated, they broadcast an event declaring that their state has changed, so the views may query the new state and update themselves. +As mentioned above, a store registers itself with the dispatcher and provides it with a callback. This callback receives the action's data payload as a parameter. The payload contains a type attribute, identifying the action's type. Within the store's registered callback, a switch statement based on the action's type is used to interpret the payload and to provide the proper hooks into the store's internal methods. This allows an action to result in an update to the state of the store, via the dispatcher. After the stores are updated, they broadcast an event declaring that their state has changed, so the views may query the new state and update themselves. -### Views and Controller-Views - +### Views and Controller-Views + React provides the kind of composable views we need for the view layer. Close to the top of the nested view hierarchy, a special kind of view listens for events that are broadcast by the stores that it depends on. One could call this a controller-view, as it provides the glue code to get the data from the stores and to pass this data down the chain of its descendants. We might have one of these controller-views governing any significant section of the page. -When it receives the event from the store, it first requests the new data it needs via the stores' public getter methods. It then calls its own `setState()` or `forceUpdate()` methods, causing its `render()` method and the `render()` method of all its descendants to run. +When it receives the event from the store, it first requests the new data it needs via the stores' public getter methods. It then calls its own `setState()` or `forceUpdate()` methods, causing its `render()` method and the `render()` method of all its descendants to run. -We often pass the entire state of the store down the chain of views in a single object, allowing different descendants to use what they need. In addition to keeping the controller-like behavior at the top of the hierarchy, and thus keeping our descendant views as functionally pure as possible, passing down the entire state of the store in a single object also has the effect of reducing the number of props we need to manage. +We often pass the entire state of the store down the chain of views in a single object, allowing different descendants to use what they need. In addition to keeping the controller-like behavior at the top of the hierarchy, and thus keeping our descendant views as functionally pure as possible, passing down the entire state of the store in a single object also has the effect of reducing the number of props we need to manage. Occasionally we may need to add additional controller-views deeper in the hierarchy to keep components simple. This might help us to better encapsulate a section of the hierarchy related to a specific data domain. Be aware, however, that controller-views deeper in the hierarchy can violate the singular flow of data by introducing a new, potentially conflicting entry point for the data flow. In making the decision of whether to add a deep controller-view, balance the gain of simpler components against the complexity of multiple data updates flowing into the hierarchy at different points. These multiple data updates can lead to odd effects, with React's render method getting invoked repeatedly by updates from different controller-views, potentially increasing the difficulty of debugging. -### Actions +### Actions -The dispatcher exposes a method that allows a view to trigger a dispatch to the stores, and to include a payload of data, or an action. The action construction may be wrapped into a semantic helper method which sends the payload to the dispatcher. For example, we may want to change the text of a to-do item in a to-do list application. We would create an action with a function signature like `updateText(todoId, newText)` in our `TodoActions` module. This method may be invoked from within our views' event handlers, so we can call it in response to a user action. This action method also adds the action type to the payload, so that when the payload is interpreted in the store, it can respond appropriately to a payload with a particular action type. In our example, this type might be named something like `TODO_UPDATE_TEXT`. +The dispatcher exposes a method that allows a view to trigger a dispatch to the stores, and to include a payload of data, or an action. The action construction may be wrapped into a semantic helper method which sends the payload to the dispatcher. For example, we may want to change the text of a to-do item in a to-do list application. We would create an action with a function signature like `updateText(todoId, newText)` in our `TodoActions` module. This method may be invoked from within our views' event handlers, so we can call it in response to a user action. This action method also adds the action type to the payload, so that when the payload is interpreted in the store, it can respond appropriately to a payload with a particular action type. In our example, this type might be named something like `TODO_UPDATE_TEXT`. Actions may also come from other places, such as the server. This happens, for example, during data initialization. It may also happen when the server returns an error code or when the server has updates to provide to the application. We'll talk more about server actions in a future article. In this post we're only concerned with the basics of the data flow. -### What About that Dispatcher? +### What About that Dispatcher? -As mentioned earlier, the dispatcher is also able to manage dependencies between stores. This functionality is available through the `waitFor()` method within the Dispatcher class. We did not need to use this method within the extremely simple [TodoMVC application](https://github.com/facebook/react/tree/master/examples/todomvc-flux), but we have included it [in the example dispatcher](https://github.com/facebook/react/blob/master/examples/todomvc-flux/js/dispatcher/Dispatcher.js#L110) as an example of what a dispatcher should be able to do in a larger, more complex application. +As mentioned earlier, the dispatcher is also able to manage dependencies between stores. This functionality is available through the `waitFor()` method within the Dispatcher class. We did not need to use this method within the extremely simple [TodoMVC application](https://github.com/facebook/flux/tree/master/examples/flux-todomvc), but we have included it [in the example dispatcher](https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/dispatcher/Dispatcher.js#L110) as an example of what a dispatcher should be able to do in a larger, more complex application. -Within the TodoStore's registered callback we could explicitly wait for any dependencies to first update before moving forward: +Within the TodoStore's registered callback we could explicitly wait for any dependencies to first update before moving forward: ```javascript -case 'TODO_CREATE': - Dispatcher.waitFor([ - PrependedTextStore.dispatcherIndex, - YetAnotherStore.dispatcherIndex - ], function() { - TodoStore.create(PrependedTextStore.getText() + ' ' + action.text); - TodoStore.emit('change'); - }); - break; +case 'TODO_CREATE': + Dispatcher.waitFor([ + PrependedTextStore.dispatcherIndex, + YetAnotherStore.dispatcherIndex + ], function() { + TodoStore.create(PrependedTextStore.getText() + ' ' + action.text); + TodoStore.emit('change'); + }); + break; ``` The arguments for `waitFor()` are an array of dispatcher registry indexes, and a final callback to invoke after the callbacks at the given indexes have completed. Thus the store that is invoking `waitFor()` can depend on the state of another store to inform how it should update its own state. diff --git a/docs/docs/flux-todo-list.md b/docs/docs/flux-todo-list.md index 906f70c67ca..6df4e2fd1b6 100644 --- a/docs/docs/flux-todo-list.md +++ b/docs/docs/flux-todo-list.md @@ -5,54 +5,54 @@ layout: docs prev: flux-overview.html --- -To demonstrate the Flux architecture with some example code, let's take on the classic TodoMVC application. The entire application is available in the React GitHub repo within the [todomvc-flux](https://github.com/facebook/react/tree/master/examples/todomvc-flux) example directory, but let's walk through the development of it a step at a time. +To demonstrate the Flux architecture with some example code, let's take on the classic TodoMVC application. The entire application is available in the Flux GitHub repo within the [flux-todomvc](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) example directory, but let's walk through the development of it a step at a time. To begin, we'll need some boilerplate and get up and running with a module system. Node's module system, based on CommonJS, will fit the bill very nicely and we can build off of [react-boilerplate](https://github.com/petehunt/react-boilerplate) to get up and running quickly. Assuming you have npm installed, simply clone the react-boilerplate code from GitHub, and navigate into the resulting directory in Terminal (or whatever CLI application you like). Next run the npm scripts to get up and running: `npm install`, then `npm run build`, and lastly `npm start` to continuously build using Browserify. -The TodoMVC example has all this built into it as well, but if you're starting with react-boilerplate make sure you edit your package.json file to match the file structure and dependencies described in the TodoMVC example's [package.json](https://github.com/facebook/react/tree/master/examples/todomvc-flux/package.json), or else your code won't match up with the explanations below. +The TodoMVC example has all this built into it as well, but if you're starting with react-boilerplate make sure you edit your package.json file to match the file structure and dependencies described in the TodoMVC example's [package.json](https://github.com/facebook/flux/tree/master/examples/flux-todomvc/package.json), or else your code won't match up with the explanations below. Source Code Structure ---------------------- -The resulting index.js file may be used as the entry point into our app, but we'll put most of our code in a 'js' directory. Let's let Browserify do its thing, and now we'll open a new tab in Terminal (or a GUI file browser) to look at the directory. It should look something like this: +--------------------- +The resulting index.js file may be used as the entry point into our app, but we'll put most of our code in a 'js' directory. Let's let Browserify do its thing, and now we'll open a new tab in Terminal (or a GUI file browser) to look at the directory. It should look something like this: -``` -myapp - | - + ... +``` +myapp + | + + ... + js | + app.js - + bundle.js // generated by Browserify whenever we make changes. - + index.html - + ... -``` - -Next we'll dive into the js directory, and layout our application's primary directory structure: - -``` -myapp - | - + ... - + js - | - + actions + + bundle.js // generated by Browserify whenever we make changes. + + index.html + + ... +``` + +Next we'll dive into the js directory, and layout our application's primary directory structure: + +``` +myapp + | + + ... + + js + | + + actions + components // all React components, both views and controller-views + constants - + dispatcher - + stores + + dispatcher + + stores + app.js + bundle.js + index.html + ... -``` +``` -Creating a Dispatcher ---------------------- +Creating a Dispatcher +--------------------- -Now we are ready to create a dispatcher. Here is an naive example of a Dispatcher class, written with JavaScript promises, polyfilled with Jake Archibald's [ES6-Promises](https://github.com/jakearchibald/ES6-Promises) module. +Now we are ready to create a dispatcher. Here is an naive example of a Dispatcher class, written with JavaScript promises, polyfilled with Jake Archibald's [ES6-Promises](https://github.com/jakearchibald/ES6-Promises) module. -```javascript +```javascript var Promise = require('es6-promise').Promise; var merge = require('react/lib/merge'); @@ -98,16 +98,16 @@ Dispatcher.prototype = merge(Dispatcher.prototype, { }); _promises = []; } -}); - -module.exports = Dispatcher; -``` +}); -The public API of this basic Dispatcher consists of only two methods: register() and dispatch(). We'll use register() within our stores to register each store's callback. We'll use dispatch() within our actions to trigger the invocation of the callbacks. +module.exports = Dispatcher; +``` -Now we are all set to create a dispatcher that is more specific to our app, which we'll call AppDispatcher. +The public API of this basic Dispatcher consists of only two methods: register() and dispatch(). We'll use register() within our stores to register each store's callback. We'll use dispatch() within our actions to trigger the invocation of the callbacks. -```javascript +Now we are all set to create a dispatcher that is more specific to our app, which we'll call AppDispatcher. + +```javascript var Dispatcher = require('./Dispatcher'); var merge = require('react/lib/merge'); @@ -129,144 +129,144 @@ var AppDispatcher = merge(Dispatcher.prototype, { }); module.exports = AppDispatcher; -``` +``` + +Now we've created an implementation that is a bit more specific to our needs, with a helper function we can use in the actions coming from our views' event handlers. We might expand on this later to provide a separate helper for server updates, but for now this is all we need. + + +Creating Stores +---------------- -Now we've created an implementation that is a bit more specific to our needs, with a helper function we can use in the actions coming from our views' event handlers. We might expand on this later to provide a separate helper for server updates, but for now this is all we need. +We can use Node's EventEmitter to get started with a store. We need EventEmitter to broadcast the 'change' event to our controller-views. So let's take a look at what that looks like. I've omitted some of the code for the sake of brevity, but for the full version see [TodoStore.js](https://github.com/Facebook/flux/blob/master/examples/flux-todomvc/js/stores/TodoStore.js) in the TodoMVC example code. + +```javascript +var AppDispatcher = require('../dispatcher/AppDispatcher'); +var EventEmitter = require('events').EventEmitter; +var TodoConstants = require('../constants/TodoConstants'); +var merge = require('react/lib/merge'); +var CHANGE_EVENT = 'change'; -Creating Stores ----------------- +var _todos = {}; // collection of todo items -We can use Node's EventEmitter to get started with a store. We need EventEmitter to broadcast the 'change' event to our controller-views. So let's take a look at what that looks like. I've omitted some of the code for the sake of brevity, but for the full version see [TodoStore.js](https://github.com/Facebook/react/blob/master/examples/todomvc-flux/js/stores/TodoStore.js) in the TodoMVC example code. +/** + * Create a TODO item. + * @param {string} text The content of the TODO + */ +function create(text) { + // Using the current timestamp in place of a real id. + var id = Date.now(); + _todos[id] = { + id: id, + complete: false, + text: text + }; +} -```javascript -var AppDispatcher = require('../dispatcher/AppDispatcher'); -var EventEmitter = require('events').EventEmitter; -var TodoConstants = require('../constants/TodoConstants'); -var merge = require('react/lib/merge'); - -var CHANGE_EVENT = 'change'; - -var _todos = {}; // collection of todo items - /** - * Create a TODO item. - * @param {string} text The content of the TODO - */ -function create(text) { - // Using the current timestamp in place of a real id. - var id = Date.now(); - _todos[id] = { - id: id, - complete: false, - text: text - }; -} - -/** - * Delete a TODO item. - * @param {string} id - */ -function destroy(id) { - delete _todos[id]; -} - -var TodoStore = merge(EventEmitter.prototype, { - - /** - * Get the entire collection of TODOs. - * @return {object} - */ - getAll: function() { - return _todos; - }, - - emitChange: function() { - this.emit(CHANGE_EVENT); - }, - - /** - * @param {function} callback - */ - addChangeListener: function(callback) { - this.on(CHANGE_EVENT, callback); - }, - - /** - * @param {function} callback - */ - removeChangeListener: function(callback) { - this.removeListener(CHANGE_EVENT, callback); - } - - dispatcherIndex: AppDispatcher.register(function(payload) { - var action = payload.action; - var text; - - switch(action.actionType) { - case TodoConstants.TODO_CREATE: - text = action.text.trim(); - if (text !== '') { - create(text); - TodoStore.emitChange(); - } - break; - - case TodoConstants.TODO_DESTROY: - destroy(action.id); - TodoStore.emitChange(); - break; - - // add more cases for other actionTypes, like TODO_UPDATE, etc. + * Delete a TODO item. + * @param {string} id + */ +function destroy(id) { + delete _todos[id]; +} + +var TodoStore = merge(EventEmitter.prototype, { + + /** + * Get the entire collection of TODOs. + * @return {object} + */ + getAll: function() { + return _todos; + }, + + emitChange: function() { + this.emit(CHANGE_EVENT); + }, + + /** + * @param {function} callback + */ + addChangeListener: function(callback) { + this.on(CHANGE_EVENT, callback); + }, + + /** + * @param {function} callback + */ + removeChangeListener: function(callback) { + this.removeListener(CHANGE_EVENT, callback); + } + + dispatcherIndex: AppDispatcher.register(function(payload) { + var action = payload.action; + var text; + + switch(action.actionType) { + case TodoConstants.TODO_CREATE: + text = action.text.trim(); + if (text !== '') { + create(text); + TodoStore.emitChange(); + } + break; + + case TodoConstants.TODO_DESTROY: + destroy(action.id); + TodoStore.emitChange(); + break; + + // add more cases for other actionTypes, like TODO_UPDATE, etc. } - - return true; // No errors. Needed by promise in Dispatcher. - }) - -}); - -module.exports = TodoStore; -``` - -There are a few important things to note in the above code. To start, we are maintaining a private data structure called _todos. This object contains all the individual to-do items. Because this variable lives outside the class, but within the closure of the module, it remains private — it cannot be directly changed from the outside. This helps us preserve a distinct input/output interface for the flow of data by making it impossible to update the store without using an action. - -Another important part is the registration of the store's callback with the dispatcher. We pass in our payload handling callback to the dispatcher and preserve the index that this store has in the dispatcher's registry. The callback function currently only handles two actionTypes, but later we can add as many as we need. - - -Listening to Changes with a Controller-View -------------------------------------------- - -We need a React component near the top of our component hierarchy to listen for changes in the store. In a larger app, we would have more of these listening components, perhaps one for every section of the page. In Facebook's Ads Creation Tool, we have many of these controller-like views, each governing a specific section of the UI. In the Lookback Video Editor, we only had two: one for the animated preview and one for the image selection interface. Here's one for our TodoMVC example. Again, this is slightly abbreviated, but for the full code you can take a look at the TodoMVC example's [TodoApp.react.js](https://github.com/facebook/react/blob/master/examples/todomvc-flux/js/components/TodoApp.react.js) - + + return true; // No errors. Needed by promise in Dispatcher. + }) + +}); + +module.exports = TodoStore; +``` + +There are a few important things to note in the above code. To start, we are maintaining a private data structure called _todos. This object contains all the individual to-do items. Because this variable lives outside the class, but within the closure of the module, it remains private — it cannot be directly changed from the outside. This helps us preserve a distinct input/output interface for the flow of data by making it impossible to update the store without using an action. + +Another important part is the registration of the store's callback with the dispatcher. We pass in our payload handling callback to the dispatcher and preserve the index that this store has in the dispatcher's registry. The callback function currently only handles two actionTypes, but later we can add as many as we need. + + +Listening to Changes with a Controller-View +------------------------------------------- + +We need a React component near the top of our component hierarchy to listen for changes in the store. In a larger app, we would have more of these listening components, perhaps one for every section of the page. In Facebook's Ads Creation Tool, we have many of these controller-like views, each governing a specific section of the UI. In the Lookback Video Editor, we only had two: one for the animated preview and one for the image selection interface. Here's one for our TodoMVC example. Again, this is slightly abbreviated, but for the full code you can take a look at the TodoMVC example's [TodoApp.react.js](https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/components/TodoApp.react.js) + ```javascript -/** @jsx React.DOM */ - -var Footer = require('./Footer.react'); -var Header = require('./Header.react'); -var MainSection = require('./MainSection.react'); -var React = require('react'); -var TodoStore = require('../stores/TodoStore'); - -function getTodoState() { - return { - allTodos: TodoStore.getAll() - }; -} - -var TodoApp = React.createClass({ - - getInitialState: function() { - return getTodoState(); - }, - - componentDidMount: function() { - TodoStore.addChangeListener(this._onChange); - }, - - componentWillUnmount: function() { - TodoStore.removeChangeListener(this._onChange); - }, - +/** @jsx React.DOM */ + +var Footer = require('./Footer.react'); +var Header = require('./Header.react'); +var MainSection = require('./MainSection.react'); +var React = require('react'); +var TodoStore = require('../stores/TodoStore'); + +function getTodoState() { + return { + allTodos: TodoStore.getAll() + }; +} + +var TodoApp = React.createClass({ + + getInitialState: function() { + return getTodoState(); + }, + + componentDidMount: function() { + TodoStore.addChangeListener(this._onChange); + }, + + componentWillUnmount: function() { + TodoStore.removeChangeListener(this._onChange); + }, + /** * @return {object} */ @@ -281,189 +281,189 @@ var TodoApp = React.createClass({