最近组件库有多了一个组件:滚动条,你可能会问:
为什么还要再造一个轮子?IScroll
不好用吗?那还有Better-Scroll
啊?
这两个库都不错,自己平时也用,之所以要做,原因只有两个:
1、不符合 React 的范式:ui = f(state)
这两个库都是跨平台的,都是直接操作 dom
的,跨平台不是不好,肯定是好,但是在 React 的世界,要处理状态的同步,通常都是通过状态或属性来控制,虽然可以用个 React 包裹上面两个库,提供 React 版本,但是总是觉得不那么完美。
2、产品的无理需求
团队提供的是PC端面向B端的商业产品,需要有很好的交互体验
产品说:系统的滚动条能不能改改样式?
我说:可以改,Chrome 可以改,但是 FireFox 等改不了,
产品说:能鼠标 Hover 的时候变大?
我说:我试试,Edeg 本来身就支持,Chrome 努努力也行,其他的好像不行
产品说:你看这里表格里面的滚动条,能不能拿到浏览器边上来
我说:我靠,这个表格是在内部啊,离浏览器边上隔着几座山,他是个单独的组件
产品说:我怎么拖拽页面,就让页面滚动,不用拖滚动条
我说:移动端触摸屏可以,PC 上你可以用触摸板
产品说:我的触摸板咋不起作用
我说:Mac 上可以,你这 TinkPad 触摸板好像得安装个驱动,你可以用鼠标滚轮
好了,综上,我们的产品需求你明白了吗?下面我先写一条自己的感悟:
如果你想成长,那么在面对产品经理的无理需求的时候,你要拒绝,就要做到问心无愧的拒绝
事实上,拒绝很容易,总是有理由的,成本也是最低的,但是内心总是觉得,这个肯定可以实现,可惜时间成本有点高,bug 这么多,改不过来,要实现这个,怎么不得一两天?一两天都未必够,说不准有什么问题
当然,我还是是拒绝了产品,集中精力改阻断性的 bug,然后,趁着周末,好好构思了下这个滚动条该怎么做,要是答应了产品,最后做不出来,就糗大了,做出来,算是给产品的惊喜,虽然他意识不到这个有多坑……
设计目标
1、贴近原生,易用,易于从默认滚动条切换到新的滚动条
原生写法:
<div className="container"
style={
{
width: 500,
height: 400,
overflow:'auto'
}}
onScroll={onScroll}
>
<div className="content" ref="content" style={
{
width: 1000,
height: 800,
}}>
{content}
</div>
</div>
只需要修改容器的标签,替换后:
<Scroll className="container"
style={
{
width: 500,
height: 400,
overflow:'auto'
}}
onScroll={onScroll}
>
<div className="content" ref="content" style={
{
width: 1000,
height: 800,
}}>
{content}
</div>
</Scroll>
2、onScroll
接口和原生保持一致&#x