常见陷阱与最佳实践

使用 MobX 遇到坑了？本章节涵盖了一些 MobX 新手可能会遭遇的一些常见问题。

导入的路径有误

因为 MobX 自带了 TypeScript 的 typings ，一些导入自动完成工具(至少在 VSCode 中是这样的)的自动导入会有问题，像这样:

// 错误的
import { observable } from "mobx/lib/mobx"

这是不正确的，但却不会总是立即导致运行时错误。所以需要注意。导入 mobx 包中任何东西的唯一正确方式是:

// 正确的
import { observable } from "mobx"

装饰器问题?

有关装饰器的设置提示和限制，请参见 装饰器 一节。

Array.isArray(observable([1,2,3])) === false

在 ES5 中没有继承数组的可靠方法，因此 observabl e数组继承自对象。
这意味着一般的库没有办法识别出 observable 数组就是普通数组(像 lodash，或 Array.concat 这样的内置操作符)。
这个问题很容易解决，在把 observable 数组传递给其它库之前先调用 observable.toJS() 或 observable.slice() 将其转化为普通数组。
只要外部库没有修改数组的意图，那么一切都将如预期一样的正常运作。
可以使用 isObservableArray(observable) 来检查是否是 observable 数组。

object.someNewProp = value 不起作用

对于声明 observable 时未分配的属性，MobX observable 对象 检测不到，也无法作出反应。
因此 MobX observable 对象充当具有预定义键的记录。
可以使用 extendObservable(target, props) 来为一个对象引入新的 observable 属性。
但是像 for .. in 或 Object.keys() 这样的对象迭代不会自动地对这样的改变作出反应。
如果你需要动态键对象，例如通过 id 来存储用户，可以使用 observable.map 来创建 observable 映射。
想了解更多详情，请参见 MobX 会对什么作出反应?。

在所有渲染 @observable 的组件上使用 @observer

@observer 只会增强你正在装饰的组件，而不是内部使用了的组件。
所以通常你的所有组件都应该是装饰了的。但别担心，这样不会降低效率，相反 observer 组件越多，渲染效率越高。

不要拷贝 observables 属性并存储在本地

Observer 组件只会追踪在 render 方法中存取的数据。常见的错误的是从 observable 属性中提取数据并存储，这样的数据是不会被追踪的:

class User {
  @observable name
}
class Profile extends React.Component {
  name
  componentWillMount() {
    // 错误的
    // 这会间接引用 user.name 并只拷贝值一次！未来的更新不会被追踪，因为生命周期钩子不是响应的
    // 像这样的赋值会创建冗余数据
    this.name = this.props.user.name
  }
  render() {
    return <div>{this.name}</div>
  }
}

正确的方法通过不将 observables 的值存储在本地(显然，上面的示例很简单，但却是有意为之的)，或通过将其定义为计算属性:

class User {
  @observable name
}
class Profile extends React.Component {
  @computed get name() {
    // 正确的; 计算属性会追踪 `user.name` 属性
    return this.props.user.name
  }
  render() {
    return <div>{this.name}</div>
  }
}

Render 回调函数不是 render 方法的一部分

因为 observer 只作用于当前组件的 render 函数，传递一个 render 回调函数或组件给子组件不会自动地变成响应的。
想了解更多详情，请参见 MobX 会对什么作出反应 指南。

间接引用值尽可能晚的使用

MobX 可以做许多事，但是它无法将原始类型值转变成 observable(尽管可以用对象来包装它们，参见 boxed observables)。
所以说值不是 observable，而对象的属性才是。这意味着 @observer 实际上是对间接引用值作出反应。
所以如果像下面这样初始化的话，Timer 组件是不会作出任何反应的:

React.render(<Timer timerData={timerData.secondsPassed} />, document.body)

在这行代码中，只是 secondsPassed 的当前值传递给了 Timer，这个值是不可变值 0 (JS中的所有原始类型值都是不可变的)。
这个值永远都不会改变，所以 Timer 也永远不会更新。secondsPassed 属性将来会改变，所以我们需要在组件内访问它。
或者换句话说: 永远只传递拥有 observable 属性的对象。
想了解更多详情，请参见 MobX 会对什么作出反应?。

计算值(Computed values)的运行次数要比预想中频繁的多

如果一个计算属性没有被 reaction(autorun、observer 等) 使用，计算表达式将会延迟执行；每次它们的值被请求(所以它们只是作为正常属性)。
计算值将仅追踪那些它们已被观察的依赖。
这允许 MobX 自动暂停非使用状态的计算。
想深入的了解内部原理，请参见此 @mweststrate/becoming-fully-reactive-an-in-depth-explanation-of-mobservable-55995262a254">博客 或 issue #356。
如果你胡乱使用的话，计算属性似乎效率不怎么高。但当使用 observer、 autorun 等并应用在项目中时，它们会变得非常高效。

MobX 计算也会在事务期间自动地保持活动，参见 PR: #452 和 #489。

