5年老前端，今天终于发布了自己的npm包
携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第 1 天，点击查看活动详情
项目背景：
产品提了个，说是很重要的需要，要看各种事件对某个指标的影响，要前端开发一个事件线和折线图联动的组件，给了个设计稿大概就是下图这个样子：
- 展示5种不同类型的事件，展示不同的主题色；
- 每个事件有开始时间，可能有结束时间，标题，详情等信息；
- 事件展示的长度和时间跨度同步，hover现实详情，点击查看具体开始/结束时间；
- 同步展示相关指标以及同比的趋势图，和事件线同步滑动等等；
经过百度/谷歌几番搜索，最后确定了一个貌似简单可行的方案：
- tl-timeline + ant-design-charts的混合方案，方案的难点在于两个组件联动，采用的方案是监听tl-timelie滑动然后动态改变ant-design-charts折线图缩略轴这样一个方案。
但是这个方案又个天坑就是事件线的x轴和折线的x轴由两种完全不同的方案实现，tl-timelien完全是div实现，ant-design-charts的折线是canvas/svg实现，两个轴都有不可控的自适应场景，所以就仅仅是x轴同步展示的问题，就出现各种一波又一波的bug，再加上折线刷新，扩展性差等问题，只能选择放弃该方案。
难道就和产品说没办法了？不！其实一直有另一种canvas自研方案，只不过自己一直在逃避而已！自己心里没底，没有自信罢了。最后想了想自己已经干快5年前端了，前几年还专门学习过canvas相关知识，只是业务上一直没有使用，荒废了；现在终于有了业务场景了，难道真的就不去试试，难道就这样承认自己老了，学不动了？继续混吃等死...
老当益壮，宁移白首之心？穷且益坚，不坠青云之志。
不不，不能，经过几番挣扎，最后决定试试！
于是利用下班或周末时间一边搜索canvas的各种API、动画基础知识，一边写demo实现，真的是不试不知道，一试吓一跳：真的太复杂了。
举个例子🌰：刻度下的日期展示，展示多少，多远展示一个，你不设计好，他能给你糊成一坨。
不过，经过接近一个月业余时间的努力，总体上终于做出来了，上图就是效果。当然用于业务，可能还要展示10年的数据，还有很多需要优化的地方，这不正是进阶段位的机会吗？
下面就从项目的搭建，到事件线，趋势图，各种交互几个角度来详细介绍该组件的生产过程，希望对大家有帮助。今天就先讲下组件库项目搭建，组件具体实现过程除本篇项目搭建外，还有：
准备工作
- 百度
- 百度
- 最重要的还是百度
开个玩笑，不过说真的，咱还真离不了百度，它就是搜索的代名词!
当然这也是说笑，能用谷歌咱还是用谷歌，不然百度和bing一起用才够。)。
言归正传，既然是npm包，那咱首先得有npm账号，然后咱得有代码库，就直接用dumi脚手架来搭建好了，毕竟咱的重心是开发组件，环境问题交给更专业的团队。
- npm账号：www.npmjs.com/
- dumi文档：d.umijs.org/zh-CN/guide
- 对canvas常用API有一个全面了解；
接着就该咱程序员大大场了，咱可以不生产代码，咱可以只是CV工程师，但咱得知道有这么一回事，不然连度娘都帮不了你！
搭建项目
dumi是什么？为什么用dumi搭建组件库？
根据官方文档介绍，dumi是文档工具，可生成类似ant design一样功能的组件库网页。这当然是我门需要的，我们希望自己写的组件，能被更多人使用，那就需要有一份详细可靠的API文档，dumi就是生成这样文档的工具。
另外，我们辛辛苦苦写的组件，当然要打包发布到npm市场才行，这就需要用到dumi默认支持的father来打包。
总结来说，dumi具有以下功能：
- 开发组件；
- 调试组件；
- 编写文档；
- 编写测试用例；
- 打包组件；
Talk is cheap, show me the code.
找个空文件夹，用作组件库。然后在这个空文件下执行初始化命令：
$ npx @umijs/create-dumi-lib # 初始化一个文档模式的组件库开发脚手架
# or
$ yarn create @umijs/dumi-lib
$ npx @umijs/create-dumi-lib --site # 初始化一个站点模式的组件库开发脚手架
# or
$ yarn create @umijs/dumi-lib --site
初始化时注意有两种模式，一种是doc文档模式，一种是site站点模式。这两种模式有什么区别呢？顾名思义，文档模式就是以文档为主，而站点模式就是类似一个静态网站，具体样式如下：
上面的图片，左边是文档模式，右边是站点模式。从图中不难看出：
- 只展示组件列表以及使用文档的话，推荐采用文档模式；
- 提供除了组件和文档之外还能为我们的组件库设计首页，提炼主题，设计思想等其他更丰富的内容的话，那就推荐使用站点模式。
一句废话：个人觉得一般采用文档模式就够了，毕竟个人开发者精力有限，能把文档写好，让其他人容易上手，容易使用，这对咱们的组件库才是最实用的。
其他更详细的使用配置，请查看官网。
组件开发
项目搭建好了，我们会得到类似下面这样的一个项目：
只看项目目录结构，远看还以为是个普通的React前端项目，当打开入口的src/index.tsx文件时，我们发现这个项目只是导出了组件，当然组件库不导出组件导出什么。问题是，你导出组件，我怎么调试组件呢？
前面在列举dumi的功能时，说了dumi可以调试组件的。原来dumi采用了一种理念叫：开发者应该像用户一样使用组件，所以我们的调试入口在组件的index.md，我们来打开看看：
从上图我们可以看到，在编写组件文档中的demo时，直接像用户一样从组件库npm包中引入的组件，虽然这个组件库我们还没有发布，但是已经可以在demo中使用，当然即使发布了，这里demo的包依然是本地。
现在项目搭建好了，该跑起来溜溜了。
npm i
...
npm start
项目运行起来之后，大概是这个样子，左边是组件列表，中间是demo+文档，右边是文档大纲。
这个项目当初使用的是站点模式，现在看来很多余。dumi使用文档说是直接修改配置字段就可以切换，结果配置之后样式错乱了，所以暂时就先这样。
项目跑起来了，接下来就该开发组件了。
上面展示的事件线组件是为业务需求定制的组件，事件和折线同步展示相关性。目前一期已经开发完毕，欢迎有同样需求的前端试用哈，假如用的还过的去的话几个给个star，有bug或建议欢迎提issues。
后面也计划写博客总结下这个事件线组件的实现过程，坑点，汇总下相关API的使用。感兴趣的话，点个关注不迷路。
开发组件的过程是个孤独且漫长的过程，建议先推出一个基础功能版本，再逐渐扩展；最好大概列一个开发计划，有条不紊进行下去。
组件发布
俗话说：丑媳妇也得见公婆。经过一段时间的开发和调试，组件库终于可以拉到市面溜溜了。是不是很激动，接下来我们介绍下组件发布的大概流程。
在命令行里登录已在官网注册好的账号：
执行npm登录命令：
npm login
依次输入注册用户名，密码和邮箱，这里需要注意是只能登录npm官网，不能是其他镜像源，如果使用cnpm或其他npm镜像源，则需要指定登录npm源网站：
npm login --registry http://registry.npmjs.org
登录成功之后就可以执行发布了，dumi已配置发布前默认打包，所以我们忽略打包环节
npm publish
# or 指定发布源
npm publish --registry http://registry.npmjs.org
发布之后就可以在npmjs官网上查看自己的组件库了，其他开发者也就可以使用这个组件库了。
传送门：multi-event-line
哦，对了最后提醒一下大家。一般npm组件发布之后，需要等待大概半天之后才能搜索到，想查看的话可以在个人中心里查看。
谢谢大家，感觉有帮助的可以点个赞支持一下。想了解multi-event-line事件线组件更多细节的朋友可以点个关注不迷路。