Question

我同时学习了React和Redux，并全力投入Redux。基本上所有状态都存储在Redux中。我遵循标准的allIds，byId状态形状模式as detailed here。

我的应用程序非常以数据为中心，它与API通讯，并且执行许多CRUD类型的操作-fetchAll，fetchById，添加，更新，删除。

API通信被隔离到一个“服务层”模块中，该模块是其自己的npm软件包。使用redux-thunk在Redux操作中对此服务层的所有调用。

我已经意识到不需要将所有内容都放在Redux中，例如，确实需要在特定组件上使用数据。而且，我想简化这种架构。

因此，我开始重构为自定义钩子。似乎因为状态状态更多地是对象而不是标量，所以我应该使用useReducer而不是useState ...

// reducer
// ------------------------- 
const initialState = {
  adding: false,
  updating: false,
  deleting: false,
  error: null,
  items: null
};
const reducer = (state, action) => {
// implementation omitted for brevity. . .
}
const useItemsApi = () => {
  const [state, dispatch] = useReducer(reducer, initialState);

  // wrapped in useCallback because called in component's useEffect
  const fetchItems = useCallback(async (options) => {
    try {
      const resp = apiService.fetchItems(options);
    } catch (err) {
      if(err.status === 401) 
         // send to login screen
      else
         dispatch({type: 'error', payload: err});
    }
  }, [options]);

  // addItem, updateItem, deleteItem, etc...

  const actions = {fetchItems, updateItem, addItem, deleteItem};
  return [state, actions];
};

// component
// ------------------------- 
const component = (props) => {
  const [state, actions] = useItemsApi();
  const {fetchItems, updateItem, addItem, deleteItem} = actions;
  useEffect(() => {
     fetchItems()
  }, fetchItems);

  // omitted for brevity...
}

当我需要在化简器中为更新操作设置状态时，我意识到如果使用“ allIds”和“ byId”模式会更容易。

在这一点上，我想-与使用Redux有什么不同？

最终看起来几乎是完全相同的代码，我失去了选择器的某些功能，但消除了redux-thunk的复杂性。而且我当前的redux动作包括特定的用例动作（例如，对于项目类型X的特殊保存），所以我需要为这些地方找到一个地方。

我的问题是-是否有任何理由使用本地状态将其重构为一个钩子？

Answer 1

对我来说，这真的可以归结为三件事：

是否需要Redux的中间件，日志记录功能等
您对未来的稳定性有多关注
个人品味

Redux提供的more不仅仅是状态管理。
将上下文处理工作转移到Redux对我来说是一个很大的进步，我对未来充满期待。
如果您的应用程序是以数据为中心的，那么我不会忽略redux-devtools和其他中间件（我个人很喜欢redux-observable）。
当您的应用程序变得越来越复杂时，您将需要查找损坏的状态更新以及意外触发了多次的状态。
但是话又说回来，只有您可以评估自己的应用程序的复杂性以及将来的发展方向。

本文的其余部分为“个人品味”，但我将其添加。

我个人喜欢使用Redux的原因与之前提到的原因有所不同。
我使用Redux甚至在不久之前根本没有使用React，并且还使用了一个没人听说过的框架，这是Salesforce的Lightning Web组件框架。
关键在于它将状态管理和视图逻辑保留在单独的库中。
个人，我并不赞成React成为瑞士军刀。
对我而言，React的核心优势是它是一个具有明确目的的，具有虚拟DOM的视图库，而现在...好吧，它之间的边界在哪里变成了自以为是的框架？
没有强加使用React钩子，但是还是有点。
如果您使用React，那么您将全部使用它，这个问题为这一结论致敬。

在这一点上，我想-这与使用Redux有什么不同？

因此您将Redux重构为useReducer钩子，然后想知道为什么我需要这个？如果您问，那么您可能没有。
也许这只是您问题的答案。
Reducer功能刚刚从状态管理库移至视图库（或者是？）。酷（我猜）。

Answer 2

在Redux中存储状态的优势：

您可以全局访问和修改它
即使卸载了组件，它仍然存在

将状态存储在组件中的优点：

您可以在状态中包含多个具有不同值的组件，这可能是您想要的
...或者您甚至可以在一个组件中使用多个相同类型的钩子！
您不需要在文件之间切换。根据代码的组织方式，可以将Redux分为3个文件和1个用于使用它的组件的文件-尽管这可以帮助您的代码在复杂的使用案例中保持良好的结构化，但是对于跟踪某个应用程序而言，这可能是一个过大的杀伤力简单状态。必须在多个文件之间切换才能在一个组件上工作会降低您的生产率（我不希望必须在IDE中跟踪我所使用的每个功能的4个选项卡）。
^{（而且，钩子是新的而且很酷。）}

因此，如果满足以下条件，请使用Redux：

您需要在多个组件之间共享状态（或将来计划）
即使卸载使用它的组件，您也需要保持状态

在其他情况下，您可能更喜欢将状态保持在React（无论是鸣叫还是其他方式）中，因为它们会稍微简化您的代码。

但这并不意味着您需要重构整个代码库。如果您认为您的代码足够简洁，并且喜欢它的组织方式，或者不确定不确定将来是否需要全局状态，则可以将其保留在Redux中-这没什么问题！

Answer 3

不，您不必这样做。从我的角度来看，如果仅将Redux作为状态管理库，则可以将其替换为Hooks（useReducers ect）+本地/共享状态。

Redux先于钩子出现，并且我们的应用已由Redux实现，绝对不需要替换它。

我们可以计划在新项目中使用钩子+共享状态作为替代方案。

我确实遇到了三种情况：

仅限Redux；
仅挂钩；
Redux +挂钩；

他们所有人都很好。

这是我们在Redux和Hooks过渡中的困境。挂钩的制作方法不替代redux，但如果需要，可以这样做。

因此，将来您可以根据使用情况使用其中的任何一种。

希望有帮助。

Redux与自定义钩子

3 个答案: