r******9
发帖数: 566 | 1 是这样，由于公司后端太傻比，前端需要循环一个数组，数组中每个对象拿出来call一
次api。大家都知道for循环当中执行异步就是个灾难，但是es6有generator好像能解决
这个问题。然而由于我要一个一个去send，如果我外围包一个for循环去执行.next(),
他最后make api的顺序是完全错误的。哎。不知道哪位大神遇到过这种情况。 |
t**********n
发帖数: 1718 | |
A*******5
发帖数: 690 | 3 你的前端是纯javascript，还是有其他framework， 有自己同步异步http transaction
的module？ |
l****u
发帖数: 1764 | 4 递归啊， onSuccess里面发起下一个call，刷了那么多dp题了怎么还老是想到for呢 |
r******9
发帖数: 566 | 5
只有递归了 但是我们很多chained api call 几个api之间的调用很复杂 这将是一个灾
难………
【在 l****u 的大作中提到】
: 递归啊， onSuccess里面发起下一个call，刷了那么多dp题了怎么还老是想到for呢
|
r******9
发帖数: 566 | 6
transaction
纯客户端 后端的人太傻逼 本来直接我传一个数组给他就完了 结果他们有各种限制
【在 A*******5 的大作中提到】
: 你的前端是纯javascript，还是有其他framework， 有自己同步异步http transaction
: 的module？
|
l****u
发帖数: 1764 | 7 http call不应该都是stateless的么，如果几个call直接有dependency本来就是设计
api的时候有问题了
【在 r******9 的大作中提到】
:
: transaction
: 纯客户端 后端的人太傻逼 本来直接我传一个数组给他就完了 结果他们有各种限制
|
A*******5
发帖数: 690 | 8
我大概明白了，递归是callback里call自己下一个吧。你那后端的api复不复杂？
这个还是应该后端改啊，他现在的API肯定有verification and implement的modules，
为什么不拆开呢？
前端这样很危险，以后有了http transition同步异步的bug，连debugger都不好用了。
因为一旦有timeout在里面就不行了，我以前就被assign过这么个bug，有200多个
action batch，一个batch10-40个action，想想多少http transaction。。。bug的描
述是，多层表，有时子表打开下面没内容，只是有时, 要求我在不连客户数据库的情况
下判断在新的version里能不能reproduce。根本不能直接debug，最后是用反证法，搞
了一个星期才确定，不能复制！其实QA 复制个数据库就半个小时左右，然后连上新版
本直接测就可以，可人家不想。
【在 l****u 的大作中提到】
: http call不应该都是stateless的么，如果几个call直接有dependency本来就是设计
: api的时候有问题了
|
P*******o
发帖数: 3165 | 9 用promise不就完了
[在 ry880809 (ry880809) 的大作中提到：]
:是这样，由于公司后端太傻比，前端需要循环一个数组，数组中每个对象拿出来call
一次api。大家都知道for循环当中执行异步就是个灾难，但是es6有generator好像能解
决这个问题。然而由于我要一个一个去send，如果我外围包一个for循环去执行.next()
, 他最后make api的顺序是完全错误的。哎。不知道哪位大神遇到过这种情况。 |
l****u
发帖数: 1764 | 10 恩 就是callback里面重复call自己，传入不同的参数，然后再promise里面判断是不是
该停止递归返回结果了
后端api挺简单的，之所以这么弄是api 在服务器太慢了，一次性发过去run太久，得等
好几分钟，nginx超时了。。。所以采用这种work around分解成多个http call，每个
call的时间就在超时范围内了。。
【在 A*******5 的大作中提到】
:
: 我大概明白了，递归是callback里call自己下一个吧。你那后端的api复不复杂？
: 这个还是应该后端改啊，他现在的API肯定有verification and implement的modules，
: 为什么不拆开呢？
: 前端这样很危险，以后有了http transition同步异步的bug，连debugger都不好用了。
: 因为一旦有timeout在里面就不行了，我以前就被assign过这么个bug，有200多个
: action batch，一个batch10-40个action，想想多少http transaction。。。bug的描
: 述是，多层表，有时子表打开下面没内容，只是有时, 要求我在不连客户数据库的情况
: 下判断在新的version里能不能reproduce。根本不能直接debug，最后是用反证法，搞
: 了一个星期才确定，不能复制！其实QA 复制个数据库就半个小时左右，然后连上新版
|
|
|
r******9
发帖数: 566 | 11
就是后端太傻比的原因了。
【在 l****u 的大作中提到】
: http call不应该都是stateless的么，如果几个call直接有dependency本来就是设计
: api的时候有问题了
|
h***n
发帖数: 1600 | 12 挺stupid的做法
【在 l****u 的大作中提到】
: 恩 就是callback里面重复call自己，传入不同的参数，然后再promise里面判断是不是
: 该停止递归返回结果了
: 后端api挺简单的，之所以这么弄是api 在服务器太慢了，一次性发过去run太久，得等
: 好几分钟，nginx超时了。。。所以采用这种work around分解成多个http call，每个
: call的时间就在超时范围内了。。
|
r******9
发帖数: 566 | 13
其实递归不行。我们会有很多很多数据 没人能保证递归会不会爆炸。。。。现在采取
的办法是：
function sendApi(obj){api((obj)=>{sucess:{
这里还有其他两个有dependency的api call。。。
handlesucess()
}
handleError:(){
这里也有两三个apicall。。。。
}
})}
function handleSuccess(){sendNextApi()}
function sendNextApi(){sendApi(array[index+1])}
彻底无语。。。。
【在 l****u 的大作中提到】
: 递归啊， onSuccess里面发起下一个call，刷了那么多dp题了怎么还老是想到for呢
|
l****u
发帖数: 1764 | 14 这不就是递归啊，不过多套了几个别的函数
不过为啥handleError里面还有几个api call，出错了还不直接炸掉，还继续call个啥呢
【在 r******9 的大作中提到】
:
: 其实递归不行。我们会有很多很多数据 没人能保证递归会不会爆炸。。。。现在采取
: 的办法是：
: function sendApi(obj){api((obj)=>{sucess:{
: 这里还有其他两个有dependency的api call。。。
: handlesucess()
: }
: handleError:(){
: 这里也有两三个apicall。。。。
: }
|
a****i
发帖数: 1182 | 15 onsuccess递归的话不是顺序同步call了吗？
我觉得建个 id -> result的map，然后还是异步call
success了放进map里
【在 r******9 的大作中提到】
:
: 其实递归不行。我们会有很多很多数据 没人能保证递归会不会爆炸。。。。现在采取
: 的办法是：
: function sendApi(obj){api((obj)=>{sucess:{
: 这里还有其他两个有dependency的api call。。。
: handlesucess()
: }
: handleError:(){
: 这里也有两三个apicall。。。。
: }
|
A*******5
发帖数: 690 | 16 你们后端真的不能沟通， 还是后端没有办法改？连我们公司遇到这种情况也不会冒这
种险。是不是deadline快到了，没时间先弄个凑活着。 |
r******9
发帖数: 566 | 17
啥呢
因为要出错了也要继续call下一个 生成employee的api。。。
【在 l****u 的大作中提到】
: 这不就是递归啊，不过多套了几个别的函数
: 不过为啥handleError里面还有几个api call，出错了还不直接炸掉，还继续call个啥呢
|
r******9
发帖数: 566 | 18
是的吧。等上一个回来我再call下一个。顺序上应该对的。但是我们没直接递归
【在 a****i 的大作中提到】
: onsuccess递归的话不是顺序同步call了吗？
: 我觉得建个 id -> result的map，然后还是异步call
: success了放进map里
|
r******9
发帖数: 566 | 19
这不是冒险 在咱这是常态。前端干起后端的活。
【在 A*******5 的大作中提到】
: 你们后端真的不能沟通， 还是后端没有办法改？连我们公司遇到这种情况也不会冒这
: 种险。是不是deadline快到了，没时间先弄个凑活着。
|
