Mobx React 最佳实践

若是你不知道mobx是什么，请阅读这篇文章

在这一篇文章里，将展现一些使用了mobx的React的最佳实践方式，并按照一条一条的规则来展现。在你遇到问题的时候，能够依照着这些规则来解决。

这篇文章要求你对于mobx的stores有基本的理解，若是没有的话请先阅读官方文档。

stores 表明着UI状态

永远记住，你的stores表明着你的UI状态，这就意味着，当你将你的stores储存下来后，就算你关了网页，再次打开，载入这个stores，你获得的网页也应该是相同的。虽然stores并非一个本地数据库的角色，可是他依然存储着一些相似于按钮是否可见，input里面的内容之类的UI状态。

class SearchStore {
  @observable searchText;

  @action
  setSearchText = (searchText) => {
    this.searchText = searchText
  }
}

@observer
class SearchInput extends React.Component {

  handleInputChanged = (event) => {
    const { searchStore } = this.props;
    searchStore.setSearchText(event.target.value);
  }

  render() {
    const { searchStore } = this.props;
    return (
      <input value={searchStore.searchText} onChange={this.handleInputChanged} /> ); } } 复制代码

将你的REST API请求和store的action分离

不建议将REST API请求的函数放在stores里面，由于这样以来这些请求代码很难测试。你能够尝试把这些请求函数放在一个类里面，把这个类的代码和store放在一块儿，在store建立时，这个类也相应建立。而后当你测试时，你也能够优雅的把数据从这些类里面mock上去。

class TodoApi {

  fetchTodos = () => request.get('/todos')
}

class TodoStore {

  @observable todos = [];

  constructor(todoApi) {
    this.todoApi = todoApi;
  }

  fetchTodos = async () => {
    const todos = await this.todoApi.fetchTodos();

    runInAction(() => {
      this.todos = todos;
    });
  }
}

// 在你的主要函数里面
const todoApi = new TodoApi();
const todoStore = new TodoStore(todoApi);
复制代码

把你的业务逻辑放在stores里面

尽可能不要把业务逻辑写在你的组件里面。当你把业务逻辑写在组件里面的时候，你是没有办法来及时定位错误的，由于你的业务逻辑分散在各类不一样的组件里面，让你很难来经过行为来定义究竟是哪些代码涉及的这个错误。最好就把业务逻辑放在stores的方法里面，从组件里面调用。

避免使用全局的store实例

请尽可能避免使用全局的store实例，由于这样你很难写出有条理而可靠的组件测试。取而代之的是，你可使用Provider来把你的store inject到你的component实例的props里面。这样你就能够轻松的mock这些store来测试了。

const searchStore = new SearchStore();

const app = (
  <Provider searchStore={searchStore}> <SearchInput /> </Provider>
);

ReactDom.render(app, container);
复制代码

mobxjs/mobx-react

只有在store里面才容许改变属性

请不要直接在组件里面直接操做store的属性值。由于只有store才可以来修改本身的属性。当你要改变属性的时候，请使用相应的store方法。否则的话你的属性修改会散落在各处不受控制，这是很难debug的。

时刻记得在组件声明 @observer

在每一个组件声明的时候使用@observer来更新组件的状态。否则在嵌套组件里面，子组件没有声明的话，每次状态更新涉及到的都是父组件级的从新渲染。当你都使用了@observer时，从新渲染的组件数量会大大下降。

使用 @computed

就像下面代码的例子，使用@computed属性来处理一些涉及多个属性的逻辑。使用@computed能够减小这样的判断类业务逻辑在组件里面出现的频率。

class ApplicationStore {

  @observable loggedInUser;

  @observable isInAdminMode;

  @computed isAdminButtonEnabled = () => {
    return this.loggedInUser.role === 'admin' && this.isInAdminMode;
  }
}
复制代码

你不须要 react router 来管理状态

你不须要使用react router管理状态。就像我前面所说的，你的store就表明了应用的状态。当你让router来管理部份应用状态的时候，这部分状态就从store里面剥离开来。因此尽可能使用store来储存全部的UI状态，这样store的属性就是你的界面所得。

倾向于编写可控组件

多编写可控组件，这样会大大下降你的测试复杂度，也让你的组件易于管理。

Forms – React

做者：Daniel Bischoff

原文：Mobx React — Best Practices

翻译：Dominic Ming