jQuery Ajax 回调越来越多时，我会先拆状态
· 阅读需 2 分钟
2013 年做前端页面时，很多交互都离不开 jQuery Ajax。搜索、保存、翻页、校验、局部刷新，看起来只是多写几个请求，可页面一旦复杂起来，真正先失控的往往不是接口本身，而是页面状态和回调关系。
我后来吃过几次亏后，慢慢形成一个习惯：如果 Ajax 回调开始一层套一层，我先不急着继续加逻辑，而是先把页面状态拆出来。
为什么回调多了之后页面最容易乱
因为一个请求的成功和失败，不只是拿到一份数据那么简单。
它通常还会影响：
- 按钮是否禁用
- loading 是否显示
- 表单错误信息要不要清空
- 列表是否需要重绘
如果这些状态全都散在不同回调里，后面只要再插入一个新请求，页面行为就容易开始互相打架。
我现在更愿意先写清楚的状态
哪怕不搞什么复杂框架，我也会先明确下面几类状态：
- 当前是不是在请求中
- 这次请求属于加载、提交还是刷新
- 成功后页面应该变成什么样
- 失败后哪些元素要恢复
当这些东西先被命名出来，回调函数就不至于什么都包办。
不是先拆函数，而是先拆语义
很多人一看回调多了，就开始机械地把函数拆成好几个。
这当然有帮助，但如果没有先分清状态语义，只是把一大坨逻辑切成几小坨，页面依然会乱。
我更在意的是：这个回调到底在处理“数据返回”，还是在处理“界面恢复”，还是在处理“下一步动作触发”。
小结
jQuery Ajax 年代最典型的问题，不是不会发请求，而是页面越来越像一团靠事件勉强粘住的状态集合。
我后来每次一看到回调开始往多层走，就先把状态拆开。只要状态语义站稳，哪怕还是用 jQuery，页面也会清爽很多。