关于react.js:mobx如何观察数据的变动从而触发渲染

8次阅读

共计 4009 个字符，预计需要花费 11 分钟才能阅读完成。

开发过程中应用 Mobx 极大的不便了咱们，然而在应用过程中还是会或多或少地遇到一些问题导致绑定失败，上面咱们来一起探讨下 Mobx 的绑定过程，以不便咱们来更好的应用它。

MobX 会对在追踪函数执行过程中读取现存的可察看属性做出反馈。

MobX 的官网文档将 MobX 的绑定及相应过程总结为这么一句话，并标出了“读取”、“追踪函数”和“过程”三个关键字。

“追踪函数”是 computed 表达式、observer 组件的 render() 办法和 when、reaction 和 autorun 的第一个入参函数。

文档阐明的也比较清楚，会对文件当中的 @computed 润饰的办法、render()办法、when办法的第一个入参函数、reaction办法的第一个入参函数、autorun办法的第一个入参函数这些中央收集，MobX 会在页面加载执行前扫描所有的文件，收集这些中央的绑定。

以下调用和赋值 this.store.listA 的中央，MobX 都会去收集绑定，其它的中央则不会去收集。

// 数据绑定文件
import {computed, observable} from 'mobx';

class IndexStore {@observable listA = ["1","2","3"];
    @observable listB = ["a","b","c"];

    @computed get dataA() {return this.listA;}
}

//Index 视图文件
import {observer} from 'mobx-react/native';
import IndexStore from 'indexStore';

@observer
class Index extends Component {constructor() {super();
        this.store = new IndexStore();
        when(() => this.store.listA.length == 0,
            () => console.log("listA none")
        );
    }

    const autorun1 = autorun(() => {console.log(this.store.listA);
    })

    const reaction2 = reaction(() => this.store.listA,
        listA => console.log(listA.join(","))
    )

    render() {
        return (<MainItem dataSource={this.store.listA}
            renderHeader={() => <Item data={this.store.listB}></Item>
            } />
        )
    }
}

“过程(during)”意味着只追踪那些在函数执行时被读取的 observable。这些值是否由追踪函数间接或间接应用并不重要。

这句话解释了 MobX 收集哪些绑定，是那些在函数执行时被读取的 observable，例如下面实例代码<MainItem dataSource={this.store.listA}/> 中的 this.store.listA，它在render() 函数执行时被调用，用于作为 MainItem 的数据源，所以这个绑定就被收集到了，render()函数和 listA 之间就建设了分割，当 listA 发生变化时，render()函数就会被调用，界面也就从新渲染刷新了。同理，下面的一些 log 也会调用，会在控制台输入相应信息。

须要留神的是下面实例代码中的 renderHeader={() => <Item data={this.store.listB}></Item>} 当中的 this.store.listB 并不会被收集到，为什么呢？因为 renderHeader 作为一个属性传入 MainItem，renderHeader 当中的 this.store.listB 并没有在 Index 的render()去应用，而是在 Item 当中应用了它，所以 Index 的render()并没有与 listB 之间建设连贯，当 listB 发生变化就不会调用 Index 的render()，界面也就不会从新渲染刷新。

咱们想在批改 listB 时让界面刷新作出相应，咱们该怎么办呢？咱们须要在 Item 当中增加 @observer 去捕捉这个绑定，因为 listB 在Item的 render() 当中进行了调用，所以正确的写法如下：

//Index 视图文件
render() {
    return (<MainItem dataSource={this.store.listA}
            renderHeader={() => <Item data={this.store}></Item>
        } />
    )
}

//Item 视图文件
import {observer} from 'mobx-react/native';

@observer
class Item extends Component {constructor() {super();
    }

    render() {
        return (<Text>{this.props.data.listB[0]}</Text>
        )
    }
}

Tips：当咱们批改 listB 时，Item就会从新调用其 render() 函数从新渲染，咱们从新渲染 Item 比从新渲染整个 Index 所耗费的资源会更少，尽管 MobX 曾经有机制帮咱们缩小不必要的渲染，然而这样还是会耗费更少的资源，所以官网举荐咱们绑定粒度越细越好。

