const DAY_STATUS = {
NONE: 0,
SINGLE_CHOSEN: 1,
RANGE_BEGIN_CHOSEN: 2,
RANGE_MIDDLE_CHOSEN: 3,
RANGE_END_CHOSEN: 4
};
_genDayData({startDate, endDate, availableStartDate, availableEndDate}) {
let result = {}, curDate = new Date(startDate);
while(curDate <= endDate) {
// use `year-month` as the unique identifier
const identifier = Helper.formatDate(curDate, 'yyyy-MM');
// if it is the first day of a month, init it with an array
// Note: there are maybe several empty days at the first of each month
if(!result[identifier]) {
result[identifier] = [...(new Array(curDate.getDay() % 7).fill({}))];
}
// save each day's data into result
result[identifier].push({
date: curDate,
status: DAY_STATUS.NONE,
available: (curDate >= availableStartDate && curDate <= availableEndDate)
});
// curDate + 1
curDate = Helper.addDay(curDate, 1);
}
// there are several empty days in each month
Object.keys(result).forEach(key => {
const len = result[key].length;
result[key].push(...(new Array((7 - len % 7) % 7).fill({})));
});
return result;
}
1. 前言
由于最近接到一个需要支持拖拽选择日期的日历需求,做出来感觉体验和效果都还不错,所以今天想跟大家分享一下封装这个日历组件的过程。
2. 调研开始
正所谓“磨刀不误砍柴工”,既然要做一个日历,那么先让我们来看看最终想要做成什么样:
由于之前吃过RN在安卓上性能表现不佳的亏,深深地怀疑这东西做出来能在安卓上跑么,尤其是日期要实时地随着手指滑动的位置发生变化。还有这牵涉到了手势系统,之前又没捣鼓过,谁知道有没有什么天坑在等着我。。。
唉,不管了,先把最简单的样式实现了再考虑这些吧~
But! 正所谓“巧妇难为无米之炊”,没有相应的日历数据,怎么画日历!So, let's do it first.
2.1 日历数据
Q1:如何确定日历要渲染哪些天的数据?
仔细观察先前的示意图,我们可以发现日历中有些天是暗的,有些是高亮的。也就是说日历上所渲染出来的这些格子,是有available/unavailable区别的。为此,我们可以支持两种方式通过props传入:
理清了思路,我们来看看代码实现:
Q2:calendarData的结构怎么设计比较好?
经过上一步,我们已经知晓了哪些day是需要渲染的,接下来我们再看看数据结构应该怎么设计:
我们再来看看相应的代码应该如何实现:
生成日历数据就这样大功告成啦,貌似还挺容易的嘛~ 我们来打个log看看长什么样:
2.2 日历样式
其实样式这个环节,倒是最容易的,主要是对日历的内容进行合适的拆解。
除此之外,还有一点就是一定要考虑该日历组件的可扩展性,样式方面肯定是可以让调用方可自定义啦。为此,代码方面我们可以这么写:
2.3 实现拖拽
呼~ 长吁一口气,万里长征终于迈出了第一步,接下来就是要实现拖拽了。而要实现拖拽,我们可以通过大致以下流程:
为此,我们来逐一解决各个问题:
2.3.1 获取相关布局和坐标信息
获取相关布局:
在RN中,有两种方法可以获取一个元素的布局信息。一个是onLayout,还有一个就是UIManager.measure。讲道理,两种方法都能实现我们的需求,但是通过UIManager.measure,我们这里的代码可以更优雅。具体代码如下:
通过给UIManager.measure封装一层promise,我们可以巧妙地利用Promise.all来知道什么时候所有的month元素都已经渲染完毕,然后可以进行下一步的dayLayouts计算。但是,如果使用onLayout方法就不一样了。由于onLayout是异步触发的,所以没法保证其调用的先后顺序,更是不知道什么时候所有的month都渲染完毕了。除非,我们再额外加一个计数器,当onLayout触发的次数(计数器的值)等于month的个数,这样才能知道所有month渲染完毕。不过相比于前一种方法,肯定是前一种更优雅啦~
获取手指触摸的坐标信息:
重头戏终于要来啦!在RN中,有一个手势系统封装了丰富的手势相关操作,相关文档可以戳这里。
首先我们来思考这么个问题,由于日历的内容是用ScrollView包裹起来的,因此我们正常的上下拖动操作会导致ScrollView内容上下滚动。那么问题就来了,我们应该怎么区分这个上下拖动操作,是应该让内容上下滚动,还是选中不同的日历范围呢?
在这里,我采用的解决方案是用两个透明的View盖在ScrollView上层,然后把手势处理系统加在这层View上。由于手指是触摸在View上,并不会导致ScrollView滚动,因此完美地规避了上面这个问题。
不过,如果用这种方法会有另外一个问题。因为透明的View是采用的绝对定位布局,left和top值是当前选中日期的坐标信息。但是当ScrollView上下发生滚动时,这层透明View也要跟着动,也就是在onScroll事件中改变其top值,并刷新当前组件。我们来看看具体代码是怎么实现的:
注意:state中的startDate和endDate是当前选中时间范围的第一天和最后一天。由于现在都还没有值,所以目前看不出效果。
接下来,我们再实现最重要的_initPanResponder方法。PanResponder提供了很多回调,在这里,我们主要用到的就只有5个:
除此之外,以上的回调函数都会携带两个参数:event和gestureState,它们中包含了非常重要的信息。在这里,我们主要用到的是:
event.nativeEvent:
gestureState:
因此,我们可以在onPanResponderGrant记录下一开始手指的坐标,然后在onPanResponderMove中获取deltaX和deltaY,相加之后就得到当前手指的实时坐标。一起来看下代码:
我们给state中的startDate和endDate随意加个值,并给draggableArea加个半透明的红色来测试下,我们的手势操作到底有没有起作用。
咦~ 怎么console得到的值看起来好像不太对。打印出来的(x, y)像是相对draggableArea的坐标,而不是整个ScrollView的坐标。不过这也好办,因为我们知道draggableArea的left和top值,所以加上就好了。我们可以在onTouchStart这个函数中做这件事,同时还可以区分当前手指触摸的是选中时间范围内的第一天还是最后一天。代码如下:
2.3.2 坐标信息转换成日期信息
根据上面的步骤,我们已经成功地获取到了当前手指触摸的实时坐标。所以,接下来就是把该坐标转换成落在哪个日期上,从而可以判断出选中日期是否发生变化。
这一步,说简单也简单,要想复杂那也可以复杂。简单来看。我们的this._dayLayouts保存了所有Day的layout,我们只需要进行遍历,判断手指坐标有没有落在某个Day的范围当中即可。复杂来讲,就是减少不必要的比较次数。不过,我们还是先实现功能为主,优化步骤在后面介绍。实现代码如下:
2.3.3 对比前后选中日期,触发渲染
经过上一步的positionToDate,我们知道了当前手指落在哪一天上。接下来,就是比较当前新的选中日期和拖动之前旧的选中日期,看看有没有发生变化。
特别注意:假如我们一开始手指是触摸在start上,但是拖动之后手指停留的日期已经大于end上的日期;或者反过来,一开始触摸在end上,拖动之后手指停留的日期小于start上的日期。这种特殊情况下,pressStart和pressEnd其实发生了变化,所以需要特殊处理。我们来看看代码是怎么写的:
这里需要对_updateDayStatus函数进行稍加解释:
我们在renderMonthBody用的是FlatList,由于FlatList是纯组件,所以只有当props发生变化时,才会重新渲染。虽然我们在_updateDayStatus中更新了calendarData,但其实是同一个对象。所以,分配给renderMonthBody的data也会是同一个对象。为此,我们在更新Day的status时用一个flag来表示该月份中是否有日期的状态发生变化,如果发生变化,我们会用Object.assign来复制一个新的对象。这样一来,状态发生变化的月份会重新渲染,而没有发生变化的月份不会,这反而算是一个性能上的优化吧。
2.4 其他
其实,上面我们已经实现了基本的拖拽操作。但是,还有一些遗留的小问题:
...
当然了,上面的这些问题都是细节问题,考虑篇幅原因,就不再详述了。。。
但是!性能优化问题是肯定要讲的!因为,就目前做出来的这东西在ios上表现还可以,但是在android上拖动的时候,会有一点卡顿感。尤其是在性能差的机子上,卡顿感就更明显了。。。
3. 性能优化
我们都知道,react性能上的优化很大程度上得益于其强大的DomDiff,通过它可以减少dom操作。但是过多的DomDiff也是一个消耗,所以怎么减少无谓的DomDiff呢?答案是正确地使用shouldComponentUpdate函数,不过我们还是得首先找出哪些是无谓的DomDiff。
为此,我们可以在我们写的所有_renderXXX函数中打一个log,在手指拖动的时候,都有哪些组件一直在render?
经过试验,可以发现每次选中日期发生变化的时候,_renderMonth,_renderMonthHeader,_renderMonthBody和_renderDay这几个函数会触发很多次。原因很简单,当选中日期发生变化时,我们通过setState更新了clendarData,从而触发了整个日历重新render。因此,每个month都会重新渲染,相应的这几个render函数都会触发一遍。
3.1 减少renderMonth的DomDiff
既然源头已经找到,我们就可以对症下药了。其实也简单,我们每次只要更新状态发生变化的月份就可以,其他的月份可以省略其DomDiff过程。
但是!!!这个解决方案有一个弊端,就是需要维护changingMonth这个变量。每次手指拖动操作的时候,我们都得计算出哪些月份是发生状态变化的;手指释放之后,又得重置changingMonth。而且,现在这个组件的操作逻辑相对来说还比较简单,如果交互逻辑往后变得越来越复杂,那这个维护成本会继续上升。。。
所以,我们可以换个思路~ month不是每次都会DomDiff吗?没关系,我把month中的子组件封装成PureComponent,这样子组件的DomDiff过程是会被优化掉的。所以,即使每次渲染month,也会大大减少无谓的DomDiff操作。而_renderMonthBody用的是FlatList,这已经是纯组件了,所以已经起到一定的优化效果,不然_renderDay的触发次数会更多。因此,我们要做的只是把_renderMonthHeader改造成纯组件就好了。来看看代码:
3.2 减少renderDay的DomDiff
根据前面的试验结果,其实我们可以发现每次渲染月份的时候,这个月份中的所有DayItem都会被渲染一遍。但实际上只需要状态发生变化的DayItem重新渲染即可。所以,这又给了我们优化的空间,可以进一步减少无谓的DomDiff。
上面的例子已经证明PureComponent是再好不过的优化利器了~ 所以,我们继续把_renderDay改造成纯组件,来看代码:
3.3 减少positionToDate的查找次数
经过上面两步,已经减缓了一部分的DomDiff开销了。那还有什么可以优化的呢?还记得前文提到的positionToDate函数么?目前我们是通过遍历的方式将坐标转换成日期的,时间复杂度是O(n),所以这里还有优化的空间。那么又该怎么优化呢?
这时以前学的算法是终于有用武之地了,哈哈~ 由于日历中的日期排版很有规律,从左到右看,都是递增的;从上到下看,也是递增的。so~ 我们可以用二分查找来减少这个查找次数,将时间复杂度降到O(nlog2)。不过,在这个case中,我们应当如何使用二分呢?
其实,我们可以使用3次二分:
思路已经有了,可是我们的this._dayLayouts是一个对象,没法操作。所以,我们需要做一层转换,姑且就叫索引吧,这样显得洋气~~~ 来看代码:
从上面打印出来的索引结果中,我们可以看到建立索引的过程主要是干了两件事:
接下来再看看二分查找的代码:
我们来绝歌例子看看优化的效果:假如渲染的日历数据有6个月的内容,也就是180天。最坏的情况下,原先需要查找180次才有结果。而现在呢?月份最多3次能确定,row最多3次能确定,col最多3次能确定,也就是最多9次就能找到结果。
啊哈~ 简直是文美~ 再看看手指拖拽时的效果,丝毫没有卡顿感,妈妈再也不用担心RN在android上的性能效果啦~
4. 实战
费了那么大劲儿,又是封装组件,又是优化性能的,现在终于可以能派上用场啦~ 为了应对产品变化多端的需求,我们早就对日历的样式做了可配置化。
来看看效果咋样:
5. 写在最后
看着眼前的这个demo,也算是收获不小,既接触了RN的手势系统,还涨了一波组件的优化经验,甚至还用到了二分查找~ 嘿嘿嘿,美滋滋~
老规矩,本文代码地址:
https://github.com/SmallStoneSK/react-native-draggable-calendar