感觉反弹该歇一下了. - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Stock

感觉反弹该歇一下了.

感觉反弹该歇一下了.# Stock

r*92011-03-15 07:03

1 楼

是这样，由于公司后端太傻比，前端需要循环一个数组，数组中每个对象拿出来call一
次api。大家都知道for循环当中执行异步就是个灾难，但是es6有generator好像能解决
这个问题。然而由于我要一个一个去send，如果我外围包一个for循环去执行.next(),
他最后make api的顺序是完全错误的。哎。不知道哪位大神遇到过这种情况。

w*s2011-03-15 07:03

2 楼

谨慎的扔了一瓶酱油出来看看.

t*n2011-03-15 07:03

3 楼

LC第692题

b*e2011-03-15 07:03

4 楼

hehe 油价下来，fed日子好过点. hiahia

【在 w******s 的大作中提到】

: 谨慎的扔了一瓶酱油出来看看.

A*52011-03-15 07:03

5 楼

你的前端是纯javascript，还是有其他framework，有自己同步异步http transaction
的module？

m*e2011-03-15 07:03

6 楼

like tsunami,
if you runs quickly
you live
otherwise, you die

l*u2011-03-15 07:03

7 楼

递归啊， onSuccess里面发起下一个call，刷了那么多dp题了怎么还老是想到for呢

r*92011-03-15 07:03

8 楼

只有递归了但是我们很多chained api call 几个api之间的调用很复杂这将是一个灾
难………

【在 l****u 的大作中提到】

: 递归啊， onSuccess里面发起下一个call，刷了那么多dp题了怎么还老是想到for呢

r*92011-03-15 07:03

9 楼

transaction
纯客户端后端的人太傻逼本来直接我传一个数组给他就完了结果他们有各种限制

【在 A*******5 的大作中提到】

: 你的前端是纯javascript，还是有其他framework，有自己同步异步http transaction
: 的module？

l*u2011-03-15 07:03

10 楼

http call不应该都是stateless的么，如果几个call直接有dependency本来就是设计
api的时候有问题了

【在 r******9 的大作中提到】

:
: transaction
: 纯客户端后端的人太傻逼本来直接我传一个数组给他就完了结果他们有各种限制

A*52011-03-15 07:03

11 楼

我大概明白了，递归是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*o2011-03-15 07:03

12 楼

用promise不就完了
[在 ry880809 (ry880809) 的大作中提到：]
:是这样，由于公司后端太傻比，前端需要循环一个数组，数组中每个对象拿出来call
一次api。大家都知道for循环当中执行异步就是个灾难，但是es6有generator好像能解
决这个问题。然而由于我要一个一个去send，如果我外围包一个for循环去执行.next()
, 他最后make api的顺序是完全错误的。哎。不知道哪位大神遇到过这种情况。

l*u2011-03-15 07:03

13 楼

恩就是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*92011-03-15 07:03

14 楼

就是后端太傻比的原因了。

【在 l****u 的大作中提到】

: http call不应该都是stateless的么，如果几个call直接有dependency本来就是设计
: api的时候有问题了

h*n2011-03-15 07:03

15 楼

挺stupid的做法

【在 l****u 的大作中提到】

: 恩就是callback里面重复call自己，传入不同的参数，然后再promise里面判断是不是
: 该停止递归返回结果了
: 后端api挺简单的，之所以这么弄是api 在服务器太慢了，一次性发过去run太久，得等
: 好几分钟，nginx超时了。。。所以采用这种work around分解成多个http call，每个
: call的时间就在超时范围内了。。

r*92011-03-15 07:03

16 楼

其实递归不行。我们会有很多很多数据没人能保证递归会不会爆炸。。。。现在采取
的办法是：
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*u2011-03-15 07:03

17 楼

这不就是递归啊，不过多套了几个别的函数
不过为啥handleError里面还有几个api call，出错了还不直接炸掉，还继续call个啥呢

【在 r******9 的大作中提到】

:
: 其实递归不行。我们会有很多很多数据没人能保证递归会不会爆炸。。。。现在采取
: 的办法是：
: function sendApi(obj){api((obj)=>{sucess:{
: 这里还有其他两个有dependency的api call。。。
: handlesucess()
: }
: handleError:(){
: 这里也有两三个apicall。。。。
: }