我目前正在学习Angular 2,我正在研究警卫。我了解它们是如何工作的,但我不明白为什么它们比仅仅禁用您不希望用户使用的导航控件更为可取?
在我看来,你可以在拥有这些控件的组件中做到这一点。如果您有一个单独的类来实现 CanActivate
和 CanDeactivate
接口来驱动该逻辑,您会得到什么?保护组件似乎为坚果增加了很多复杂性。
有人可以解释我错过的内容吗?
答案 0 :(得分:7)
答案很简单:没有看到链接并不意味着你不能去那里。
如果您在受保护的页面上,并为其添加了书签,该怎么办?然后在几天你没有访问它,你试图去那里?你不会看到任何按钮,但你有网址。
所以没有守卫,你就可以在那里航行。
此外应该在服务器端进行额外检查,用户获取数据取决于他们的角色,但这是其他故事
答案 1 :(得分:1)
除了@Volodymyr提出的观点之外,我发现使用这些警卫(特别是CanActivate
)可以在应用程序开始增长时保持组件代码更清晰。
定义像AuthGuard in the Angular docs这样的守卫将该逻辑保存在一个地方,并且您可以在添加更多路线时应用它们。任何新组件都不需要关心它们是否可以路由到,或者如何确定它们。
我们发现它们对于认证和安全等交叉问题非常有用。授权,在守卫中定义逻辑并将其保留在工作组件之外只显示一些数据。
另一个不错的副作用是,在我们的5位开发人员的团队中,如果我想调整防护逻辑的实现方式,我不会与那些使用这些组件的人发生冲突。
另外,使用Resolve guard来预取数据也有类似的好处。