TodoMVC 教程

TodoMVC 教程

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 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 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, or else your code won’t match up with the explanations below.

Source Code Structure

The index.html file may be used as the entry point into our app which loads the resulting bundle.js file, 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
  |
  + ...
  + 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
    + components // all React components, both views and controller-views
    + constants
    + dispatcher
    + stores
    + app.js
    + bundle.js
  + index.html
  + ...

Creating a Dispatcher

Now we are ready to create a dispatcher. The same dispatcher that Facebook uses in production is available through npm, Bower, or GitHub. It provides you with a default implementation, Dispatcher. All we need to do is to instantiate the Dispatcher and export it as a singleton:

var Dispatcher = require('flux').Dispatcher;
module.exports = new Dispatcher();

The public API of the dispatcher consists of two main 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.

Creating Stores

A store updates itself in response to some action, and should emit a change event when done with it. We thus can use Node’s EventEmitter to get started with a store: we will use EventEmitter to broadcast the ‘change’ event to our controller-views so that they can re-render, if needed. 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 in the TodoMVC example code.

var AppDispatcher = require('../dispatcher/AppDispatcher');
var EventEmitter = require('events').EventEmitter;
var TodoConstants = require('../constants/TodoConstants');
var assign = require('object-assign');
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 = assign({}, EventEmitter.prototype, {
  /**
   * Get the entire collection of TODOs.
   * @return {object}
   */
  getAll: function() {
    return _todos;
  },
  emitChange: function() {
    this.emit(CHANGE_EVENT);
  },
  /**
   * Controller-views will use this to listen for any changes on the store and,
   * maybe, re-render themselves.
   * @param {function} callback
   */
  addChangeListener: function(callback) {
    this.on(CHANGE_EVENT, callback);
  },
  /**
   * Controller-views will use this to stop listening to the store.
   * @param {function} callback
   */
  removeChangeListener: function(callback) {
    this.removeListener(CHANGE_EVENT, callback);
  }
});
// Register a callback to handle all updates.
AppDispatcher.register(function(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.
    default:
      // no op
  }
})
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 outside of the module. 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. 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

var Footer = require('./Footer.react');
var Header = require('./Header.react');
var MainSection = require('./MainSection.react');
var React = require('react');
var TodoStore = require('../stores/TodoStore');
/**
 * Retrieve the current TODO data from the 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}
   */
  render: function() {
    return (
      <div>
        <Header />
        <MainSection
          allTodos={this.state.allTodos}
        />
        <Footer allTodos={this.state.allTodos} />
      </div>
    );
  },
  _onChange: function() {
    this.setState(getTodoState());
  }
});
module.exports = TodoApp;

Now we’re in our familiar React territory, utilizing React’s lifecycle methods. We set up the initial state of this controller-view in getInitialState(), register an event listener in componentDidMount(), and then clean up after ourselves within componentWillUnmount(). We render a containing div and pass down the collection of states we got from the TodoStore.

The Header component contains the primary text input for the application, but it does not need to know the state of the store. The MainSection and Footer do need this data, so we pass it down to them.

More Views

At a high level, the React component hierarchy of the app looks like this:

<TodoApp>
  <Header>
    <TodoTextInput />
  </Header>
  <MainSection>
    <ul>
      <TodoItem />
    </ul>
  </MainSection>
</TodoApp>

If a TodoItem is in edit mode, it will also render a TodoTextInput as a child. Let’s take a look at how some of these components display the data they receive as props, and how they communicate through actions with the dispatcher.

The MainSection needs to iterate over the collection of to-do items it received from TodoApp to create the list of TodoItems. In the component’s render() method, we can do that iteration like so:

var allTodos = this.props.allTodos;
for (var key in allTodos) {
  todos.push(<TodoItem key={key} todo={allTodos[key]} />);
}
return (
  <section id="main">
    <ul id="todo-list">{todos}</ul>
  </section>
);

Now each TodoItem can display its own text, and perform actions utilizing its own ID. Explaining all the different actions that a TodoItem can invoke in the TodoMVC example goes beyond the scope of this article, but let’s just take a look at the action that deletes one of the to-do items. Here is an abbreviated version of the TodoItem:

var React = require('react');
var ReactPropTypes = React.PropTypes;
var TodoActions = require('../actions/TodoActions');
var TodoTextInput = require('./TodoTextInput.react');
var TodoItem = React.createClass({
  propTypes: {
    todo: ReactPropTypes.object.isRequired
  },
  render: function() {
    var todo = this.props.todo;
    return (
      <li
        key={todo.id}>
        <label>
          {todo.text}
        </label>
        <button className="destroy" onClick={this._onDestroyClick} />
      </li>
    );
  },
  _onDestroyClick: function() {
    TodoActions.destroy(this.props.todo.id);
  }
});
module.exports = TodoItem;

With a destroy action available in our library of TodoActions, and a store ready to handle it, connecting the user’s interaction with application state changes could not be simpler. We just wrap our onClick handler around the destroy action, provide it with the id, and we’re done. Now the user can click the destroy button and kick off the Flux cycle to update the rest of the application.

Text input, on the other hand, is just a bit more complicated because we need to hang on to the state of the text input within the React component itself. Let’s take a look at how TodoTextInput works.

As you’ll see below, with every change to the input, React expects us to update the state of the component. So when we are finally ready to save the text inside the input, we will put the value held in the component’s state in the action’s payload. This is UI state, rather than application state, and keeping that distinction in mind is a good guide for where state should live. All application state should live in the store, while components occasionally hold on to UI state. Ideally, React components preserve as little state as possible.

