Redux + Effects对复杂的Angular应用程序是否有希望的体系结构？

Question

对于可伸缩的Angular应用程序，我渴望使用redux模式并使用“效果”，“动作”和“实体”。我认为，这使代码更加结构化，因为您必须定义“动作”，“效果”将使用这些动作来触发副作用和“商店”更改。数据将具有良好的结构，并且代码必须位于特定的位置，这使您不太可能拥有混乱的代码。

然后，我也很警惕不要选择可能由于某种原因而终止的解决方案。

那是我想知道是否还有更好的解决方案，或者至少是一个可靠的竞争对手。 “更好”是指更简单（但可伸缩性也不差），以及社区将在不选择其他路线的情况下建立的解决方案。

此体系结构在Angular中是最先进的吗？

[请详细说明您的答案，并在必要时与Redux-Saga和Redux-Thunk或其他解决方案进行比较。

Answer 1

我强烈支持Angular应用程序中的redux模式，因为它具有以下pros：

• UI状态与视图分离
• 与容器表示组件体系结构非常兼容
• 得到社区的大力支持
• UI状态将成为附加的调试工具（取决于您的redux风格）

当与容器表示组件体系结构一起使用时，redux是可伸缩应用程序的绝佳选择。

但是与任何体系结构一样，有一些cons：

• Redux模式和解耦的UI状态的固有优势不会自动等于组织代码。混乱在您的商店模型以及商店与组件之间的通信中占据主导地位很容易。
• 您无疑已经听过很多次了：样板代码。
• [Angular有一些自己的怪癖和社区的版本。如果您的风格过时，则您将困在一个很少维护的库中，或者需要进行大量工作以将其切换出来。
• 它将严重影响应用程序的体系结构。因此，重要的是团队中的所有（或至少是最有主见的）开发人员都参与其中。有些人只是不喜欢它。也可以，只要它们也提供等效或更好的（具体的）解决方案即可。

已解耦的UI状态

Redux应用程序使用store保存所有UI状态，具体取决于您的组件体系结构，特定或所有组件均可访问以更新视图。当然，这并不意味着您无法拥有在组件被销毁时消失的内部组件UI状态。

（以这种方式将（全局）UI状态解耦后，您就可以以不同的方式使用它，通常通过使用所谓的选择器来做到这一点。这类似于使用数据库来获取满足服务器请求所需的所有数据。

容器表示组件体系结构

尽管不是redux模式的一部分，但我敢说Redux模式仅在与容器表示模式一起使用时才在Angular中可接受。

容器：基本上，您将应用程序划分为功能域，每个功能域都有一个所谓的“容器组件”。对于每个功能，这是唯一允许与UI状态和其他应用程序范围内的依赖项（例如，Router，ActivatedRoute）进行通信的组件（有一些不幸的例外）。

容器组件包含您功能域的所有业务逻辑，并协调其单独的表示组件与应用程序范围的依赖项（例如商店，路由器和服务）之间的通信。

[不幸的是，有时将一个容器嵌套在一个容器下面会更容易。例如，在子路由中，通过路由器出口发送数据通常是不值得的。

演示：所有其他组件都是表示组件（哑组件），它们对应用程序的其余部分一无所知。为了设置他们的HTML模板，他们通过@Inputs获取数据。它们也不应（直接）在其HTML模板之外引起任何副作用。例如，要更改UI状态，它不会直接将操作发送到商店，而是通过@output通知容器发生了某些事情，然后容器决定是否应该发送操作。

呈现组件也不会引起任何其他副作用。他们总是使用@outputs通知容器组件，容器组件决定如何处理信息。例如，您的演示文稿显示了超级英雄列表。当用户单击超级英雄以获取更多信息时，您的演示文稿不会打开新页面（它不知道任何页面）。相反，它通过其@output将具有超级英雄ID的事件发送到容器。然后，容器可以打开新页面，打开弹出窗口或更新同级组件等。这样，在限制UI状态更改和其他副作用的情况下，您的演示文稿组件变得更可靠，更易于测试并且可重用到您的容器组件。

替代方案-允许每个组件与存储进行通信或引起其他副作用-是一种反模式，它将消除许多将UI状态解耦的好处。这也意味着您可能会从应用程序的任何位置执行动作。

社区/ Angular Redux口味

不仅在Angular和React中，而且在本机iOS和Android中，对于redux模式也引起了很多兴趣。 Angular上有几种redux风格，它们似乎有足够的吸引力可以使用一段时间，尤其是ngrx / store。

Angular中的redux概念与React中略有不同。例如，redux-thunk是一个反应库，而angular没有完全相同的东西（请注意，如果这是不正确的）。在ngrx / store中，操作是在效果和可观察对象的使用范围内处理的，这可能需要一些时间才能习惯。同样，可能需要链接多个效果才能获得与redux-thunk相同的结果。

就角形的redux风味而言，最受欢迎的是：

• NGRX /存储
• ngxs /存储
• 秋田

已死，或不再保持良好状态：

• angular-redux（sadly）

UI状态作为调试工具

ngrx / store（至少）提供了Chrome Redux DevTools扩展名的使用。这是一个很好的工具，可以检查您的redux存储以及每次分发操作时它如何更改。

样板

当以原始形式使用redux时，您将编写很多样板代码。可以通过以下几种方法减少这种情况：

• 写自己的工厂。例如，为动作编写一个工厂函数，该动作将返回包含以下4个动作的对象：加载，成功，错误，重置。相应地创建效果和缩减器工厂，它们均以定义的方式处理redux模式。
• ngrx有其自己的redux实体变体，其减少样板代码的方式类似于上面的“自行滚动”方法]
• ngrx最近合并了ngrx /数据库，该库甚至进一步在redux中抽象了一些东西，从而实际上消除了对样板代码的需求

组织代码

如上所述，随着应用的发展，您的商店很快就会变得混乱。通常，我们将商店视为视图的镜像，并根据构建的第一个视图定义商店。然后，我们在商店中最终需要重复进行很多重复。

[相反，从每个特定视图退后一步以查看多个视图所需的UI状态并至少部分规范化商店，您可以依靠选择器来构成每个视图所需的UI状态。

与React中的Redux不同，可以通过将其拆分为功能模块来拥有单独的存储。尽管一开始这似乎是一个好主意，但是当您需要在模块之间共享状态时，尤其是在您拥有惰性模块时，通常会带来麻烦。最后，通常不值得麻烦，因此我建议从应用程序模块级别的一家商店开始，直到您绝对需要拆分商店为止。