Normy 数据缓存自动更新的边界为什么顶层数组仍需手动更新以及 2 种实用应对策略【免费下载链接】normyAutomatic normalization and data updates for data fetching libraries (react-query, vue-query, trpc, swr, rtk-query and more)项目地址: https://gitcode.com/gh_mirrors/no/normy如果你正在使用 react-query、SWR 或 RTK Query那么 Normy 这个开源库值得了解它负责对接口数据进行自动数据归一化并在 mutation 成功后自动更新所有相关缓存让你告别手动维护setQueryData的繁琐代码。但 Normy 的自动化有一个明确的边界——顶层数组的增删排序仍需手动处理。本文帮你看懂这个边界产生的原因并给出 2 种简单实用的应对策略。一、Normy 能自动做什么先划清能力范围Normy 的核心逻辑在 packages/normy/src/normalize.ts所有带id的对象无论嵌套多深都会被按 id 存入一个共享的归一化存储而各个查询的数据只保留对这些对象的引用。于是当 mutation 返回{ id: 1, name: Name 1 Updated }时create-normalizer.ts 中的getQueriesToUpdate会找到所有依赖了id: 1这个对象的查询把归一化存储中的对象深合并deep merge为新值自动把新数据写回每一个相关查询的缓存。一张表看懂 Normy 自动更新的边界场景是否自动原因修改对象的字段如书名、作者名✅ 自动按 id 匹配并深合并所有依赖查询同步更新更新嵌套对象列表如书籍的likedByUsers✅ 自动列表属于对象内部属性整体合并向顶层数组追加新对象❌ 手动新对象尚不在任何查询中不存在依赖关系从顶层数组删除对象❌ 手动同一对象可能出现在多个查询库无法猜你的意图对顶层数组重新排序❌ 手动顺序只存在于各查询自身不在共享存储中二、为什么顶层数组是个例外原因并不复杂官方 README 在 Normalization of arrays 一节 里解释得很清楚ADD_BOOKNormy 不知道新对象应该被加进哪一个查询的数组也不知道加在第几个位置REMOVE_BOOK一本书可能同时出现在全部书籍列表和我的收藏等多个查询里Normy 不知道你想从哪些列表里移除它SORT_BOOKS数组的顺序信息只存在于各个查询自己的缓存中共享的归一化存储里只有对象内容没有数组成员关系。换个角度理解Normy 的共享存储是一张对象 id → 对象内容的表而哪些对象出现在哪个列表、按什么顺序是每个查询自己的事。所以**内容交给 Normy 自动同步成员关系留给你手动决定**——这正是它的设计边界。 注意这个限制只针对顶层数组。只要对象列表是某个带 id 对象的属性例如book.likedByUsersmutation 返回更新后的完整对象即可自动生效。三、应对策略 1手动补数组自动补字段最简单直接的做法顶层数组用数据获取库自带的 API 手动更新对象内容交给 Normy 自动同步两者分工协作。以 react-query 为例添加新书时只需在 mutation 的onSuccess里手动把新对象拼进[books]这个查询的缓存示例见 examples/react-query/src/components/app.jsxonSuccess: mutationData { queryClient.setQueryData([books], data data.concat(mutationData)); }这之后如果该书的作者信息又发生了变化Normy 会自动把更新同步到书籍列表、书籍详情等所有相关查询——你完全不用手写map 判断 id 的代码。 适用场景新增、替换单条数据等目标查询明确的操作代码量最少。四、应对策略 2先用 getDependentQueries 定位再批量更新当一次操作影响多个查询的顶层数组时比如从全部列表收藏最近浏览同时移除一本书手动猜查询 key 很容易漏。这时可以利用 Normy 内置的依赖查询能力getDependentQueries传入一段包含对象的数据如{ id: 1 }返回所有持有该对象的查询 key 列表getDependentQueriesByIds直接传 id 数组效果相同。拿到 key 列表后你可以用 react-query 的invalidateQueries让相关查询重新拉取或逐个setQueryData从数组中过滤掉目标对象。 同样的能力在 SWR 和 RTK Query 集成中也有对应实现可参考 packages/normy-swr/src/SWRNormalizerProvider.tsx 与 packages/normy-rtk-query/src/index.ts。 适用场景删除、排序等跨多个查询的操作避免漏更新某个列表的 bug。五、小结把 Normy 用在刀刃上对象字段变更→ 完全交给 Normy 自动更新这是它最大的价值顶层数组增删排序→ 手动处理查询明确就用策略 1跨多查询就用策略 2 先定位再批量更新项目作者也表示未来版本计划通过额外的指针机制把这些更新也自动化值得持续关注 CHANGELOG。理解这个边界后你会发现Normy 的自动化覆盖了你日常 80% 以上的缓存同步场景剩下的 20% 也有清晰的应对方案——这正是它简单又实用的地方。【免费下载链接】normyAutomatic normalization and data updates for data fetching libraries (react-query, vue-query, trpc, swr, rtk-query and more)项目地址: https://gitcode.com/gh_mirrors/no/normy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Normy 数据缓存自动更新的边界：为什么顶层数组仍需手动更新，以及 2 种实用应对策略
Normy 数据缓存自动更新的边界为什么顶层数组仍需手动更新以及 2 种实用应对策略【免费下载链接】normyAutomatic normalization and data updates for data fetching libraries (react-query, vue-query, trpc, swr, rtk-query and more)项目地址: https://gitcode.com/gh_mirrors/no/normy如果你正在使用 react-query、SWR 或 RTK Query那么 Normy 这个开源库值得了解它负责对接口数据进行自动数据归一化并在 mutation 成功后自动更新所有相关缓存让你告别手动维护setQueryData的繁琐代码。但 Normy 的自动化有一个明确的边界——顶层数组的增删排序仍需手动处理。本文帮你看懂这个边界产生的原因并给出 2 种简单实用的应对策略。一、Normy 能自动做什么先划清能力范围Normy 的核心逻辑在 packages/normy/src/normalize.ts所有带id的对象无论嵌套多深都会被按 id 存入一个共享的归一化存储而各个查询的数据只保留对这些对象的引用。于是当 mutation 返回{ id: 1, name: Name 1 Updated }时create-normalizer.ts 中的getQueriesToUpdate会找到所有依赖了id: 1这个对象的查询把归一化存储中的对象深合并deep merge为新值自动把新数据写回每一个相关查询的缓存。一张表看懂 Normy 自动更新的边界场景是否自动原因修改对象的字段如书名、作者名✅ 自动按 id 匹配并深合并所有依赖查询同步更新更新嵌套对象列表如书籍的likedByUsers✅ 自动列表属于对象内部属性整体合并向顶层数组追加新对象❌ 手动新对象尚不在任何查询中不存在依赖关系从顶层数组删除对象❌ 手动同一对象可能出现在多个查询库无法猜你的意图对顶层数组重新排序❌ 手动顺序只存在于各查询自身不在共享存储中二、为什么顶层数组是个例外原因并不复杂官方 README 在 Normalization of arrays 一节 里解释得很清楚ADD_BOOKNormy 不知道新对象应该被加进哪一个查询的数组也不知道加在第几个位置REMOVE_BOOK一本书可能同时出现在全部书籍列表和我的收藏等多个查询里Normy 不知道你想从哪些列表里移除它SORT_BOOKS数组的顺序信息只存在于各个查询自己的缓存中共享的归一化存储里只有对象内容没有数组成员关系。换个角度理解Normy 的共享存储是一张对象 id → 对象内容的表而哪些对象出现在哪个列表、按什么顺序是每个查询自己的事。所以**内容交给 Normy 自动同步成员关系留给你手动决定**——这正是它的设计边界。 注意这个限制只针对顶层数组。只要对象列表是某个带 id 对象的属性例如book.likedByUsersmutation 返回更新后的完整对象即可自动生效。三、应对策略 1手动补数组自动补字段最简单直接的做法顶层数组用数据获取库自带的 API 手动更新对象内容交给 Normy 自动同步两者分工协作。以 react-query 为例添加新书时只需在 mutation 的onSuccess里手动把新对象拼进[books]这个查询的缓存示例见 examples/react-query/src/components/app.jsxonSuccess: mutationData { queryClient.setQueryData([books], data data.concat(mutationData)); }这之后如果该书的作者信息又发生了变化Normy 会自动把更新同步到书籍列表、书籍详情等所有相关查询——你完全不用手写map 判断 id 的代码。 适用场景新增、替换单条数据等目标查询明确的操作代码量最少。四、应对策略 2先用 getDependentQueries 定位再批量更新当一次操作影响多个查询的顶层数组时比如从全部列表收藏最近浏览同时移除一本书手动猜查询 key 很容易漏。这时可以利用 Normy 内置的依赖查询能力getDependentQueries传入一段包含对象的数据如{ id: 1 }返回所有持有该对象的查询 key 列表getDependentQueriesByIds直接传 id 数组效果相同。拿到 key 列表后你可以用 react-query 的invalidateQueries让相关查询重新拉取或逐个setQueryData从数组中过滤掉目标对象。 同样的能力在 SWR 和 RTK Query 集成中也有对应实现可参考 packages/normy-swr/src/SWRNormalizerProvider.tsx 与 packages/normy-rtk-query/src/index.ts。 适用场景删除、排序等跨多个查询的操作避免漏更新某个列表的 bug。五、小结把 Normy 用在刀刃上对象字段变更→ 完全交给 Normy 自动更新这是它最大的价值顶层数组增删排序→ 手动处理查询明确就用策略 1跨多查询就用策略 2 先定位再批量更新项目作者也表示未来版本计划通过额外的指针机制把这些更新也自动化值得持续关注 CHANGELOG。理解这个边界后你会发现Normy 的自动化覆盖了你日常 80% 以上的缓存同步场景剩下的 20% 也有清晰的应对方案——这正是它简单又实用的地方。【免费下载链接】normyAutomatic normalization and data updates for data fetching libraries (react-query, vue-query, trpc, swr, rtk-query and more)项目地址: https://gitcode.com/gh_mirrors/no/normy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考