积跬步,至千里
精前端,通全栈

通过Angular DI和multi 选项更好地去组织你的代码

几乎在每个应用程序中都有一个文件,我们把所有的endpoints都放到里边。如果你正在使用Angular,它可能看起来像这样:

乍一看,一切看起来都很好,但随着应用程序的增长,这个文件也会产生一些问题。

我们违反了单一的责任。我们暴露于合并冲突,我们的端点不可移植,并且在文件中找到端点位置变得困难。

我们需要将责任分配给负责的模块,因此每个模块负责揭示其端点。

然后,我们可以在我们的API服务中汇总和加入整个端点。

让我们来看看如何在Angular 依赖注入DImulti选项的帮助下做到这一点。

创建API服务

首先,我们需要创建负责执行聚合的服务并公开endpoint

我们有一个InjectionToken将代表每个端点。现在让我们看看我们如何填充END_POINTS令牌。

创建验证模块

每个模块需要创建两个额外的文件。

顾名思义,这个文件将负责AuthModule

我们仍然想通过杠杆打字稿声明合并来使用打字稿的力量。

在最基本的层面上,合并将两个声明的成员机械地连接成一个同名的接口。
现在,打字稿会将每个端点合并到EndPoints接口,以便我们可以自动完成。

接下来,我们为Auth相应模块中的Angular DI 提供端点,在我们的例子中是Auth模块。

你可以把这个multi选项想象成一个数组。每当我们添加一个新的提供者,Angular将提供者推入数组中。

所以,如果我们回到我们的API服务并记录_endpoints属性,我们将看到我们在数组中有一个项目 - AuthModule

END_POINTS提供商

太好了,现在我们只需要把我们的东西endpoints放到一个大对象上。

最后,我们来创建一个简单的方法来帮助我们解析url

现在,我们可以在我们需要的每个服务中使用API服务。为了简洁起见,我已经添加了一个Todos与我们描述的过程相同的模块。

例如:

总结

在这篇文章中,我们目睹了Angular DI的强大功能,以及我们如何利用这个multi选项。有了这个变化,我们就不太容易受到合并冲突的影响,模块可以随API一起移植,使我们可以在其他应用程序中使用它们。我们也避免违反单一责任,而且我们的代码组织得更好。

赞(0) 打赏
未经允许不得转载:前端学堂 » 通过Angular DI和multi 选项更好地去组织你的代码

讨论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

前端实战学习群 学以致用,进步更快

demo演示立即加入

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