|
页面渲染思路和原理:
suplyMsgData数据从服务器请求得到(目前测试阶段写死),其中返回的某一列可能会有json字符串之类的内容,需要处理后才能使用bind-*之类的方法进行渲染。
imgsData是用来存放图片数据的,类似于微信朋友圈,使用内外两个list嵌套渲染页面,通过唯一的消息ID(suplyMsgID)进行过滤。
根据suplyMsgData的唯一行ID获取到渲染的当前行。
从suplyMsgData中取出渲染的当前行imgUrl,数据格式如: "../../test/imgs/head@3x.png","../../test/imgs/head@3x.png","../../test/imgs/head@3x.png","../../test/imgs/head@3x.png",
得到之后转成数组,然后遍历数组,将渲染的当前行ID和数组中每一个imgUrl存入 imgsData中,list组件感应到imgsData添加了数据,会自动渲染新的img到页面指定的容器(div)中。
绑定的li查看设计器中,第二个list的img元素,bind-attr-src object.val("imgUrl")。
原理说完了,如果还不够清楚,请自行查看 w页面结构,绑定方式,以及下面的getDate方法理解。
说下问题:
情景描述:
上面思路中最关键的一点就是把suplyMsgData中当前渲染的行的imgUrl中的值转成数组,再遍历此数组将数组中的每一个元素和当前渲染行的ID给存储到imgsData中,问题就处在这一步上面。
问题:
遍历数组时向imgsData中使用newData方法添加数据,此时进入死循环。 死循环可以查看for循环中的console语句在chrome控制台打印出来的内容判断。
并且可以看到 rowID有的会重复的打印出来,调试发现:
渲染suplyMsgData中第一行数据时正常;
在渲染第二行的时候,一开始的rowID为 20170520134531(suplyMsgData的第二行数据),然而当走到for循环时,循环的第二次,rowID又变成20170706162047。
!!!注意!!!: 此时当前for循环还没结束,并且此getDate方法的此次调用也没有按正常顺序执行结束(循环体内部,以及下面的return语句都没有执行),
然后函数又执行了一次getDate方法,调试指针又跳到了方法的第一行(debugger,已注释掉),并且rowID又变成20170706162047,诡异!!!!
其他的测试:
将imgsData.newData方法注释掉就一切正常。
猜测: imgsData.newData是异步的?
测试imgsData.newData是否异步:
1 在model组件的onload事件中,newData了300次,并且打印出当前循环的索引j的值。
2 在chrome控制台并查看:在循环结束之前并没有执行一次 console.log(11111111);
基本可以排除 上面的猜测。
调试中从函数的调用栈中发现执行的内部是有一个 refresh suplyMsgData的过程的,不知是否是此原因导致的。
这种偏框架底层的东西我了解还不够,暂时还没能力深入,所以来请大神解答一下。
这个问题其实挺有趣的,希望有兴趣的小伙伴可以把这份测试代码拿下来试一试。
忠告:
第一次打开此页面的时候请保持for循环中的imgsData.newData方法为注释状态,
否则即使写了debugger语句,在chrome控制台打开之前(或者chrome设置了断点跳过),
浏览器也会被卡死关不掉,只能用任务管理器强杀,这个也挺让人头疼的。
|
|