rchunping

Same bug in Gogland 1.0 EAP, Windows 10 There's no Deployment tool in Goglang, and I find this plugin , but faild.

append: Sync file .gitignore will experiencing this issue. and other file *.go , no problem.

@F-loat 这个到不是关键 滑动的时候只有十几条数据在data上，问题是这十几条数据不会随着 v-if的变化而清掉，依然留在data.$root上 另一个问题是，v-for这种内部处理是不是有什么特别的地方，即使我的数据简单到一个数字数组，然后放在v-for里面展示， 当我追加20个数字到data的时候，ui刷新依然有明显延迟（安卓）。

@anchengjian 嗯，也看过这个指南。 产品就是不停刷不停翻的信息流，现在是在各种测试从wepy迁移过来的问题 我试试看能不能v-for里面引入小程序自己的自定义组件来减少data上循环组件数据

@fangdiao 什么问题？UI更新慢还是数据太多卡？

@fangdiao 我们这边测试下来，ui延迟在iOS上完全没问题，安卓上暂时无解（不过真机上效果也能接受） 大列表导致ui卡顿的问题，我们的解决方案是： 1. 如果列表的展示卡片UI比较简单，那么不要用组件。同时控制data数据量，只传必要的一部分数据。 比如不管列表多长，始终传入够展示5屏的数据量（当前屏和上下各2屏，根据实际效果调整），其他列表项用0填充。 比如 this.list = [0,0,0,0,0,.......,{数据n},{数据n+1},{数据n+2},.....,0,0,0,0] 模板v-for中用v-if 进行开关：碰到0就显示一个空白的<view>占位，非0就展示实际的卡片内容 （不要用v-show，否则会提前碰到DOM节点超出数量限制的错误） 然后根据scroll-view的滚屏事件动态计算列表中哪些位置需要填充真实的数据，更新this.list进行UI渲染。 卡片定高的这样做就行了，如果卡片不定高而且最终高度无法通过数据进行精确计算的话，还需要动态检测每个卡片的实际高度，并把数组中的0用实际的高度代替。这个做起来复杂一点，比如未知高度的卡片第一次始终需要先设置进数据展示一次才能拿到高度之类的..... 2. 如果列表卡片UI很复杂，那么也不要用Vue的组件，因为v-for内的Vue的组件会导致数据倍增（this.list上一份，然后每个卡片组件又一份，组件用过的data并不会随着v-if的开关而减少） 我们的经验是把卡片做成原生的小程序自定义组件，同时 this.list 也要按照上面的方法只传入必要那几个当前需要展示的卡片数据，其他用0代替 我们项目中上面2中情况都有使用，实际测试下来，刷几千条都不会有卡顿问题。 当然实际上很多地方都需要微调优化，scroll检测频率，this.list更新频率都会影响实际效果。

@fangdiao 不用vuex维护大列表，单独或者几个页面共享一个大的Object维护获取到的数据。减少data上的传值。你用vuex引入计算属性的话最终还是在data上

@fangdiao 你要几个页面共用或者需要跨组件操作就放单独js里导出来用

同样的问题，因为v-mode是通过bindinput事件实现的

@youngluo 按照bindinput的说明，事件处理函数中如果返回了字符串，那么会替换input中的内容，我猜问题出在这里？