永远要清理 reaction

所有形式的 autorun、 observe 和 intercept， 只有所有它们观察的对象都垃圾回收了，它们才会被垃圾回收。
所以当不再需要使用它们的时候，推荐使用清理函数(这些方法返回的函数)来停止它们继续运行。
对于 observe 和 intercept 来说，当目标是 this 时通常不是必须要清理它们。
对于像 autorun 这样的 reaction 要棘手得多，因为它们可能观察到许多不同的 observable，并且只要其中一个仍在作用域内，reaction 将保持在作用域内，这意味着其使用的所有其他 observable 也保持活跃以支持将来的重新计算。
所以当你不再需要 reaction 的时候，千万要清理掉它们！

示例:

const VAT = observable(1.20)
class OrderLIne {
    @observable price = 10;
    @observable amount = 1;
    constructor() {
        // 这个 autorun 将与当前的命令行实例一起进行垃圾回收
        this.handler = autorun(() => {
            doSomethingWith(this.price * this.amount)
        })
        // 这个 autorun 将不会与当前的命令行实例一起进行垃圾回收
        // 因为 VAT 保留了引用以通知这个 autorun
        // 这反过来在作用域中保留了 `this`
        this.handler = autorun(() => {
            doSomethingWith(this.price * this.amount * VAT.get())
        })
        // 所以，为了避免细微的内存问题，总是调用清理函数..
        this.handler()
        // 当 reaction 不再需要时！
    }
}

当在 React 组件中使用 @observable 时有一个奇怪的异常

如下异常: Uncaught TypeError: Cannot assign to read only property '__mobxLazyInitializers' of object
react-hot-loader 不支持装饰器，所以当使用时会出现这个错误。
解决方法: 在 componentWillMount 中使用 extendObservable 替代 @observable 或者 把 react-hot-loader 更新到 "^3.0.0-beta.2" 版本或者更高。

未设置 React 组件的显示名称

如果你使用 export const MyComponent = observer((props => <div>hi</div>))，那么在开发者工具中看不到显示名称。
下列方法可以用来解决此问题:

// 1 (显示设置 displayName)
export const MyComponent = observer((props => <div>hi</div>))
myComponent.displayName = "MyComponent"
// 2 (MobX 根据函数名推断出组件名)
export const MyComponent = observer(function MyComponent(props) { return <div>hi</div> })
// 3 (编译器根据变量名推断出组件名)
const _MyComponent = observer((props => <div>hi</div>)) //
export const MyComponent = observer(_MyComponent)
// 4 (默认导出)
const MyComponent = observer((props => <div>hi</div>))
export default observer(MyComponent)

还可参见: http://mobxjs.github.io/mobx/best/stateless-HMR.html 或 #141。

observable 数组的 propType 是对象

Observable 数组实际上是对象，所以它们遵循 propTypes.object 而不是 propTypes.array。
mobx-react 为 observable 数据结构提供了明确的 PropTypes。

在 React Native 中渲染 ListViews

React Native 的 ListView.DataSource 接收真正的数组。Observable 数组实际上是对象，要确保在传给 ListViews 之前先使用 .slice() 方法。
此外，ListView.DataSource 本身可以移到 store 之中并且使用 @computed 自动地更新，这步操作同样可以在组件层完成。

class ListStore {
  @observable list = [
    'Hello World!',
    'Hello React Native!',
    'Hello MobX!'
  ];
  ds = new ListView.DataSource({ rowHasChanged: (r1, r2) => r1 !== r2 });
  @computed get dataSource() {
    return this.ds.cloneWithRows(this.list.slice());
  }
}
const listStore = new ListStore();
@observer class List extends Component {
  render() {
    return (
      <ListView
        dataSource={listStore.dataSource}
        renderRow={row => <Text>{row}</Text>}
        enableEmptySections={true}
      />
    );
  }
}

想了解更多信息，请参见 #476。

开发模式下声明 propTypes 可能会引起不必要的渲染

参见: https://github.com/mobxjs/mobx-react/issues/56

使用 Babel 时 @observable 属性延迟初始化

这个问题只有当使用 Babel 作为编辑器，而不是 Typescript(装饰器支持更成熟) 时才会出现。
Observable 属性不会进行初始化，直到第一次读/写此属性(在这一刻它们都会被初始化)。
这导致了以下细微的bug:

class Todo {
    @observable done = true
    @observable title = "test"
}
const todo = new Todo()
"done" in todo // true
todo.hasOwnProperty("done") // false
Object.keys(todo) // []
console.log(todo.title)
"done" in todo // true
todo.hasOwnProperty("done") // true
Object.keys(todo) // ["done", "title"]

在实践中，很少会出现这样的问题，只有在读/写对象的任何属性之前使用像 Object.assign(target, todo) 或 assert.deepEquals 这样的一般方法时才会出现。
如果你想确保此问题不会出现，在构造函数中初始化字段来替代字段声明，或者使用 extendObservable 来创建 observable 属性。