将 SWR 与 Redux 一起使用是正确的还是好的做法？

Question

我正在使用SWR

在我的代码中，我使用了两者的交界处，如下所示

const vehiclesStates = useSelector(({ vehiclesStates: state }) => state); // REDUX
const response = useFetch("/vehicles/states") // SWR
const dispatch = useDispatch(); // REDUX

// REDUX
useEffect(() => {
  if(response.data) dispatch(VehiclesStatesActions.setVehiclesStates(response.data.result))
}, [response.data, dispatch]);

if(response.error) return <div>ERROR - {response.error.toString()}</div> // SWR
else if(!response.data) return <div>LOADING</div> // SWR

// If there is a return I render my component
return (<></>)

在上面的这段摘录中，我使用我使用 SWR（与 axios 集成）返回的数据在 redux 中设置了我的组件状态。这样，在需要使用相同数据的任何其他组件中，我只使用 redux 的useSelect导入它。

这边走

const vehiclesStates = useSelector(({ vehiclesStates: state }) => state);

我发现这比通过在每个想要使用该数据的组件上调用 useFetch 来使用 SWR 更实用。

我的问题是：使用这种方式是一种正确的方式，还是会影响性能或其他什么？

提前致谢

Answer 1

您可以将 swr 与 redux 一起使用，这并不是多余的。因为有两种类型的状态。UI State和Server Caching State。Ui 状态的一个示例是模式是否打开或关闭。服务器缓存状态，我们调用api，存储结果并缓存该结果以供客户端使用。swr正在处理服务器缓存状态。

在 redux 的早期，没有缓存。然后一些库出现了，在 next.js swr 中，在 React React-Query 库中。Redux-toolkit有自己的 api 缓存实现。

我认为通过 React-16，我们有了上下文 api。React context 本身并不是一个状态管理工具。它只是传输数据的一种手段。useState如果与或 一起使用，它就成为状态管理工具useReducer。将 React Context 与自己的 hooks 结合起来，就可以替代 redux。在你的钩子函数中你应该使用swr. 我在这里解释了如何结合react-context、hooks和swr来创建一个完整的状态管理工具：全局状态管理和Next.js

Answer 2

我认为这有点多余，您可以更好地使用一个或另一个，SWR 旨在将缓存用作本地状态，因为该状态存在于服务器上，它更加丰富并且使您无需冗长地管理状态中的每个操作，就像您必须在任何时候调度操作时显式调用 API 调用的 redux 一样。

使用这两种方式都可以打败 SWR 的目的，那么你只使用 Redux 会更好。一个很好的规则是使用 SWR 来管理服务器中的状态，使用 Redux 来管理本地状态。

我可以看到两者共存的一些场景，当你有一个非常复杂的数据操作，你必须经常修改和删除信息时，我认为这种情况将使用 redux 和 SWR 的 mutate 功能的某种混合。