mobx基础

React 和 MobX 是一对强力组合。React 通过提供机制把应用状态转换为可渲染组件树并对其进行渲染。而MobX提供机制来存储和更新应用状态供 React 使用。

对于应用开发中的常见问题，React 和 MobX 都提供了最优和独特的解决方案。React 提供了优化UI渲染的机制， 这种机制就是通过使用虚拟DOM来减少昂贵的DOM变化的数量。MobX 提供了优化应用状态与 React 组件同步的机制，这种机制就是使用响应式虚拟依赖状态图表，它只有在真正需要的时候才更新并且永远保持是最新的。

 

1.@observable 装饰器

使用observable可以吧对象的属性变成单据格或者引用值

 

import { observable } from "mobx";

class Todo {
    id = Math.random();
    @observable title = "";
}

2.@computed 装饰器. 计算值

相关数据发生变化时自动更新的值

class TodoList {
    @observable todos = [];
    @computed get unfinishedTodoCount() {
        return this.todos.filter(todo => !todo.finished).length;
    }
}

　当添加了一个新的todo或者某个todo的 finished 属性发生变化时，MobX 会确保 unfinishedTodoCount 自动更新。

3.reactions. 反应

reactions是在响应式编程和命令式编程之间建立沟通的桥梁

和@computed相似，但是不是产生新的值，而是一些操作，例如 网络请求，打印控制台，更新react组件树

4.react 响应式组件

在组件上添加observer装饰器/函数 就可以把无状态组件变成响应式组件

MobX 会确保组件总是在需要的时重新渲染

import React, {Component} from 'react';
import ReactDOM from 'react-dom';
import {observer} from 'mobx-react';

@observer
class TodoListView extends Component {
    render() {
        return <div>
            <ul>
                {this.props.todoList.todos.map(todo =>
                    <TodoView todo={todo} key={todo.id} />
                )}
            </ul>
            Tasks left: {this.props.todoList.unfinishedTodoCount}
        </div>
    }
}

const TodoView = observer(({todo}) =>
    <li>
        <input
            type="checkbox"
            checked={todo.finished}
            onClick={() => todo.finished = !todo.finished}
        />{todo.title}
    </li>
)

const store = new TodoList();
ReactDOM.render(<TodoListView todoList={store} />, document.getElementById('mount'));

3.1 自定义reactions

使用autorun,reaction,when函数可以创建自定义reactions

例如，每当 unfinishedTodoCount 的数量发生变化时，下面的 autorun 会打印日志消息:

autorun(() => {
    console.log("Tasks left: " + todos.unfinishedTodoCount)
})

mobx的基本实现

1.定义可观察的状态 （observable）

2.创建视图用来响应状态的变化

3.更改状态

 

mobx会对什么作出反应？

mobx会对追踪函数执行过程中读取现存的可观察属性作出反应

• “读取” 是对象属性的间接引用，可以用过 . (例如 user.name) 或者 [] (例如 user['name']) 的形式完成。
• “追踪函数” 是 computed 表达式、observer 组件的 render() 方法和 when、reaction 和 autorun 的第一个入参函数。
• “过程(during)” 意味着只追踪那些在函数执行时被读取的 observable 。这些值是否由追踪函数直接或间接使用并不重要。

换句话说，MobX 不会对其作出反应:

• 从 observable 获取的值，但是在追踪函数之外
• 在异步调用的代码块中读取的 observable

默认情况下 observable 会递归应用

所有字段都可观察
let message = observable({
    title: "Foo",
    author: {
        name: "Michel"
    },
    likes: [
        "John", "Sara"
    ]
})

mobx只追踪同步地访问数据

function upperCaseAuthorName(author) {
    const baseName = author.name;
    return baseName.toUpperCase();
}
autorun(() => {
    console.log(upperCaseAuthorName(message.author))
})
message.author.name = "Chesterton"

这将会作出反应。尽管 author.name 不是在 autorun 本身的代码块中进行直接引用的。 MobX 会追踪发生在 upperCaseAuthorName 函数里的间接引用，因为它是在 autorun 执行期间发生的。

 

autorun(() => {
    setTimeout(
        () => console.log(message.likes.join(", ")),
        10
    )
})
message.likes.push("Jennifer");

这将不会作出反应。在 autorun 执行期间没有访问到任何 observable，而只在 setTimeout 执行期间访问了。 通常来说，这是相当明显的，很少会导致问题。

mobx只会为数据是直接通过render存取的observer组件进行数据追踪

一个使用 observer 的常见错误是它不会追踪语法上看起来像 observer 父组件的数据，但实际上是由不同的组件渲染的。当组件的 render 回调函数在第一个类中传递给另一个组件时，经常会发生这种情况。

const MyComponent = observer(({ message }) =>
<SomeContainer
title = {() => <div>{message.title}</div>}
/>
)

message.title = "Bar"

这种情况下，SomeContainer也应该是一个observer，才可以对message.title作出反应

如果 SomeContainer 来源于外部库的话，这通常不在你的掌控之中。在这种场景下，你可以用自己的无状态 observer 组件来包裹 div 解决此问题，或通过利用 <Observer>组件:

