Remove zscroller
warmhug opened this issue · comments
zscroller 已经成为影响“体积”和“复杂度”的最后一个大因素，被 Picker / ListView / Calendar 三个组件用到，分别都导致了一定的代码冗余、理解复杂度等问题。
以 Picker 为例、对比社区其他 UI 库做法：
原生实现的 framework7 picker https://github.com/framework7io/Framework7/blob/9f3589b2a2dc9d2119d41887a31309c8e811ec27/src/js/framework7/picker.js
基于 angular 的 ionic picker https://github.com/ionic-team/ionic/blob/1573043f4e31cabe1bed6bb0f4b171a8575d360d/src/components/picker/picker-column.ts
基于 zepto 的 weui picker https://github.com/Tencent/weui.js/blob/81deb5c1c3da3e7d4d5d124d4c5da100171b8408/src/picker/picker.js
基于 react 的 weui picker https://github.com/weui/react-weui/blob/f8b12cd6f383b3e07c64442623839376384e33d0/src/components/picker/picker.js
基于 vue 的 饿了么 picker https://github.com/ElemeFE/mint-ui/blob/28abcb96cd6f85fae0863b36ef8a24cacf7f721e/packages/picker/src/picker.vue
这三个压缩后体积都在 10k 左右，并且源码比较清晰无复杂依赖，没有多余代码。
发现一个和我们一样使用 zscroller 的 picker https://github.com/airyland/vux/blob/e3f46841a544984d1d93a8e3bcf86a03b7f38f3b/src/components/picker/scroller.js 也精简了不少代码。
我们目前的问题主要出在 zscroller 上、导致体积是他们的 2 倍多大小，zscroller 的 zoom / enableScrollX / paging / PullToRefresh 这些 增加代码行数、又增加复杂度，对组件来说也是多余代码。
@silentcloud m-dialog 分支 为什么不合并到 master ？
@zhang740 负责改这个问题，我来做 ListView 的改造。
@warmhug master 小程序在用，这次改动很大，就临时起了个分支，这会可以提个 PR 了