1回答

沁尘

2021-12-10

        可以实现，使用“全局状态管理”可以减少很多类似这种判断，不过这里需要考虑实现成本问题。

我们为什么要这个这个判断呢？多数情况下目的是为了交互体验或者“防穿帮”，在课程中，有些地方对于“是否登陆”我们是写了判断的，基本上都是基于这两点考虑。但有些是并没有判断的，比如说令牌过期了（同于没登陆），这个登陆态的维护我们是等到后续请求异常了，让全局异常处理去统一捕获，再引导用户去登陆。这里具体采用哪种方式要取决于这个业务逻辑或者产品设计上对于登陆状态敏不敏感。

        比如说像CMS这种，就是属于对登陆态敏感的，你不登陆或者令牌失效了，你就啥也做不了，所以一般CMS都是直接把登录态纳入全局状态管理，整个应用自动感知登录态来做出响应，不需要遍地if。

        像C端产品，比如APP、小程序之类的，这个情况就不一定了，不一定非要登陆才能使用，这种就需要根据我前面提到的，你要分析你应用里面是不是很多都依赖登录态以及对登录态很敏感来决定。不过要提醒一点是，“设置总的配置，哪些页面需要登录，哪些不需要登录？”这个并不能从根本上解决if判断问题，因为即便你当前的页面是不需要登陆就能访问的，但不代表你这个页面里面发起的操作也是如此，这个页面可能同时存在两种情况。所以一般这种设置是应用于网络层请求封装的时候，来决定要不要带一些参数或者请求特定接口（可以类比我们封装的Http.js，这里就属于网络层请求封装）。

        那么回到一开始的问题，如果你的应用里面，存在大量业务逻辑对用户是否登陆了很敏感，然后产品设计上也是如此的，那么使用全局状态管理肯定是比重复写if要好很多的，如果不是，那么其实用课程里的方式会是更性价比的选择。在课程设计之初，本来也是有一版采用了全局状态管理来做登陆态的维护，但是实现后发现其实有点没必要（在本课程的场景下），因为关于全局状态管理的解决方案设计和落地我们在即时通讯部分已经做了实践，如果在平时工作过程中碰到了类似的需求，是有能力去应用的（比如同学你提的这个问题场景）。      

0

1

慕仰305485

好的，谢谢～

2021-12-10

共1条回复