实际开发中经常会遇到此类需求：请求一个接口需要使用上一个接口获取到的数据。
比如说：
这个页面。进入app，首先要获取一些配置数据，获取完配置数据后，再获取左边分类栏数据，获取完分类数据后，取出分类的第一个，最后根据分类ID获取商品列表数据。
这几个接口的调用是依次进行的，并且基于上一个接口返回的数据。
如果直接在接口的回调里请求下一个接口，类似这样：
// 全部依次请求成功才算成功，有一个失败就是失败
- (void)loadDataSuccess:(void (^)(void))success failure:(void (^)(void))failure {
// 请求接口1
[Request loadData1Success:^{
// 请求接口2
[Request loadData2Success:^{
// 请求接口3
[Request loadData3Success:^{
!success ?: success();
} failure:^{
!failure ?: failure();
}];
} failure:^{
!failure ?: failure();
}];
} failure:^{
!failure ?: failure();
}];
}
如果只是两个接口还好，超过两个估计你自己都看不下去了。这种写法虽然简单粗暴加直观，但如果深层嵌套就有点惨不忍睹了，最重要的是影响可读性。
这种写法也号称最low的写法，基本上可以说是新手专属。其实先不论low不low，影响可读性就肯定是不能接受的。
那么如何改善这坨代码的可读性？
不用GCD
不同RAC
不用信号量
我只需简单运用局部block就可以很好的解决这个问题，还是那几个接口，现在我搭配局部block：
// 全部依次请求成功才算成功，有一个失败就是失败
- (void)loadDataSuccess:(void (^)(void))success failure:(void (^)(void))failure {
// 接口2请求成功
void (^loadData2Success)(void) = ^{
// 请求接口3
[Request loadData3Success:^{
// 所有接口请求成功
success();
} failure:^{
failure();
}];
};
// 接口1请求成功
void (^loadData1Success)(void) = ^{
// 请求接口2
[Request loadData2Success:^{
// 接口2请求成功
loadData2Success();
} failure:^{
failure();
}];
};
// 请求接口1
[Request loadData1Success:^{
// 接口1请求成功
loadData1Success();
} failure:^{
failure();
}];
}
将多层嵌套分解为多个局部block，依旧是简单直白的代码，但是却完美规避了深层嵌套的问题，逻辑也很清晰。
这个是我今天“灵光一闪”想到的，并非什么牛逼的技术，在这之前我一直用的信号量，网上已经有很多分享，我就不赘述了。
参考demo：