Because TodoTextInput is being used in multiple places within our application, with different behaviors, we’ll need to pass the onSave method in as a prop from the component’s parent. This allows onSave to invoke different actions depending on where it is used.

var React = require('react');
var ReactPropTypes = React.PropTypes;
var ENTER_KEY_CODE = 13;
var TodoTextInput = React.createClass({
  propTypes: {
    className: ReactPropTypes.string,
    id: ReactPropTypes.string,
    placeholder: ReactPropTypes.string,
    onSave: ReactPropTypes.func.isRequired,
    value: ReactPropTypes.string
  },
  getInitialState: function() {
    return {
      value: this.props.value || ''
    };
  },
  /**
   * @return {object}
   */
  render: function() /*object*/ {
    return (
      <input
        className={this.props.className}
        id={this.props.id}
        placeholder={this.props.placeholder}
        onBlur={this._save}
        onChange={this._onChange}
        onKeyDown={this._onKeyDown}
        value={this.state.value}
        autoFocus={true}
      />
    );
  },
  /**
   * Invokes the callback passed in as onSave, allowing this component to be
   * used in different ways.
   */
  _save: function() {
    this.props.onSave(this.state.value);
    this.setState({
      value: ''
    });
  },
  /**
   * @param {object} event
   */
  _onChange: function(/*object*/ event) {
    this.setState({
      value: event.target.value
    });
  },
  /**
   * @param {object} event
   */
  _onKeyDown: function(event) {
    if (event.keyCode === ENTER_KEY_CODE) {
      this._save();
    }
  }
});
module.exports = TodoTextInput;

The Header passes in the onSave method as a prop to allow the TodoTextInput to create new to-do items:

var React = require('react');
var TodoActions = require('../actions/TodoActions');
var TodoTextInput = require('./TodoTextInput.react');
var Header = React.createClass({
  /**
   * @return {object}
   */
  render: function() {
    return (
      <header id="header">
        <h1>todos</h1>
        <TodoTextInput
          id="new-todo"
          placeholder="What needs to be done?"
          onSave={this._onSave}
        />
      </header>
    );
  },
  /**
   * Event handler called within TodoTextInput.
   * Defining this here allows TodoTextInput to be used in multiple places
   * in different ways.
   * @param {string} text
   */
  _onSave: function(text) {
    TodoActions.create(text);
  }
});
module.exports = Header;

In a different context, such as in editing mode for an existing to-do item, we might pass an onSave callback that invokes TodoActions.update(text) instead.

Creating Semantic Actions

Here is the basic code for the two actions we used above in our views:

/**
 * TodoActions
 */
var AppDispatcher = require('../dispatcher/AppDispatcher');
var TodoConstants = require('../constants/TodoConstants');
var TodoActions = {
  /**
   * @param  {string} text
   */
  create: function(text) {
    AppDispatcher.dispatch({
      actionType: TodoConstants.TODO_CREATE,
      text: text
    });
  },
  /**
   * @param  {string} id
   */
  destroy: function(id) {
    AppDispatcher.dispatch({
      actionType: TodoConstants.TODO_DESTROY,
      id: id
    });
  },
};
module.exports = TodoActions;

When the user creates a new to-do item, the payload produced by the TodoActions.create() will look like:

{
  actionType: 'TODO_CREATE',
  text: 'Write blog post about Flux'
}

Let’s wrap it up. When the user validates the text input in the Header component, TodoActions.create is called with the text for the new-todo. A new action is created, with a payload containing both the text and the action type. This action is dispatched to the stores which registered to the dispatcher, through a callback mechanism. In response to the dispatched action, the TodoStore updates itself by creating a new todo-item, then emits a ‘change’ event. The controller-view TodoApp, which is the root React component in this application, is listening for such events broadcasted by the store. It responds to the ‘change’ event by fetching the new collection of to-do items from the TodoStore and changes its state. React kicks in: this change in state automatically causes the TodoApp component to call its own render() method, and the render() method of all of its owned components. Any relevant, required updates to the DOM are performed by React at the end of this unidirectional “Flux chain”.

Start Me Up

The TodoApp component has still to be created. The bootstrap file of our application will be app.js. It simply takes the TodoApp component and renders it in the root element of the application.

var React = require('react');
var TodoApp = require('./components/TodoApp.react');
React.render(
  <TodoApp />,
  document.getElementById('todoapp')
);

Adding Dependency Management to the Dispatcher

As I said previously, our Dispatcher implementation is a bit naive. It’s pretty good, but it will not suffice for most applications. We need a way to be able to manage dependencies between Stores. Let’s add that functionality with a waitFor() method within the main body of the Dispatcher class.

We’ll need another public method, waitFor(). Note that it returns a Promise that can in turn be returned from the Store callback.

  /**
   * @param  {array} promiseIndexes
   * @param  {function} callback
   */
  waitFor: function(promiseIndexes, callback) {
    var selectedPromises = promiseIndexes.map(function(index) {
      return _promises[index];
    });
    return Promise.all(selectedPromises).then(callback);
  }

Now within the TodoStore callback we can explicitly wait for any dependencies to first update before moving forward. However, if Store A waits for Store B, and B waits for A, then a circular dependency will occur. A more robust dispatcher is required to flag this scenario with warnings in the console.

The Future of Flux

A lot of people ask if Facebook will release Flux as an open source framework. Really, Flux is just an architecture, not a framework, but we have released flux/utils which is a small set of utilities we use at Facebook to build Flux applications. There are also many other great frameworks out there that enable the Flux architecture.

Thanks for taking the time to read about how we build client-side applications at Facebook. We hope Flux proves as useful to you as it has to us.