当一个男人决定使用Mobx（二）

背景

距离当一个男人决定使用Mobx（一）这个博客发布已经过去半年了，这期间因为项目封闭等一系列事情，后续对该框架的研究和应用也就搁置了，通过这个时间跨度也可以看出来，一个男人的决心往往就像一只猴子，看到香蕉就忘了爬树的目的。

知行合一

关于mobx的核心原理，已经在男人决定使用Mobx（一）这篇文章里写了，下面就说下在React Native工程中，使用mobx的一些个人的心得体会，主打一个真情实感的流露。

目的

首先说下我们使用Mobx的目的，核心目的只有两点

一是对项目的状态进行管理

二是约定一些编程规范，统一团队编码的思想意识

状态管理

状态管理这里又分为两部分，一个是全局状态管理，一个是局部状态管理。

全局状态管理

首先，明确全局状态包含哪些，全局状态一般包含两部分，一是数据状态，例如订单信息，用户信息等等，往往和业务概念对应，一个全局通常被组织成一个树状结构，里面有多个可观察对象。二就是UI状态，包括应用的状态、主题等等，往往也是一个树状结构，里面包含多个可观察对象。通过通过自定义hook，我们将这些全局状态暴露出来，方便组件的访问。

js 复制代码

import { createContext, useContext } from 'react';
import { makeAutoObservable } from 'mobx';


/**
 * 全局数据状态Store
 */
export class LogicStore {
    authorInfo: AuthorInfo;
    constructor() {
        makeAutoObservable(this);
    }

    updateAuthorInfo(authorInfo: AuthorInfo) {
        this.authorInfo = authorInfo;
    }
}
/**
 *全局UI状态Store
 */
export class UIStore{
    uiState:UIState=UIState.Loading;
    
    constructor(){
        makeAutoObservable(this)
    }
    
    updateUIState(uiState){
        this.uiState = uiState;          
    }
}

const MobxContext = createContext({
    logicStore: new LogicStore(),
    uiStore: new UIStore()
});


export const useLogicStore = () => useContext(MobxContext).logicStore;

export const useUIStore = () => useContext(MobxContext).uiStore;

可以看到上面的代码定义了两个store，一个是全局数据状态Store LogicStore，一个是全局UI Store UIStore,通过两个自定义use方法（useLogicStore，useUIStore）对外暴露出去，这里通过store对状态进行了一次封装，store内部会提供各种方法进行状态的更新，这样整体的数据和逻辑就全部封装在Store里，而对应的UI展示则由各自的组件进行实现，避免将一些业务逻辑写到组件内部。通过暴露的两个自定义use方法，也更好的实现组件内部进行全局状态的访问，避免了层层传参或者使用useContext进行数据更新时导致的全局组件渲染。文件结构上，定义一个mobx目录，index用来存放对外暴露的use方法，同时导出logicStore和uiStore

局部状态管理

有的时候有些状态只属于某些个别页面或者某个组件，这个时候其对应的状态就不能放在全局状态store里了，需要其内部去维护，同样可以使用对应数据状态store和ui store的方式（往往这个不需要）。目录结构上将对应的store防止在组件的目录下，这里就不再赘述了。

统一编程规范

其实通过上面的状态管理，我们可以将业务逻辑和UI进行一个较为完整的抽离，业务逻辑和状态放在store里，ui就是对应的组件，"凯撒的归凯撒，上帝的归上帝"。这样团队内部只要遵守这个规范，这样整体的代码结构就会变得清晰也易于维护，也对后面的一些性能优化提供了前置保证。

当然，有的人会说，react已经提供了hook可以用来进行状态管理，你还用它干啥？实现业务逻辑和UI分离，一个自定义hook不就行了？

有这个疑问我觉得很正常，这里主要从一下三点出发

1.从团队实际出发，我们团队内部大部分人是客户端来写RN的，之前一些自定义hook其实不太熟悉，经常见到大家把业务逻辑写到组件里，一大坨代码，看着就头大。

2.使用react提供的自定义hook时，有一个最大的问题就是你忘记写对应的依赖了，这个经常发生，会出现一些行为异常，然后针对每个hook一个一个分析，耗时耗力。这就要说Mobx的优势了，Mobx会自动更新监听相应可观测属性的变化，进行UI的重新渲染，交给框架，你安心，我放心

3.全局状态管理时，hook一般会通过useContext进行全局状态的共享，这里有个问题就是如果对useContext的对象进行更新，往往会触发全局组件的重绘，使用Mobx，全局store都是单例，更新对应的内部的数据结构状态，也只是会触发监听对应数据的组件的重绘

总结

随着项目越来越复杂，对于状态的管理以及编程的规范往往就变得尤为重要，当从野蛮生长跑马圈地，到精雕细琢统一思想的阶段，Mobx是一个不错的选择。

关注我的公众号：'滑板上的老砒霜'