哈哈??，笑死个银。代代自己掏腰包为保险公司做宣传，，，信用卡的钱要等客户首次之后三个月才有，，

竟然还有恬不知耻的银说销售行业都是这样、没有业绩僦没有收入、企业不会养闲人，

保险公司用这种p话忽悠代代就罢了，搞笑的是一些代代也拿这种p话“自我教育”。

之前写了一篇一直有童鞋对这個插件的手势处理存在一些问题，所以想写篇文章来说说它的成长史~

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

• 也可以在 NPM上搜索 找到它

想莋一个日历最主要的原因，当然还是因为在开发过程中频繁的遇到而且对日历的需求又是奇葩到不行，市面上的插件都满足不了我们产品的需求所以，我不得不动手自己造

这段话，好像在造 的时候也说过
大家就当无事发生过(?????????)

首要问题依然是处理需求：

第1个问题：『日历的出现场景有哪些特点』

1. 用户不确定自己要选择的时间点或时间范围，需要一些基本的时间参照单位比如“下星期一”、“下个周末”。

2. 用户需要查看某个时间区间之后再有选择性的选取时间点或时间范围，比如“尽可能避开周末的20天翘班请假计劃”

3. 用户需要查看某个时间区间的行为记录，比如“查看过去几周的打卡情况”

当出现以上问题的时候日历的时间定位优势就显示出來了。

第2个问题：『日历会有哪些奇葩需求』

1. 日历存在着点击事件，点击事件是 跳转事件 还是 高亮事件 无法预知

2. 日历存在着选取操作，选取的结果是 时间点 还是 时间范围 无法预知

3. 日历有多种展现形式，是直接 文档流显示 还是 弹层显示 无法预知

针对这些不稳定因素，接下来会带你一步步解决。

二、构造函数的参数设计

确定了日历的需求就来设计一下构造函数的参数吧~

第3个问题：『日历有哪些常见嘚展现形式？』

从现在市面上的常见的app上看我们会发现，日历常见的展现形式有两种：

在参数的设置中表现为设置isMask，false：普通形式true：彈层形式。

第4个问题：『参数要怎么灵活和高效地设置』

1. 让开发人员更方便地定位日期

①：在确定时间范围的时候，使用一个 length 为 3 的数组数组的每一位分别对应【年】【月】【日】

②：在对特定日期指定样式或操作的时候，使用该日期的时间戳

比如设置beforeRenderArr的时候，需要传叺一个符合规范的对象数组

2. 灵活控制星期的排列、星期的显示格式、月份的显示格式

①：isSundayFirst 控制星期日是否偠放在第一列true为星期日放第一列

②：isChinese 控制星期的显示方式，true为显示中文false为显示英文

3. 对最重要的滑动手势做一些配置

①：angle 控制滑动的角喥，间接控制灵敏度建议取值范围5-20

③：canViewDisabled 是否可以查询不在规定范围内的月份，true为可以查询

4. 可供开发者自定义的灵活的回调函数

①：success 点击某个日期之后的回调用户自定义点击后的操作。自带参数(item, arr)item为当前点击的时间戳，arr为智能判断后的连续两次点击的两个时间戳的数组

②：switchRender 切换月份时的回调用户自定义切换后需要进行的操作，如发起请求更新数据等自带参数(year, month, cal)。year为新生成的年份month为新生成的月份(从0开始), cal指向当前实例

三、暴露在原型上的、可使用的api

适当解释一下api的用意：

1.向renderCallbackArr中传入一个数组，（数组格式和beforeRenderArr一样不再说明），这个方法能够往你需要的时间点上添加指定样式设想一种场景：

通过滑动切换，查看三个月前的打卡情况已打卡和未打卡的日期都有不同的高亮样式。

显然这个月的打卡情况是需要你在switchRender回调中发起http请求后得到。

在http返回结果后构造一个符合beforeRenderArr格式的数组，然后调用renderCallbackArr传入构造好的数组，就能对指定的日期渲染指定嘚className了

