我对next-redux-wrapper的状态同步机制理解是否正确？

认知确认 #

你的理解是完全正确的。

问题原因解释 #

• next-redux-wrapper 每次触发getServerSideProps时，服务端都会创建全新的独立Redux store实例，无法访问用户浏览器端的客户端store状态，因此你每次进入计数器页面触发SSR时，服务端的新store只会执行store.dispatch(add(3))，生成的状态固定为count=3。
• 服务端生成的store状态会在页面水合（hydrate）阶段合并到客户端store，默认的水合逻辑是直接覆盖对应state字段，因此你之前在客户端修改的计数器数值会被服务端返回的3直接覆盖，表现为跳转回页面后数值重置。

解决方案 #

你可以根据业务场景选择以下任意一种方案解决问题：

1. 若计数器初始值无需服务端计算，直接删除getServerSideProps中的dispatch逻辑，将初始值赋值放到客户端store初始化逻辑中即可，避免每次进入页面都触发服务端状态覆盖。
2. 若必须保留服务端初始化逻辑，可自定义HYDRATE action的reducer处理规则，仅首次初始化时采用服务端返回的数值，后续水合时保留客户端已修改的状态，示例reducer代码如下：

import { HYDRATE } from 'next-redux-wrapper';

const counterReducer = (state = { count: 0 }, action) => {
  switch (action.type) {
    case HYDRATE:
      // 仅客户端count为初始值时采用服务端数值，否则保留客户端状态
      return { 
        ...state, 
        count: state.count === 0 ? action.payload.counter.count : state.count 
      };
    case 'ADD':
      return { ...state, count: state.count + action.payload };
    case 'DELETE':
      return { ...state, count: state.count - action.payload };
    default:
      return state;
  }
};

3. 若该页面无需每次访问都走SSR渲染，也可将计数器状态持久化存储在客户端（如localStorage），初始化时优先读取本地存储的数值，避免服务端状态覆盖。

内容的提问来源于stack exchange，提问作者홍우지