组件库-基础

and what should I use in different scenario(like import from node env or browser env)? 在写日期选择器的时候，在构

暂时方案： 默认根据取当地时区 this.in__start = moment(startDate /** String * /) 如果用户需求是：全球统一显示某个固定时区（比如，不论用户在哪个时区，

1. the first day of a week ？( 每個星期的第一天是周几) 每個星期的第一天 几种情况（JavaScript 代码） 第一天是周末 第一天是周一 ISO week date

思路 当传入 Start 和 End 的时候，左右两边的日期一般是根据 Start 的日期进行确认的 这时候，这样 inside__leftCalendarMonth = moment(this.st

用户行为的边界思量 左右不联动 startDate.month === endDate.month endDate.month - startDate.month >= 1 LeftCalendar

基本原则 行列：6 行 7 列 确定 6 * 7 日历中 的 第一天 几个特殊日历 2015-02 ： 02-01 是周日

返回值以及类型： preset 的点击返回值，延时返回 or 初始化时候确认？ 但有个问题：23:59 分打开页面，默认加载了组件，这时候的 Today 的 range 值也就确定了。 用户如果看完一

Vue.js 中 props、data、computed、watcher 初始化顺序

hover 到某个日期 hoverDate， 则需要显示如上图的范围 in-range，通过下面规则判定： 因为只点击了一次（第一次点击的值，默认作为 Start），Start 是确定的： 2018-

X轴变化 日期选择器选择多天，X轴显示为多天；日期选择器选择单天，X轴显示为 24小时 在这里， X轴 的计算 并不是依赖 后端的API返回【因为返回的数据可能会有天数缺失，后者小时缺失】，而是前端在

看起来好像左边是一个列表（比如班级列表），右侧呢，则是班级对应的学生列表 看这个需求/页面，感觉好像蛮简单的，开发的话，好像1-2天就OK了，甚至这1-2天都有点多了对吧 但我们进来看一下这个页面中的

Filters 约定：下拉菜单格式 项目中所有的下拉菜单均采用如下格式 好处： 格式统一，维护成本降低 写 API 转换层的输出比较统一：从后端拿到下拉菜单的格式可能不统一，但前端对其的format函

由一个奇葩交互 case引发的思考 需求 实际效果 2 现状 一部分产品缺少画原型图的能力，或者画出来的原型图都是 90年代的线框图 更甚之，只有文案，缺少示意图 示意图之间缺少 状态流转 B端 缺少

左侧列表-初始状态 左侧列表-默认值 左侧列表-分页 左侧列表-新增 左侧列表-删除 左侧列表-分页场景下新增 左侧列表-分页场景下删除 是否保留在当前页面 如果删除为当前页最后一项？ 如果删除为最后

```js const { getFieldDecorator, getFieldsError, getFieldError, isFieldTouched, getFieldValue, getFi

Label 标签是否可以设置固定宽度，自动换行

表单创建时候的写法 因为不是编辑模式，不用根据服务器端数据，进行已经选项 -- 可选列表 的映射关系，所以创建的时候，没有问题。 但编辑的时候，因为 getFieldDecorator 里面直接包装的