【问题标题】:Is this a dumb idea for how to simplify redux + react?对于如何简化 redux + react,这是一个愚蠢的想法吗?
【发布时间】:2021-10-01 00:23:02
【问题描述】:

我正在尝试重构应用程序以使用 redux 工具包,但在调度操作以设置状态时遇到了无限循环,我怀疑这是因为我没有遵循约定。

我试图在高层次上做的是有一个useAppHandlers 钩子,它返回整个应用程序的所有处理程序。同样,我有一个useAppState 钩子,它返回一个全局对象,其中 all 我的状态。来自my config file的片段:

export const useAppState = () => {
  const coingeckoApiState: AppState[typeof coingeckoApi.reducerPath] = useSelector(state => state.coingeckoApi);
  const connectionState: AppState['connection'] = useSelector(state => state.connection);
  const currencyState: AppState['currency'] = useSelector(state => state.currency);
  return { ...coingeckoApiState, ...connectionState, ...currencyState };
};

export const useAppHandlers = () => {
  const connectionHandlers = useConnectionHandlers();
  const currencyHandlers = useCurrencyHandlers();
  return { ...connectionHandlers, ...currencyHandlers };
};

^^这看起来有问题吗?很遗憾,我无法分享完整的 repo,因为它是私有的。

在我遇到的所有 redux 示例中,除了他们在每个组件中调度的操作之外,人们还导入 useDispatch。我真的不喜欢它如何导致这么多行代码仅用于导入和设置 ex: const dispatch = useDispatch() 在 repo 中重复令人作呕)。

这个 repo 是我试图避免的真实示例:

https://github.com/Uniswap/uniswap-interface/blob/4078390a4890445d1ff0ed5196fd4cb56a44de87/src/components/NavigationTabs/index.tsx#L116

在我放弃并遵循惯例之前,我想确定一下我配置 redux 的上述方式是否是无限循环的来源,或者它是否是我在代码中更深入地引入的随机错误。

【问题讨论】:

  • 我不认为这是导致无限循环的原因,但让每个组件都依赖于整个应用程序状态并不是最佳做法。我不认为它一定是有害的。如果您可以创建一个简化的示例来演示您的无限循环,那么我很乐意看看它。这是一个展示他们的计数器应用程序的示例 RTK 应用程序:codesandbox.io/s/rtk-counter-sample-ly8xe
  • 谢谢。我将进行更多测试以缩小问题范围并报告。

标签: reactjs redux redux-toolkit


【解决方案1】:

老实说,不要。如果在创建这样的上帝对象时需要这样做,您将永远无法在未来进行捆绑拆分。此外,现在添加一些内容意味着您必须至少再触摸一个未使用该内容的文件 - 删除也是如此。

除此之外,编写如此“宽”的选择器来选择一个完整的切片,即使你的组件只消耗了该切片的一部分,这对你的性能来说是一件可怕的事情——如果任何东西,这些组件总是会重新呈现 在该切片中发生变化,无论它对您的组件是否重要。

最后:忽略您的导入并让您的 IDE 为您处理它,可能是开箱即用的。您的 IDE 可以为您自动导入它们。您可以配置您的 IDE(使用 eslint autofix 或其他插件)以自动按字母顺序对导入进行排序,并在保存时删除未使用的导入。我敢肯定,如果您不想看到它们,甚至有一个插件会为您折叠您的导入。

PS:至于 why 在 react-redux 中你通常会在任何地方导入 useDispatch,你可以在这里阅读一些关于该决定的历史:https://react-redux.js.org/api/hooks#recipe-useactions

【讨论】:

  • 好的,谢谢。我开始意识到为什么它是这样设计的。但是我仍然很困惑为什么像 reactn 这样的库能够摆脱如此简单的 API (github.com/CharlesStover/reactn#readme) ...如果不是因为它更差的打字稿支持和更小的开发人员采用率,我会使用它,但也许还有其他我没有看到的权衡?
  • 我想权衡是(我对那个库没有经验)它似乎与 React 组件更紧密地交织在一起,可能不太可测试,你很容易发生冲突,并且当一切都没有真正的数据流时理论上可以只写状态。 Redux 首先是一种数据流模式。但这一切可能是高度个人化的:)
【解决方案2】:

试试 mobx,老实说现在没人会用 react-redux。

【讨论】:

  • 提问者不是在寻找替代状态管理器。
猜你喜欢
  • 1970-01-01
  • 2011-06-09
  • 2013-03-01
  • 2020-09-03
  • 2015-02-12
  • 2021-09-05
  • 2013-08-14
  • 2020-03-26
相关资源
最近更新 更多