如何造一个移动端的联动选择器（三）

写在前面

之前写了一篇 MultiPicker -『为移动端而生』的自定义多级联动选择器，得到了很多人的关注。鉴于很多人对这种手写插件的过程很好奇，所以写了几篇文章，来说说它的成长史~

在阅读本文之前，确保你有稍微看过 MultiPicker 的源码 喔~

点击查看源码 ，也可以在 npm 上找到他们：

• 日期选择器 - DateSelector - NPM.

• 自定义json选择器 - MultiPicker. NPM.

回顾上上集：如何造一个移动端的联动选择器（一）
回顾上集：如何造一个移动端的联动选择器（二）

四、日期选择器 和 自定义 JSON 选择器 的联动差别

思考第5个问题：『如果说滑动手势是它们之间的共同点，那它们之间又有什么区别？』

一个最明显的区别就是，日期选择器可以在多级之间反复调整，而自定义JSON 选择器只能从高级联动往下调整。

比如，在用日期选择器选择生日的时候。不小心操作失误了，选择成了1994-1-16

我想要修改年份为1995。当我滑动第一级联动时，后面的联动是不会改变的。

---

但是当我选择城市的时候，如果我选择了北京，下面的联动等级一定会全部配合 “北京” 这个高级联动，向下自适应改变。

选择了广东，下面的联动等级也一定会全部配合 “广东” 这个高级联动，向下自适应改变。

所以为了区别这两个不一样的联动场景，出现了两套不一样的联动算法。

五、日期选择器 的联动算法

思考第6个问题：『如何协调用户设置的时间点和实际时间点之间的联系？』

前面说到，用户如果设置了【月日时分】这四个时间单位的话，他可能会输入beginTime：[3,27,12,12]， endTime 和 recentTime 也是类似。但是计算机如何快速识别这个开始时间，其实就是[2016, 3, 27, 12, 12] 呢？

如果把用户设置的时间点称为【虚拟时间】，而计算机能够处理的完整时间点称为【实际时间】，这个问题就简化了许多。

我做了一个小技巧，就是在我判断用户参数合法性的同时，把用户作为参数传入的【虚拟时间】( 如 ：beginTime、endTime、 recentTime），转变成一个代码能够快速识别的【真实时间】（如：begin_time、end_time、 recent_time）。

另外，idxArr、maxHeight、distance 对应下标的值是和【虚拟时间】对应下标的值保持一致。

思考第7个问题：『如何计算联动数据，才能做到在多级之间反复调整？』

在我最新的重构算法中，我的解决方案是:

当ul被滑动时，就从最高级的联动开始【递归调用】。被递归的函数叫做checkRange。

实现步骤如下：

① 每次touchend的时候，会先将当前滑动的结果保存，再调用checkRange(0);

② checkRange会根据你的参数，直接设置下一级联动应该有的数据范围：

③ 判断好下一级的数据范围后，需要判断是否滑动到了开始时间(即最顶)，或结束时间(即最底)：

这里的loop是自己封装的 for 循环，一定要理解这里的dir到底是如何计算的。

④ 判断好dir的值之后，就需要对前面第②步生成的数据范围进行调整：

如果滑到了开始时间的分界点，需要处理min的值；

如果滑到了结束时间的分界点，需要处理max的值；

处理好后，再调用 initRangeArr 更新dom。

⑤ 在initRangeArr中更新dom之后，需要配合数据，调整好 ul 的translate3d。通过一系列的计算，得到targetLong的值，用来设置translate3d。并且同步好所有控制结果的数据，不仅仅是更新recent_time、resultArr，还需要更新 maxHeight和 distance。

⑥ 然后递归调用checkRange；

PS：注意区分【虚拟时间】和【真实时间】的下标含义哦。

【虚拟时间】的下标是指，在界面上的每个ul的下标，比如有三个ul，那么就是 [0, 1, 2];

【真实时间】的下标是指，【0：年】【1：月】【2：日】.... 以此类推。

预知后话

Github地址:『为移动端而生』的自定义多级联动选择器

到此，时间选择器的核心算法就已经基本掌握了。

预知后话，后两天见分晓

我是嘉宝Appian，一个卖萌出家的算法妹纸。