浅谈前端状态管理

前端开发者或多或少都听说过，或者使用过 状态管理器:

通常我们会选择 redux, vuex, mobx 这些著名的工具。

那么为什么要使用状态管理器呢？这篇文章，我来谈一谈这个形而上学的问题。

案例分析

有一个输入框，输入文本后，在输入框下方展示出所有包含已输入文本的名字。

简单粗暴的做法：

codepen

const names = ["张零", "李一", "王二", "张三", "李四", "王五"]; const input = document.getElementById("input"); const list = document.getElementById("list"); function handleInputChange(e) { const { value } = e.target; list.innerHTML = ""; if (value === "") { return; } names.filter(name => name.includes(value)).forEach(name => { const p = document.createElement("p"); p.innerText = name; list.append(p); }); } input.addEventListener("keyup", handleInputChange); 

这段代码完美地实现了上述场景的需求。

现在我们这个项目要更加工程化一些，input 和 list 是两个程序员开发的，像下面这样：

// data.js const names = ["张零", "李一", "王二", "张三", "李四", "王五"]; 

// input.js const input = document.createElement("input"); 

// list.js const list = document.createElement("list"); function handleInputChange(e) { const { value } = e.target; list.innerHTML = ""; if (value === "") { return; } names.filter(name => name.includes(value)).forEach(name => { const p = document.createElement("p"); p.innerText = name; list.append(p); }); } input.addEventListener("keyup", handleInputChange); 

我们看list.js的代码，有这些隐患：

• 对 input.js 的引用依赖，这会导致 list 必须晚于 input 加载，但其实这两个组件从意义上讲，并没有这层限制，只是因为程序中有引用才导致这种情况
• list 直接关注了 input 的具体业务逻辑（按键），这是一个问题，每当增加一种修改 input 值的方式，list 就需要多注册一个回调来追踪这种改变。但细想起来，list 真正应该关注的是 input 的数据，而不是 input 有哪些事件可能会修改其数据
• input.js 的迭代非常危险，需要时刻关注有哪些模块在依赖他的事件，对自身事件的增删改操作都会对整个应用伤筋动骨

因此，如果在这种开发模式下去开发一个前端应用，过不了很久，甚至在你的应用变得庞大之前，你已经做不下去了。

为了避免这种困境，我们来对这个小应用进行改造：

codepen

// data.js const names = ["张零", "李一", "王二", "张三", "李四", "王五"]; 

// 共同的数据源 source.js const source = (() => { let data = ""; const listeners = []; return { subscribe(listener) { listeners.push(listener); }, setData(newData) { data = newData; listeners.forEach(listener => listener()); }, getData() { return data; } }; })(); 

// input.js const input = document.createElement("input"); function handleInputChange(e) { source.setData(e.target.value); } input.addEventListener("keyup", handleInputChange); 

// list.js const list = document.createElement("list"); source.subscribe(() => { list.innerHTML = ""; const value = source.getData(); if (value === "") { return; } names.filter(name => name.includes(value)).forEach(name => { const p = document.createElement("p"); p.innerText = name; list.append(p); }); }); 

这样一来是不是变得逻辑非常清晰，input 与 list 互不关心对方的具体实现，从而可以各自实现高内聚的业务逻辑，且完全没有互相的依赖。

状态管理器

其实我们上面的这段代码，就是一个状态管理器的原型。

// 共同的数据源 source.js const source = (() => { let data = ""; const listeners = []; return { subscribe(listener) { listeners.push(listener); }, setData(newData) { data = newData; listeners.forEach(listener => listener()); }, getData() { return data; } }; })(); 

它对状态进行了封装，并提供了一套管理状态的范式。各个模块在这个范式的约定下，对状态进行操作，从而分离模块之间的依赖。

结语

我们通过这个简单的状态管理器原型，成功分离了两个本就应该各自独立的前端模块，这也印证了状态管理器存在的价值。但是状态管理器所用的模式，并非前端领域独有，我们常用的各种 MessageQueue 系统，都是基于相同的模式在工作，也因为 MQ 的存在，大型分布式系统的各个模块间才得以各自独立，消除强依赖。所以这不是一个新的 Dogma，前后端在各自领域对解藕的探索，最终殊途同归。