使用@rematch/core时接口请求成功但数据未写入state问题求助

问题场景 #

首次接入@rematch/core时，发起的内部接口请求已成功返回数据，但对应模型的响应值没有写入关联的Redux状态；同套代码逻辑下，navigation模型的状态可以正常更新，无法定位差异原因。

核心差异定位 #

逐行对比两个模型的实现代码，可以定位到以下导致状态不更新的关键问题：

• Action 命名匹配链路完全断裂
  Rematch 配合你使用的@vostok/rematch-loading插件，内置了基于命名约定的状态更新规则：模型下以xxx_request命名的effect发起请求后，插件会自动将返回值通过同模型下xxx_fulfilled命名的reducer写入状态，完成状态闭环。
  • navigation模型的effect命名为get_request，同模型下存在get_fulfilled的reducer，刚好命中上述匹配规则，因此可以正常完成状态更新
  • proceedings模型存在两处核心不匹配：
    1. effect命名为get_users，和同模型下get_fulfilled的前缀get没有形成约定的匹配关系，即使effect执行完成，插件也无法识别需要触发的reducer，对应的状态更新逻辑根本不会运行
    2. 现有Main组件代码中，只调用了dispatch.navigation.get_request()，全程没有触发过proceedings模型的effect，初始请求逻辑没有在proceedings的关联页面执行

  注意：即使你在其他位置手动触发了proceedings/get_users请求、控制台能打印出res.data，因为effect和reducer之间没有建立Rematch约定的命名匹配关系，reducer永远不会接收到这份返回值，也就不会触发状态更新。

• 模型定义格式的非关键差异
  • navigation模型的effects为直接对象形式：effects: { async get_request() {...} }
  • proceedings模型的effects为返回对象的函数形式：effects: () => ({ async get_users() {...} })
    该写法Rematch本身是支持的，不会直接导致状态更新失败，但会增加和其他模型的维护对齐成本。

可落地的修复步骤 #

• 统一proceedings模型的effects写法，和navigation模型保持一致，降低后续维护的格式对齐成本
• 调整proceedings模型的effect命名，将get_users改为get_request，和同模型下get_fulfilled的命名规则对齐，确保请求返回值能正常触达对应的reducer
• 在需要加载诉讼数据的页面组件（如PageProceedings）中，添加effect触发逻辑：在组件的useEffect钩子中调用dispatch.proceedings.get_request()，确保请求逻辑在页面加载时实际执行
• 校验接口返回的res.data结构，确保和模型声明的Models.Proceedings[]类型完全匹配，避免因返回值结构异常导致的状态写入失效

内容的提问来源于stack exchange，提问作者Sergey Eromchenko