React别当全能选手，让它只做UI渲染

想象一下：你打开一个React项目的组件文件，翻了500行还没找到渲染UI的代码——里面混着用户认证判断、API请求、数据格式化、加载状态管理，甚至还有重试逻辑。这不是特例，是很多React项目的常态：原本只负责画界面的组件，慢慢变成了啥都管的“万能管家”。

你想测试个数据格式化规则，得先搭好React渲染环境；你想在非React项目里复用个权限校验逻辑，发现它死死绑着React的生命周期。开发者@thalesfp也受够了这种混乱，于是做了个叫Snapstate的工具——它要把React拉回“本职岗位”，只干UI渲染，把所有业务逻辑都丢给纯TypeScript类。为什么非要这么折腾？这得从React的“越界”说起。

React的本职与越界

React从诞生起，定位就是“UI库”——说白了，就是个帮你把数据画成界面的工具。就像个厨师，本职是把食材（数据）做成菜（UI），但很多开发者偏要让它同时负责买菜（API请求）、管仓库（状态管理）、定菜单（业务规则）。

这种“全能化”的直接后果，就是组件变得臃肿不堪。比如一个仪表盘组件，既要读用户认证状态，又要发请求拉取数据，还要处理加载、错误、重试，计算未读消息数，甚至还要写标记已读的逻辑。这些代码混在一起，就像把厨房、仓库、办公室塞在同一个房间里：找个东西要翻半天，打扫卫生无从下手，想换个橱柜还得担心碰翻锅碗瓢盆。

更麻烦的是测试和复用。你要测试“标记已读”的逻辑，得先渲染整个组件，模拟用户登录，等数据加载完成——明明是个简单的数组操作，却要搭一整套React环境。你想在小程序里复用这个逻辑？抱歉，它已经和React的生命周期绑死了。

用TypeScript类给React“减负”

Snapstate的核心思路，就是给React做“职责剥离”：让React只当厨师，专心做UI；把买菜、管仓库、定菜单的活，全交给纯TypeScript类——也就是所谓的“类基础状态管理”。

你可以把这些TypeScript类想象成“业务管家”：比如一个DashboardStore类，专门管仪表盘的所有逻辑。它会从认证服务里拿用户ID，自己发请求拉取数据，自己计算未读消息数，自己写标记已读的方法。这些逻辑完全独立于React，不需要依赖任何React钩子或生命周期。

这就像把厨房、仓库、办公室分开：仓库管理员（Store类）负责管食材，厨师（React组件）只负责做菜。你想测试仓库管理员的“盘点”逻辑，直接调它的方法就行，不用管厨师在干嘛；你想换个厨师（比如换成Vue组件），仓库里的食材和管理逻辑完全不用动。

具体到代码里，React组件会变得极其简洁：它只从Store里拿现成的数据（比如统计数据、未读消息数），然后渲染成界面；用户点了“标记已读”，它就通知Store去处理，自己完全不管背后的逻辑。

不是否定钩子，是划清边界

当然，这不是说React钩子不好——钩子本身是为UI场景设计的：比如监听浏览器滚动、协调动画、管理组件本地状态，这些都是React的本职工作。但很多开发者把钩子用在了不该用的地方：写个钩子去拉数据、处理加载状态、做重试，甚至封装成“数据服务”。

这就像让厨师去管仓库进货：虽然也能做，但厨师得同时记着菜谱和库存，还得担心进货时间会不会耽误做菜。更关键的是，这个“进货逻辑”已经和厨师绑死了——换个厨师，进货流程得重新来一遍。

Snapstate也不是要替代Redux、Zustand这些工具，而是提供了另一种思路：Redux像个中央仓库，规则严格但流程繁琐；Zustand轻量但还是基于React钩子；Snapstate则是让每个业务模块都有自己的专属管家，完全独立于React。它没有MobX那种“隐式代理跟踪”的魔法感，所有状态更新都是显式的，你能清楚看到每一步逻辑。

其实，这种“职责分离”的思路，本质上是回归软件开发的基本常识——单一职责原则。让每个模块只干自己最擅长的事，才能让代码更清晰、更易测试、更易复用。

React的强大，在于它能把复杂的UI渲染变得简单；但如果把所有逻辑都塞给它，反而会让它失去优势。Snapstate的出现，不是要颠覆React生态，而是要帮React“减负”，让它回到最擅长的岗位上。

让专业的模块，做专业的事。这不仅是React开发的趋势，也是所有复杂系统保持生命力的底层逻辑。毕竟，全能选手往往样样通、样样松，而各司其职的团队，才能走得更远。