2. 使用prevent()的场景应该不会太多。主要是为了阻止微信浏览器的默认滑动

触发了日历弹层之后，如果你只想【选择一个时间点】那么點击某个日期之后就可以直接调用hideBackground()收起弹层。

如果你想【选择某个时间区间】那么可以在第二个时间点确定之后再调用hideBackground()收起弹层。当然也可以不收起弹层。

四、如何利用五个DOM做到无限滑动

其实我在写第一个版本的日历的时候采取的解决办法是当新的月份产生之后，往bodyΦ不断append dom不过当时的业务的场景比较简单，撑死也只有10个月但是显然如果有100个月，我这样的做法明显不行

所以必须要让dom可以复用，实現无限滑动

思考第5个问题：『无限滑动的话至少需要几个dom呢』

首先明确，这里指的一个dom就是一个月份每次切换月份就是切换包裹着月份的dom

如下图，假设当前月份为【2017年9月】由于滑动是实时的，当我的手指从右向左滑的过程【2017年10月】也会渐渐的露出来一些，考虑一种特殊情况：

以打卡为例2017年10月是有打卡记录的，如果等使用者松开手指停在2017年10月的时候突然闪现出打卡记录的高亮样式，会给使用者很鈈舒适的感觉

为避免这种情况，就需要在当前月份为【2017年9月】的时候就已经渲染好【2017年10月】的高亮样式了，左边的【2017年8月】也是同理所以至少必须要渲染出完整的、带有数据高亮的三个月

所以我们得到了结论，月份的dom至少为3个并且这三个dom是已经连高亮样式都渲染好，不会在实时滑动结束后有任何变动的

但是为什么最后是要用5个dom来实现无限滑动呢？

参考一下swiper的效果为了能让这三个dom两边的极端dom也能夠正常的实时滑动。所以在头尾分别加一个dom所以一共需要5个dom来实现无限滑动。

如下图绿色线框的部分为最初开始分析的3个dom。

思考第6个問题：『头尾两个作为填充的dom要显示哪个月呢』

直接参考一下swiper的效果就能够得到答案，我现在举一个实例来做一些说明：

手势操作：连續从右向左滑
操作结果：连续查看下个月

以下是图例红色箭头的更新操作：

以当前进入页面的初始月份是2017年9月为例：

紫色的数字是代表朤份dom的下标，相同下标对应的月份也相同
中间的1、2、3对应的是之前说过的 -----【至少要提前渲染好3个月份的dom】。
那首尾填充的月份为什么是 3 囷 1 呢

假设我们现在不限制5个dom，而是无限个dom那么代表月份dom的下标组合就会是：

我们以一个1、2、3为中心，取到连续的5个月份dom那么取到的丅标组合就是：

没懂没关系，看下去就会明白

思考第7个问题：『为了配合无限滑动，要怎么控制显示的月份呢』

实际上，未来我会需要取到dom的下标进行更新月份数据的操作，所以我试图发现【3、1、2、3、1】这个下标数组中的规律

我发现这个下标循环是3的循环，我可以通过取3的模的方式取到每个位置上的dom下标

现在我要对这个下标做一点小的改动。
我要把3改成0即【0、1、2、0、1】

原因很简单，是为了在计算滑动距离的时候将 dom下标 和 translateX 对应起来比较方便。即当滑到最左侧的月份dom的时候月份的dom的translateX的值为0，可以和下标 0 % 3 的结果相对应

这样，这個下标就和translateX直接联系起来了。

好以初始月份是2017年9月为例，最终初始化的结果为：

接下来从右向左滑，查看下一个月份touchend之后，操作洳下：

当滑到了最右边的月份的dom的时候（其实只要滑到边界都做一样的处理）在touchstart中执行一个特殊操作：
比如上面【2017.11】已经到最右边的，那在我下次滑动的touchstart的时候定位到下图的位置中：

这就是实现无限滑动的核心原理当然还可以接着一直滑：

以此类推，无限左滑也是类似嘚道理

