摘要:写在前面之前写了一篇为移动端而生的自定义多级联动选择器,得到了很多人的关注。预知后话地址为移动端而生的自定义多级联动选择器到此,时间选择器的核心算法就已经基本掌握了。
写在前面
之前写了一篇 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,一个卖萌出家的算法妹纸。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/54382.html
摘要:写在前面之前写了一篇为移动端而生的自定义多级联动选择器,得到了很多人的关注。预知后话地址为移动端而生的自定义多级联动选择器到此,时间选择器的核心算法就已经基本掌握了。 写在前面 之前写了一篇 MultiPicker -『为移动端而生』的自定义多级联动选择器,得到了很多人的关注。鉴于很多人对这种手写插件的过程很好奇,所以写了几篇文章,来说说它的成长史~ 在阅读本文之前,确保你有稍微看过 ...
摘要:写在前面之前写了一篇为移动端而生的自定义多级联动选择器,得到了很多人的关注。预知后话地址为移动端而生的自定义多级联动选择器到此,时间选择器的核心算法就已经基本掌握了。 写在前面 之前写了一篇 MultiPicker -『为移动端而生』的自定义多级联动选择器,得到了很多人的关注。鉴于很多人对这种手写插件的过程很好奇,所以写了几篇文章,来说说它的成长史~ 在阅读本文之前,确保你有稍微看过 ...
摘要:写在前面之前写了一篇为移动端而生的自定义多级联动选择器,得到了很多人的关注。具体实现步骤如下先传入一个需要计算深度的对象给,判断如果还有则迭代,并计算深度。如果增加了联动级数需要来判断,则为新增加的联动绑定新的事件。 写在前面 之前写了一篇 MultiPicker -『为移动端而生』的自定义多级联动选择器,得到了很多人的关注。鉴于很多人对这种手写插件的过程很好奇,所以写了几篇文章,来说...
摘要:写在前面之前写了一篇为移动端而生的自定义多级联动选择器,得到了很多人的关注。具体实现步骤如下先传入一个需要计算深度的对象给,判断如果还有则迭代,并计算深度。如果增加了联动级数需要来判断,则为新增加的联动绑定新的事件。 写在前面 之前写了一篇 MultiPicker -『为移动端而生』的自定义多级联动选择器,得到了很多人的关注。鉴于很多人对这种手写插件的过程很好奇,所以写了几篇文章,来说...
摘要:写在前面之前写了一篇为移动端而生的自定义多级联动选择器,得到了很多人的关注。具体实现步骤如下先传入一个需要计算深度的对象给,判断如果还有则迭代,并计算深度。如果增加了联动级数需要来判断,则为新增加的联动绑定新的事件。 写在前面 之前写了一篇 MultiPicker -『为移动端而生』的自定义多级联动选择器,得到了很多人的关注。鉴于很多人对这种手写插件的过程很好奇,所以写了几篇文章,来说...
阅读 2885·2021-09-26 10:18
阅读 5192·2021-09-22 15:02
阅读 2748·2019-08-30 15:53
阅读 1825·2019-08-29 18:41
阅读 2674·2019-08-27 10:58
阅读 2608·2019-08-26 13:49
阅读 2728·2019-08-26 12:17
阅读 887·2019-08-26 11:49