北京
“不是特别优雅，但符合我的思维模型。”Jotai创建者Daishi Kato如此评价v2.20.0版本中一次关键的架构取舍。
这个React原子化状态管理库刚刚完成了一次以性能为重点的内部重构。核心贡献者David Maskasky主导了这组底层改动，目标很直接：提升高吞吐场景下的响应速度。
具体改动集中在一个点上——重做Store的构建模块。为了避免使用getInternalBuildingBlock函数，团队为onMount hooks引入了Rev3类型收窄，并在ensureAtomState中为新atom state加入了延迟hooks。三处调整看起来不大，但触及了Jotai的存储底层。
故事要从一年多前说起。v2.12.0版本首次引入了“构建模块”理念，把部分内部机制暴露给生态库作者。jotai-effect和jotai-scope这类扩展项目，正是靠着这套机制才得以打通核心能力。
Kato当时面临一个选择：是在Store创建完成后再开放扩展接口，还是在构建过程中就接受定制化配置？他选了后者。原因很简单——事后扩展可能导致能力不匹配，随着时间推移，可能出现越来越难以维护的碎片化问题。到了v2.15.0左右，这套API达到了他理想中的状态：足够灵活，同时“不容易被误用”。
但这种灵活性不是免费的。有开发者反馈出现了性能下降，追查下来，罪魁祸首是为了让构建模块更加灵活而引入的WeakMap方案。修复手段很直接：把WeakMap全部去掉，改成通过参数传递所有内容。
Kato自己对这次改动的评价相当坦诚——“不够优雅”，但有效。在Read the Code newsletter中，他明确表示这次发布是为Jotai v3做准备之前的最后一步。换句话说，v2.20.0不是终点，而是更大版本迭代前的垫脚石。
对于绝大多数普通开发者，这次更新几乎无感。创建和使用store的API没有任何变化。“破坏性变更”这个标签针对的是供库作者使用的内部构建模块，不会影响到业务代码。不过下游生态需要跟上节奏：jotai-devtools v0.14.0已经增加了对INTERNAL_buildStoreRev3的支持，同时移除了旧版本兼容。
仍在用Jotai v1的团队得行动起来了，官方提供了v2迁移指南。而atomFamily的用户需要注意，这个功能已经被标记为弃用，Jotai v3会推荐使用jotai-family包来替代。目前团队已经发布了两个补丁版本——v2.20.1和v2.20.2，继续修复边缘场景的兼容问题。
社区对这个小版本更新的反响相对平淡，这很正常，底层架构调整从来不是能让开发者兴奋的新闻。但围绕v3长期规划的讨论，一直在持续吸引核心贡献者参与。
Kato已经在公开场合抛出了Jotai v3的路线图。除重新设计构建模块数组结构——这正是本次v2.20.0涉及的核心机制——之外，还计划移除CommonJS构建、停止支持React 18以下版本，以及移除setSelf选项。
这些提议立刻引发了讨论。一位贡献者对移除CJS的计划表达了支持：“99.9999%的Jotai用户都在用某种构建工具，这些工具全都很好地支持ESM。剩下那0.0001%用纯ESM模块的用户……嗯，他们本来就在用ESM：）”这番话挺直接，但Kato的回复补充了另一个视角：服务端渲染用户的需求仍然需要考虑。
当有人提出降低Jotai与React的耦合度、吸引其他框架用户时，Kato的回应是明确的：坚持React优先的立场。这不是技术问题，而是战略选择。
放眼更广泛的生态，Jotai仍然是原子化状态管理领域的重要方案之一。不过在原始下载量方面，它排在Kato自己创建的另一个库Zustand之后。有意思的是，三个由同一位作者创建的状态管理工具，解决的是完全不同的问题。Jotai采用自底向上的atoms模型，类似Recoil；Zustand提供的是单一自顶向下的store，更接近Redux的思路；而Valtio基于代理机制，面向的是另一套思维模型。
Jotai采用MIT许可证开源，可以直接通过npm安装。这次v2.20.0的发布虽然不张扬，但它揭示了一个成熟开源项目在灵活性、性能和可维护性之间的真实权衡：有时候，放弃一个“更优雅”的技术方案，反而是向前走的最快方式。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