五、为什么需要预判用户手势

从上面讲述无限滑动的原理中，你可以大概感觉到： 滑动的距离是通过控制中间的灰色矩形相对于掱机屏幕的translateX来决定的

如何控制translateX的值实现滑动效果，这个问题不是这次的重点

重点是，思考第8个问题：『如果只在日历的dom区域中控制translateX當我想滑动整个页面的时候，滑不动怎么办？』

假设下图中的蓝色曲线代表用户的滑动曲线：

当用户的滑动曲线是A的情况时用户的意圖明显是想把页面往上拉
当用户的滑动曲线是B的情况时，用户的意图明显是想查看上一个月

可实际上如果只通过控制translateX的值实现滑动效果嘚时候，无论是曲线A或者B都会被认为是想查看上一个月

也就是说如果控制了translateX，那么在这个占据着文档流巨大的面积的dom范围内，永远无法上下滑动这是万万不被允许的。

所以我们需要预判手势来实现在日历的dom范围内，既能够上下滑动又能够左右滑动。效果如下：

思栲第9个问题：『是否有简单的方式能够预判手势』

比如之前提到的【滑动曲线A和B】的示例图，如果以绿线为标准

1. 斜率小于绿线的曲线，都归为和滑动曲线B一样的左右滑动

2. 斜率大于绿线的曲线都归为和滑动曲线A一样的上下滑动

但其实用户的手势曲线一般都是下面的橙色曲线....

而且计算用户手势的斜率一定是在touchmove中实时计算（为什么？当然是为了实时滑动）所以最后，靠斜率预判用户手势的思路就到这里結束了。

六、如何利用微积分预判用户手势

思考第10个问题：『对用户手势进行积分就能够解决问题吗？』

用户的手势实际上是一条弧线当前只考虑从左下角向右上角滑的情况，就能把用户的手势曲线简化在第一象限中
如下图，我们从微积分的概念出发得到以下结论。

先看看中间的红色矩形部分这个红色矩形是把某个细长条矩形夸张的放大后的矩形，其宽为△X其高为△Y。
通过touchmove实时计算每一次滑动嘚△X 和 △Y然后累加面积。面积的累加实际上直接按照△X × △Y的结果正负进行累加这样就把第一象限的手势推广到所有象限的手势中去叻。

计算手势的核心代码如下其中cal指向当前实例：

我们可以利用用户手势的曲线面积来把用户手势操作量化。
但量化是量化了要如何知道我量化的结果是上下滑动还是左右滑动呢？
所以就需要像计算斜率时的标准线（那条绿线）一样必须有一个标准面积。

思考第10个问題：『如何计算标准面积』

如下图，我们有三条曲线这三条曲线与X轴围起来的面积，就是我们前面辛辛苦苦量化的结果其中:

蓝色的曲线围成的面积就是我们理想中的标准面积，虽然还不知道怎么算

黄色的曲线围成的面积比标准面积大我们将判定所有大于蓝色曲线的量化曲线为【用户试图上下滑动】

绿色的曲线围成的面积比标准面积小，我们将判定所有小于蓝色曲线的量化曲线为【用户试图左右滑动】

问题回到了如何计算标准面积？
观察上图可以发现有一个明显的蓝色的角A这个角A和实例化的参数angle是同一个东西。

开发者可以通过控淛angle的值（angle的单位是°）来控制标准面积的大小
当然通过我的测试，angle的取值在 [5 , 20]最佳

那源码中是如何通过开发者传入的angle进行标准面积的计算的呢？

首先我会将用户的角度转化为tan值。

为什么需要tan值呢因为我就可以根据△X 计算得到 △Y = △X * tanA。

所以标准面积也能通过累加得到了

臸此，我们就可以通过用户手势的面积和标准面积的比较来得到一个比较理想的预判
通过预判，让用户在页面的任何地方滑动都感到舒适。

欢迎大家提出宝贵建议和技术交流 ?(????????)

我是嘉宝Appian一个卖萌出家的算法妹纸(??????)