仔细的同学可能会留神到为什么 Item 的data当中是 this.store 而不是咱们认为的this.store.listB，是写错了吗，并不是，这恰好是正确的写法，上面咱们就来探讨下这个问题。

“读取”是对象属性的间接援用，能够用过 . (例如 user.name) 或者 [] (例如 user['name']) 的模式实现。

这句话解释了 MobX 绑定了什么，它绑定的是可察看对象的援用，例如下面提到的 listA，MobX 并不是将listA 的内容 ["1","2","3"] 与render()函数绑定，而是将 listA 变量对 ["1","2","3"] 的援用与 render() 函数绑定绑定，所以只有当 listA 对值的援用发生变化时，render()函数才会调用。（也能够了解为 c /c++ 当中的指针的概念，render()函数是与 listA 变量的指针值绑定）

所以针对下面的 listA，你只批改数组的内容，render() 函数是不会调用的，界面也是不会刷新的。上面这种写法，界面并不会刷新：

// 数据绑定文件
modifyListA1() {this.listA[0] = "4";
}

// 此处只是数组 ["1","2","3"] 的内容产生了变动，listA 的援用却没有发生变化

正确的写法

// 数据绑定文件
modifyListA2() {this.listA = ["4","2","3"];
}

// 此处 listA 被赋值了一个新数组["4","2","3"]，listA 的援用产生了变动

咱们再回到 listB 的问题上，如果咱们是 <Item data={this.store.listB}></Item> 这种写法，咱们相当于把 ["a","b","c"] 这个值传递给了 Item 当中的 data，通过data 对数组的操作，并未呈现 listB 的援用，也就无奈建设绑定。而咱们将整个 store 传递过来，data就被赋值了 store 的内容，当 data 援用 listB 时，也就呈现了 listB 的援用，这样绑定才建设了起来。

所以针对子组件，须要将被察看属性的父级传递过来，这样能力在子组件中呈现被察看属性的援用，能力建设绑定。

理解了以上三个概念，MobX 的绑定过程就比拟清晰了。MobX 在代码编译时 / 代码执行之前扫描代码中的computed 表达式、observer 组件的 render() 办法等中央，将这些办法中呈现的间接调用的察看属性的援用和这些办法绑定起来，这就是 MobX 的绑定过程。绑定实现之后，当这些援用发生变化时，相应的绑定办法就调用，界面就会刷新从新渲染或者相应的逻辑就会执行。

下面咱们 modifyListA1 提到的批改并不会触发绑定的界面刷新操作，须要咱们应用 modifyListA2 当中的批改形式，给 listA 提供一个新数组，扭转它的援用值。那有没有办法能够让 listA 只批改一个值（如 modifyListA1 当中的操作）就触发界面的刷新呢，答案是必定的，咱们只须要将 listA 初始的赋值形式改成如下形式即可：

// 数据绑定文件
import {computed, observable} from 'mobx';

class IndexStore {listA = observable(["1","2","3"]);
    @observable listB = ["a","b","c"];

    @computed get dataA() {return this.listA;}
}

为什么这种形式就能够呢？因为 observable 默认状况下会递归利用，相比拟 @observable 细粒度的察看，只监测 listA 的援用，observable则会递归这些察看，将 listA[0]、listA[1]、listA[2] 的援用都作为监测对象，这样 listA[0]、listA[1]、listA[2] 的援用就和 render() 函数建设起了绑定，当 listA[0] 被赋值，援用发生变化时，render()也就被调用了，界面也就刷新了。

如果须要一个数据源的外部数据发生变化引起相应操作，咱们能够应用 observable，然而observable 也有它的弊病，它会建设起来比拟多的冗余绑定，也会使后续的保护变得复杂，总体上咱们举荐应用 @observable 这样细粒度的管制，它会使咱们的我的项目更加清晰便于保护，同时也会大大的升高那些莫名其妙的 bug 的概率。

正文完