我正在努力寻找用良好的编码模式在 React 中实现组件的好方法。
通常我知道展示组件和容器组件的想法:展示组件仅显示 html 并从 props 接收所有内容(数据和回调)；容器编排表示检索和变异数据并通过 props 将其传递给它们。
现在我将 redux 与 redux 工具包和 rtk 查询一起使用，并带有钩子(Hook)。
按照这种方法，容器组件应该是唯一允许使用 useSelector 、 useDispatch 和 useQuery 的组件。但我发现更容易和更清晰，允许演示文稿选择、获取和分派(dispatch)他们真正需要的内容，而不是制作一个巨大的容器组件，通过大量的状态和获取访问权限来管理其子级的所有数据。对于列表尤其如此，让每个子项检索自己的数据(获取或从状态)或深度嵌套的表示会更容易、更清晰。
但是，我将容器组件与虚假的演示文稿混合在一起，无论如何，这些演示文稿都会在更容易的情况下检索某些内容，而真实的演示文稿可能适用于一般且完全可重用的组件。而且组件树非常困惑(比如容器->假展示->容器->假展示->真展示->真展示...)。
最后我觉得我没有好的规则，代码也很困惑。
容器和表示组件仍然是一种遵循最佳实践模式的良好编码风格，但在钩子(Hook)和 redux 的世界中吗？
最佳答案
自 2018 年引入 React hooks 以来，Dan Abramov 倡导的 React 容器模式已被弃用。
请参阅 Dan 的博客条目 Presentational and Container Components从2015年开始。
他 2019 年的更新:
Update from 2019: I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore. If you find it natural in your codebase, this pattern can be handy. But I’ve seen it enforced without any necessity and with almost dogmatic fervor far too many times. The main reason I found it useful was because it let me separate complex stateful logic from other aspects of the component. Hooks let me do the same thing without an arbitrary division. This text is left intact for historical reasons but don’t take it too seriously.
随着 React hooks 的出现，“智能”和“哑”组件、“容器”和“演示”组件之间的区别几乎被消除了。
现在的常见模式和“最佳实践”是编写 React Function 组件并仅使用 React hooks。在使用 Redux 和 React-Redux 的情况下，使用 useDispatch 和 useSelector 钩子(Hook)而不是 connect 高阶组件。自从 React hooks 出现以来，我就没有特意编写 React 类组件，也没有在“表示”和“容器”之间拆分代码。
关于javascript - 使用钩子(Hook)和状态来 react 纯组件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/74838207/