对于“前端状态”相关问题，如何思考比较全面

 关注“脚本之家”，与百万开发者在一起

出处：魔术师卡颂（ID：gh_52d0bec584f9）

如若转载请联系原公众号

最近看到个写得很不错的知乎回答Hooks是否过誉了？前端应该跟着React走还是跟着JS、TS走？- beeplin的回答^[1]。

在这个回答的基础上，我想引申出一个问题 —— 对于「前端状态」相关问题，如何思考比较全面？

今天，我们试着从多个抽象层级的角度回答这个问题。

问题的起源

有相当比例的前端从业者入行是从「学习前端框架的使用」开始的。换言之，在他们的知识体系中，最底层是「前端框架如何使用」，其他业务知识都是构建于此之上。

要以此为基础回答「前端状态」相关问题，并不容易。就比如你问组长：

• 为什么项目中用Redux而不用Mobx？

• 为什么要用Hooks而不用ClassComponent？

很多时候得到的是一个既定的事实（就是这样，没有为什么），而不是分析后的结果。

要分析这类问题，我们需要知道一些更低抽象层级的知识。

几乎所有主流前端框架的实现原理，都在践行UI = f(state)这个公式，通俗的说 —— 「UI是对状态的映射」。

这应该是「前端状态」会出现的最低抽象层级了，所以我们从这个层级出发。

前端框架的实现原理

限于篇幅有限，这里我们以最常见的React与Vue举例。

在实现「UI是对状态的映射」过程中，两者的方向不同。

React并不关心状态如何变化。每当调用更新状态的方法（比如this.setState，或者useState dispatch...），就会对整个应用进行diff。

所以在React中，传递给「更新状态的方法」的，是「状态的快照」，换言之，是个「不可变的数据」。

Vue关心状态如何变化。每当更新状态时，都会对「与状态关联的组件」进行diff。

所以在Vue中，是直接改变状态的值。换言之，状态是个「可变的数据」。

这种底层实现的区别在单独使用框架时不会有很大区别，但是会影响上层库的实现（比如状态管理库）。

现在我们知道，通过前端框架，我们可以将状态映射到UI。那么如何管理好对应的映射关系呢？

换言之，如何将状态与「和他相关的UI」约束在一起？

我们再往更高一级抽象看。

如何封装组件

前端开发普遍采用「组件」作为「状态与UI的松散耦合单元」。

到这里我们可以发现，如果仅仅会使用前端框架，那么只能将组件看作是「前端框架中既定的设计」。

但如果从更低一层抽象（前端框架的实现原理）出发，就能发现 —— 组件是为了解决框架实现原理中「UI到状态的映射」的途径。

那么组件该如何实现，他的载体是什么呢？从软件工程的角度出发，有两个方向可以探索：

• 面向对象编程

• 函数式编程

「面向对象编程」的特点包括：

• 继承

• 封装

• 多态

其中「封装」这一特点使得「面向对象编程」很自然成为组件的首选实现方式，毕竟组件的本质就是「将状态与UI封装在一起的松散耦合单元」。

React的ClassComponent，Vue的Options API都是类似实现。

但毕竟组件的本质是「状态与UI的松散耦合单元」，在考虑复用性时，不仅要考虑「逻辑的复用」（逻辑是指操作状态的业务代码），还要考虑「UI的复用」。所以「面向对象编程」的另两个特性并不适用于组件。

框架们根据自身特点，在「类面向对象编程」的组件实现上，拓展了复用性：

• React通过HOC、renderProps

• Vue2通过mixin

经过长期实践，框架们逐渐发现 —— 「类面向对象编程的组件实现」中「封装」带来的好处不足以抵消「复用性」上的劣势。

于是React引入了Hooks，以函数作为组件封装的载体，借用「函数式编程」的理念提高复用性。类似的还有Vue3中的Composition API。

不管是ClassComponent还是FunctionComponent、Options API还是Composition API，他们的本质都是「状态与UI的松散耦合单元」。

当组件数量增多，逻辑变复杂时，一种常见的解耦方式是 —— 将可复用的逻辑从组件中抽离出来，放到单独的Model层。UI直接调用Model层的方法。

对Model层的管理，也就是所谓的「状态管理」。

对状态的管理，是比组件中「状态与UI的耦合」更高一级的抽象。

状态管理问题

「状态管理」要考虑的最基本的问题是 —— 如何与框架实现原理尽可能契合？

比如，我们要设计一个User Model，如果用class的形式书写：

class User {
  name: String;
  constructor(name: string) {
  this.name = name;
 }
 changeName(name: string) {
  return this.name = name;
 }
}

