CRUD项目毫无亮点？
- 那么你注意过后台API的调用吗？
- 你有仔细思考过他们的逻辑特点吗?
- 你是否有注意到，网络或后台接口缓慢时的查询数据的错乱问题?
- 你的字典接口调用有缓存吗？
- 对于迅速的连续点击，你有做防止重复提交的处理吗？
你不懂装饰设计模式?
没事，不需要懂，只要会这种写法即可
前端调用后端接口需要注意什么?
或者说前端调用后端接口通用逻辑是什么?
字典数据获取请求
字典数据的特点是什么？
- 数据基本不会改变，因此缓存很有必要
- 虽然他基本不会变，但你不能让一个缓存从头用到尾，应该让缓存有个有效期
那么基于数据字典的特点，调用数据字典接口的逻辑大概是这样的
flowchart TB
开始((开始)) --> 发起请求
发起请求 --> 构建请求唯一标识
构建请求唯一标识 --> 是否有缓存{根据请求唯一标识<br/>判断是否有缓存?}
是否有缓存 --> |是| 返回缓存结果
返回缓存结果 --> 结束(((结束)))
是否有缓存 --> |否| 是否有进行中请求(根据请求唯一标识<br/>判断是否有进行中请求?)
是否有进行中请求 --> |是| 返回进行中请求
返回进行中请求 --> 结束
是否有进行中请求 --> |否| 发起新请求
发起新请求 --> 结束
数据查询请求
以列表查询为例，列表查询的数据和他的后台接口的特点是什么？
- 每点一次查询按钮，都期望获取最新数据，也就是说无需缓存
- 对于复杂查询，后端接口的响应可能需要一点时间，如果时间过长，用户可能同一条件多次点击，也就是说你需要在多次点击之间共享pending状态的promise, 减少重复的网络请求
- 如果后端接口响应比较慢，用户有时会改了一个新条件去查询，那就必须避免，前一个请求的数据，把后一个请求的数据覆盖的问题，也就是说需要支持请求取消
- 如果你是一个类似tab样式的多状态数据搜索，tab切换时，同样要避免前一个tab请求的数据，覆盖后一个tab数据的问题，也就是说需要支持请求取消
flowchart TB
开始((开始)) --> 发起请求
发起请求 --> 构建请求唯一标识
构建请求唯一标识 --> 是否有进行中请求{是否有进行中请求?}
是否有进行中请求 --> |否| 发起新请求
是否有进行中请求 --> |是| 进行中请求与当前是同一请求{进行中请求<br/>的唯一标识<br/>是否与当前请求<br/>的唯一标识一致?}
进行中请求与当前是同一请求 --> |是| 返回进行中请求
返回进行中请求 --> 结束
进行中请求与当前是同一请求 --> |否| 取消进行中请求
取消进行中请求 --> 发起新请求
发起新请求 --> 结束
增/改/删请求
这类接口的特点是：
- 到项目中后期，数据量起来了之后，如果后端那边验证一多，或者涉及到第三方接口调用，那通常响应就比较慢，那响应一慢，就可能导致，用户认为没点到按钮，从而进行连续多次点击，多次点击就有可能造成前端显示了错误提示，但后端又正常插入了数据。
flowchart TB
开始((开始)) --> 发起请求
发起请求 --> 构建请求唯一标识
构建请求唯一标识 --> 是否有进行中请求{根据请求唯一标识<br/>判断是否有进行中请求?}
是否有进行中请求 --> |是| 返回进行中请求
返回进行中请求 --> 结束(((结束)))
是否有进行中请求 --> |否| 发起新请求
发起新请求 --> 结束(((结束)))
针对上面的问题，你的解决方案是？
A同学： 拜托，我们都要加loading效果的，加了loading把界面用透明遮罩挡住了，或者在按钮加了loading，同时禁用了。
B同学： 你指防抖节流那一套吗？这很容易嘛，我们项目里面，封装了axios, axios封装的代码把这些都处理完了。
C同学： 额，我暂时没考虑过。。。
A,B,C同学： 你的解决方案是骡子还是马，拉出来秀秀！
组合打法：装饰设计模式+promise+vue-request
来，这次试试模仿学者来说几句话：
- 要解决上面的问题，总体的解决方案是：用装饰设计模式对原本的接口调用方法，进行无侵入功能增强，代码解耦，保持高内聚，低耦合
- 要实现两个装饰器，一个装饰器实现pending状态的promise共享，另一个装饰器实现promise的取消
- 实现时的细节注意点是：要用闭包，实现资源共享，同时也是避免变量名污染。
后面的没心情写了，下次，下次一定。。。有需要的同学可在评论区留言/评论/探讨