easy-model：我从“状态容器”转向“业务模型”的一次迁移记录

写这篇文章是因为我在一个中型 React 项目里，经历了一次典型的“状态管理疲劳”。业务越来越复杂，状态层也越来越像一锅粥：action、reducer、selector、async side effects 到处都是，功能能跑，但每次改动都要穿越一堆文件。大家明明在写业务，却总在修状态管道。

后来我们在重构时尝试了 easy-model。它给我的第一感受不是“又一个库”，而是：终于可以用类来写业务模型了。这是我熟悉的表达方式——字段就是状态，方法就是业务逻辑，依赖关系靠注入，变化靠监听。业务“看得懂”，结构“也站得住”。

最直观的变化是心智模型的迁移：

• 以前是“状态容器思维”：先想 store、切片、action，然后把业务塞进去。
• 现在是“模型思维”：先写业务模型，状态自然附着在模型上。

下面是一个最小的例子，但能体现核心体验：

import { useModel, useWatcher } from "easy-model";

class CounterModel {
  count = 0;
  label: string;
  constructor(initial = 0, label = "计数器") {
    this.count = initial;
    this.label = label;
  }
  increment() {
    this.count += 1;
  }
  decrement() {
    this.count -= 1;
  }
}

function Counter() {
  const counter = useModel(CounterModel, [0, "示例"]);

  useWatcher(counter, (keys, prev, next) => {
    console.log("changed:", keys.join("."), prev, "->", next);
  });

  return (
    <div>
      <h2>{counter.label}</h2>
      <div>{counter.count}</div>
      <button onClick={() => counter.decrement()}>-</button>
      <button onClick={() => counter.increment()}>+</button>
    </div>
  );
}

这种写法最大的价值，不是“少写几行”，而是让业务逻辑回到模型里。当你习惯用类来描述业务（service、domain model），你会发现状态层自然贴合了业务结构。

再进一步，在 easy-model 里我们开始把依赖注入当作“默认能力”而不是“额外工具”。复杂项目里，DI 会让测试和模块拆分顺很多。加上深度监听（watch / useWatcher），你不用自己手写各种订阅逻辑，就能追踪复杂对象的变化链路。

如果你也在经历“状态容器疲劳”，或者正在考虑从 Redux/MobX/Zustand 迁移，我的建议是：把 easy-model 当作一种“业务模型范式”，而不是“状态工具”。试着写几个模型类，你很快能感受到差异。

GitHub: easy-model

npm: @e7w/easy-model