只需要将这个Model的实例包装为响应式对象，就能很方便的接入Vue3：

import { reactive } from 'vue'

setup() {
  const user = reactive(new User('KaSong') as User;
  return () => (
   <button onClick={() => user.changeName('XiaoMing')}>
      {user.name}
    </button>
  )
}

之所以这么方便，诚如本文开篇提到的 —— Vue的实现原理中，状态是「可变的数据」，这与User Model的用法是契合的。

同样的User Model要接入React则比较困难，因为React原生支持的是「不可变数据」类型的状态。

要接入React，我们可以将同样的User Model设计为不可变数据，采用reducer的形式书写：

const userModel = {
  name: 'KaSong'
};

const userReducer = (state, action) => {
  switch (action.type) {
    case "changeName":
      const name = action.payload;
      return {...state, name}
  }
};

function App() {
  const [user, dispatch] = useReducer(userReducer, userModel);

  const changeName = (name) => {
    dispatch({type: "changeName", payload: name});
  };

  return (
    <button onClick={() => changeName('XiaoMing')}>
      {user.name}
    </button>
  );
}

如果一定要接入「可变类型状态」，可以为React提供类似Vue的「响应式更新」能力后再接入。比如借用Mobx提供的响应式能力：

import { makeAutoObservable } from "mobx"

function createUser(name) {
    return makeAutoObservable(new User(name));
}

到目前为止，不管是「可变类型状态」还是「不可变类型状态」的Model，都带来了「从组件中抽离逻辑」的能力，对于上例来说：

• 「可变类型状态」将状态与逻辑抽离到User中

• 「不可变类型状态」将状态与逻辑抽离到userModel与userReducer

• 最终暴露给UI的都仅仅是changeName方法

当业务进一步复杂，Model本身需要更完善的架构，此时又是更高一级的抽象。

到这一层时已经脱离前端框架的范畴，上升到纯状态的管理，比如为mobx带来结构化数据的mobx-state-tree。

此时框架实现原理对Model的影响已经在更高的抽象中被抹去了，比如Redux-toolkit是React技术栈的解决方案，Vuex是Vue技术栈的解决方案，但他们在使用方式上是类似的。

这是因为Redux与Vuex的理念都借鉴自Flux，即使React与Vue在实现原理上有区别，但这些区别都被状态管理方案抹平了。

更高的抽象

在此之上，对于状态还有没有更高的抽象呢？答案是肯定的。

对于常规的状态管理方案，根据用途不同，可以划分出更多细分领域，比如：

• 对于表单状态，收敛到表单状态管理库中

• 对于服务端缓存，收敛到服务端状态管理库中（React Query、SWR）

• 用完整的框架收敛前后端Model，比如Remix、Next.js

总结

回到我们开篇提到的问题：

• 为什么项目中用Redux而不用Mobx？

• 为什么要用Hooks而不用ClassComponent？

现在我们已经能清晰的知道这两个问题的相同点与不同点：

• 相同点：都与状态相关

• 不同点：属于不同抽象层级的状态相关问题

要回答这些问题需要哪些知识呢？只需要知道问题涉及的「状态的抽象层级」，以及「比该层级更低的抽象层级」对应的知识即可。

比如回答：为什么项目中用Redux而不用Mobx？

考虑当前抽象层级

Redux与Mobx都属于Model的实现，前者带来一套「类Flux的状态管理理念」，后者为React带来「响应式更新」能力，在设计Model时我的项目更适合哪种类型？

或者两种类型我都不在乎，那么要不要使用更高抽象的解决方案（比如MST、Redux Toolkit）抹平这些差异？

考虑低一级抽象层级

项目用的ClassComponent还是FunctionComponent？Redux、Mobx与他们结合使用时哪个组合更能协调好UI与逻辑的松散耦合？

考虑再低一级抽象层级

React的实现原理决定了他原生与「不可变类型状态」更亲和。Redux更契合「不可变数据」，Mobx更契合「可变数据」。我的项目需要考虑这些差异么？

当了解不同抽象层级需要考虑的问题后，任何宽泛的、状态相关问题都能转化成具体的、多抽象层级问题。

从不同抽象层级出发思考，就能更全面的回答问题。

参考资料

[1]

Hooks是否过誉了？前端应该跟着React走还是跟着JS、TS走？- beeplin的回答: https://www.zhihu.com/question/468249924/answer/1968728853

<END>

程序员专属卫衣

商品直购链接

👇👇

【☝🏼点击查看更多详情】

  推荐阅读：