const MyComponent = observer(({ message }) =>
    <SomeContainer
        title = {() => <TitleRenderer message={message} />}
    />
)

const TitleRenderer = observer(({ message }) =>
    <div>{message.title}</div>}
)

message.title = "Bar"

或者

const MyComponent = ({ message }) =>
    <SomeContainer
        title = {() =>
            <Observer>
                {() => <div>{message.title}</div>}
            </Observer>
        }
    />

message.title = "Bar"

避免在本地字段中缓存observer

组件会对 author.name 的变化作出反应，但不会对 message 本身的 .author 的变化作出反应！因为这个间接引用发生在 render() 之外，而render() 是 observer 组件的唯一追踪函数。 注意，即便把组件的 author 字段标记为 @observable 字段也不能解决这个问题，author 仍然是只分配一次。

@observer class MyComponent extends React.component {
    author;
    constructor(props) {
        super(props)
        this.author = props.message.author;
    }

    render() {
        return <div>{this.author.name}</div>
    }
}

这个问题可以简单地解决，方法是在 render() 中进行间接引用或者在组件实例上引入一个计算属性:

@observer class MyComponent extends React.component {
    @computed get author() {
        return this.props.message.author
    }
// ...

　

多个组件将如何渲染

const Message = observer(({ message }) =>
    <div>
        {message.title}
        <Author author={ message.author } />
        <Likes likes={ message.likes } />
    </div>
)

const Author = observer(({ author }) =>
    <span>{author.name}</span>
)

const Likes = observer(({ likes }) =>
    <ul>
        {likes.map(like =>
            <li>{like}</li>
        )}
    </ul>
)

变化	重新渲染组件
message.title = "Bar"	Message
message.author.name = "Susan"	Author (.author 在 Message 中进行间接引用, 但没有改变)*
message.author = { name: "Susan"}	Message, Author
message.likes[0] = "Michel"	Likes

注意:

1. * 如果 Author 组件是像这样调用的: <Author author={ message.author.name} /> 。Message 会是进行间接引用的组件并对 message.author.name 的改变作出反应。尽管如此，<Author> 同样会重新渲染，因为它接收到了一个新的值。所以从性能上考虑，越晚进行间接引用越好。
2. ** 如果 likes 数组里面的是对象而不是字符串，并且它们在它们自己的 Like 组件中渲染，那么对于发生在某个具体的 like 中发生的变化，Likes 组件将不会重新渲染。

 

mobx的优点

1，使用@observer的组件真正实现按需更新，只有监听的数据发生变化，它才会re-render，尽管父组件发生更新，但是子组件只要有@observer，则不会触发更新，类似于实现了shouldComponentUpdate的效果，而同样的场景，如果是redux，子组件通过connect绑定了store里部分数据，但是如果父组件发生更新，子组件绑定的数据源并未发生变化，因此子组件不应该更新，然而却强制更新。

mobx耦合性更低。

mobx的缺点

1，store过多导致无法统一数据源，在多人开发的情况下会比较混乱，如果需要公用某个store，唯有在特定组件注入该store，那如果有多个store里有多个数据源需要公用呢，那就要同时注入多个store，项目复杂了，store的管理又是一个问题。

2，mobx对于数组的处理，会将它转换成observableArray，它不是一个数组类型，需要进行数组转换（如slice）。

3，mobx在forceupdate时，并没有像setState那样处理多个更新合并的操作，这就带来个问题就是，在同一个event loop中，如果多次通过action去引起同一个观察者的更新，那么它就会连续更新多次，但是如果是setState，它会进行一次合并，不会有这种负担。（这里的解决方案就是人为的去控制，避免这种多次同时更新，可以将多个action手动合并为1个action）；

4，对于某个公共组件，可能多个页面需要用到，但是组件内状态较多，并且不同页面，状态差异较多，此时如果用mobx的store来管理，会存在一个问题，组件虽然unmount了，但是store并未消失，导致需要手动reset store里所有的状态，否则会混乱

mobx的思想

将响应式编程和部分函数式编程相结合，取缔传统React的命令式编程，分而治之，将组件都变成可响应的，React提供了渲染的最优方式，通过对比虚拟DOM的diff算法来减少不必要的渲染耗费，而mobx则给React提供了响应式的状态管理。

关于mobx细粒度拆分

是否所有的state我都交给mobx来管理，其实类似于redux，只有当某个状态需要多个组件（这里默认为2个及以上）公用，则将该状态放到store里去监听，然后需要引用该状态的组件通过mobx-react的inject来进行监听。

关于mobx的优化

这里我参考redux的优化，将容器组件通过mobx-react来连接需要监听的store，然后展示组件就还是通过PureComponent来进行优化，避免重复re-render。这里其实有一点考虑是，我们可以利用@observer来对展示组件需要更新的状态进行一个监听，免去shouldComponentUpdate的步骤，但是如果多挂一层监听，性能未必更优，相当于要多处理一个监听器，所以还是减少监听的个数会好些。

为什么选择mobx而不是redux

这个标题不是为了贬低redux，而是解释为什么在某些项目环境中，我不使用redux，而是使用mobx，能否使用redux？可以，只不过mobx会更让开发者舒服一些。