Angular (2+) 组件结构和设计 - 最佳实践

Question

这是一个建筑设计问题。

我有一个名为 X 的 mySQL 表。 我从 2+ 角度的前端对其进行了 CRUD 操作。

为了开始，我创建了一个组件，我碰巧称之为create-new。这家伙现在在/create-new 路线上运行。

但是，随着我的开发，这个 create-new 组件（以及它的 .ts、.html 和 .css 朋友）已经变得非常通用，可以处理，不仅仅是 create-new（因此 insert ）情况，而是还有更新。

此更新不仅可以在创建新操作之后立即工作（使用新插入的 ID ）以允许立即更新新创建的记录，还可以加载另一个记录的数据以提供它的更新形式。

因此，很自然，这条 /create-new 路由现在已经能够处理基于参数的请求，例如 /create-new/?action=edit&rec_id=10

而且我喜欢这样一个事实，即最初的 create-new 代码库非常容易升级到此功能。现在插入、更新操作都完成了，不禁想，好吧，我为什么不添加DELETE、LIST-VIEW和DETAIL-VIEW功能并完成它。这就是需要挑选经验丰富的大脑的架构设计问题。

这种方法的专家，我有一个组件，它映射到一个单独的文件夹、一个单独的 .ts、.html、.css 和服务器端 .php 页面，该页面非常适合与该表 X 一起使用。这使得复制这个功能变得超级容易，让我们自己得到另一个准备好处理表 Y 上的所有 CRUD 需求的集合，只需对克隆基础进行很少的调整。

我知道常见的模式是让一个组件用于新建，一个用于查看记录，一个用于查看列表。

我的问题如下：这种全能的方法（我刚才在上面描述的）在所有情况下都是绝对的 NO-NO-APPROACH 吗？

或者，我们可以说嘿，这不是什么大不了的事，事实上，根据情况，它可能是推荐的方法？

如果可以采用这种统一的方法，我只需用 manage-X 更改名称 create-new 即可。然后下一个人将被命名为manage-y，依此类推。我确实意识到，使用这种方法，HTML 部分可能会对这种全能风格更加敏感。在这种情况下，我将不得不处理一个更长的 .HTML 文件（它不仅会托管与表 X 对话的 add-edit-form，而且还会托管显示表 X 中的记录的视图列表和视图详细信息情况. 但这是我可以忍受的限制。

再次，回到问题..

应该永远不要采用这种方法吗？ 或者在某些情况下它保证它应该是要走的路？

如果可以构建这样的组件，那么决定采用这种整合方法的主要标准是什么？

Answer 1

实际上有一些风格指南说不应该这样做，但恰恰相反。组件应尽可能小，并遵循单一职责原则。

来自文档：

将单一职责原则 (SRP) 应用于所有组件， 服务和其他符号。这有助于使应用程序更清洁、更轻松 易于阅读和维护，并且更易于测试。

参考：https://angular.io/guide/styleguide#single-responsibility