Redux-组件不同的方法(智能/哑点/容器/演示）

Redux - Component different approaches (Smart / Dumb / Container / Presentation)

本文关键字：哑点 容器 演示 智能 组件 方法 Redux-      更新时间：2023-09-26

所以，我知道没有一种"正确"的方法，但我想谈谈每种方法的优缺点。

因此，在阅读了Dan Abramov的帖子和评论，并复习了本教程后，我想知道这两种不同方法的利弊：

方法A:

├── Smart / Container component
│   ├── Dumb / presentation component
│   │   ├── Dumb / presentation component
│   ├── Dumb / presentation component

停机坪B:

├── Smart / Container component
│   ├── Dumb / presentation component
│   │   ├── Smart / Container component
│   ├── Dumb / presentation component

这里的主要区别在于你如何管理你的州。在选项B中，最深的组件应该知道redux（例如dispach），这可能是一个缺点。在方法A中，您可能需要在树上的许多Dumb组件之间传递道具。

编辑

奇怪的是，在Redux文档的"传递商店"部分，你可以找到"提供者"（反应上下文）背后的"魔法"的引用。在上下文文档中，它清楚地说：

正如在编写清晰的代码时最好避免全局变量一样应避免在大多数情况下使用上下文

和：

在使用此API构建组件之前，请考虑是否存在更清洁的替代品。我们喜欢简单地将项目作为在类似的情况下使用数组

所以，据我所知，这是某种不好的做法？？（选项B…）

它变成了可读性和重新呈现性能的问题。有时，通过几个级别显式传递道具可能更具可读性。其他时候，如果你开始一个新的连接并在那里提取你需要的数据，可能会更容易理解。此外，请注意，connect()做了大量的工作，以确保您自己的组件只有在必要时才重新渲染，这样在连接组件时，您实际上可以获得一些潜在的性能改进。相比之下，"dumb"组件通常不实现shouldComponentUpdate，这意味着它们每次都会重新渲染。

正如您所说，没有一个正确的答案——在对您自己的应用程序结构有意义的地方使用connect()。

编辑：

为了回答您关于React Context文档的问题，React Redux的<Provider>组件专门封装了它碰巧使用Context的事实。这样，如果未来对Context API或行为有任何更改，您自己的应用程序不必担心，因为它可以通过更新到Provider来处理。

换句话说，不用担心：）

相关文章：