关于前端:TS实现控制台实时快照日志的EventBus-npm库

前言

本篇文章次要围绕如何正确的实现一个合格的 npm 包的教学。不会在具体的代码实现上花太多的工夫。定位是偏授渔格调的，次要是让同学们晓得如何该正确的解决代码实现以外的一些工作。有趣味的小伙伴，可自行返回参考 monitor-event-emitter，麻雀虽小，五脏俱全。demo 在控制台可演示每次事件处理器执行时的日志信息。

背景

往年的指标之一是想深刻学习下 Typescript。

之前始终是以 vue 技术栈为主，去年公司开始用 react+antd+typescript 开发一个新后盾。这对于始终以来习惯了 javascript 涣散类型的我，是一个不小的挑战。很多时候，习惯性的用 any 去躲避所有问题。当初回过头来看之前的一些业务代码，飘红一片，本人都禁不住的厌弃

我不禁开始思考之前学习 typescript 的形式，大部分都是停留在 看的阶段。官网文档也好，技术文献也罢，看了一大堆，到最终本人实操的时候还是顾此失彼

所以我决定改过自新，筹备尝试本人用 typescript 写一个库。正好，之前接触的业务代码中，常常能看到一个之前我司大牛用 javascript 写的事件触发器，所以筹备着手颠覆从新用 typescript 实现一遍。一来是为了加深对 typescript的了解和使用，二来是为了补救很长时间以来，没有技术输入的空缺，同时寄希望于丰盛下该库的性能

千好万好，不如入手撸一遍好

概述

因为涉猎的面比拟广，对于一些陈词滥调的货色，我会一笔带过。对于一些难以了解的点，能够参考 git commit 提交记录看我做了哪些工作，有趣味的且不明确的中央可自行返回查阅官网文献。并且有些货色，我可能也是第一次接触，所以说的不对的中央，还请见谅。请给我多一些温顺

认真看完这篇文章后，我置信你肯定可能有所播种，次要有以下几点

• 大局观 晓得从零开发一款属于本人的库的必经之路
• 工程化思维 晓得除了写性能代码，还有哪些是你必须要去关注和实现的工程化配置，它们将反哺你进行更加标准和规范的开发
• 如何去写一个比拟标准的文档

• 理解一些有意思的技术点

  • excalidraw 手绘格调设计图，格调标新立异，程序猿必备
  • github action 大厂出品，必属精品。平时能够几行代码很多实现有意思的事，写博客必备
  • shields.io 让本人的库看起来更加正式的图标设计库

实现

第一步：创立我的项目

没什么好说的，先创立一个仓库，这里因为前面咱们写的库要公布到 npm 官网上，让其他人能够自在的下载和应用，所以重点是起一个 好名字，何为好名字，我的了解是有两点

• 防止包名反复
• 见名知意

mkdir monitor-event-emitter // 创立文件夹
cd monitor-event-emitter // 进入文件夹

git init // 变成 git 仓库
npm init -y // 初始化包，会生成一个 package.json 包配置文件

这里我刚开始的包名并不叫这个，公布了第一版本之后，随着我的库的外围性能（控制台实时打印日志快照）的实现，我才从新改了名字。为了就是让他人看到这个包名的时候，就能大略晓得它是什么，有什么特点，有没有吸引我去下载应用的欲望

第二步：欠缺包配置文件

欠缺 package.json 文件，这个文件的 意义不凡，它是别的人从理解你的包到能正确应用你的包的外围，挑几点说下

• main
  库的入口文件，你配置了啥，最终他人装置应用该库的时候，就会去寻找该文件，防止冗余的文件门路引入
• description
  库的形容文件，一句话，越精炼越好，突出库的亮点，吸引他人用它才是要害
• types
  该库的申明文件，因为是 typescript 开发的包，他人用的时候，为什么会有代码提醒和参数类型纠错性能，就是该文件提供的能力
• files
  上传到 npm 上的文件包含哪些。没必要将你的所有文件和文件夹都推上去吧，外面的文件，可能让库失常应用且不便用户了解的前提下，越少越好
• repository
  填写你的 github 我的项目仓库，这样他人在应用库的过程中呈现问题了，或者就是想看看你的个人主页，至多可能找到入口
• keywords
  该库类型的关键字，比方我的库次要是实现事件实时监听，我就用了这几个monitor、event、emitter

第三步：工程配置

具体性能实现前的重要步骤，工程化畛域不可或缺的局部，大抵讲一下

• husky
  在咱们本人的仓库目录下，有一个叫 .git 的目录，外面放了一些脚本 hook，为了不便在执行git 的步骤过程中，前置或者后置执行一些额定的脚本，从而让咱们能够干涉它的流程，做一些有意思的事。比方 pre-commit，也是最罕用的脚本，次要用来在commit 之前，做一些查看工作，比方你的提交信息是不是符合规范，他人是否可能依据你的提交信息窥见你本次提交的代码用意等。还有一个就是代码格调和品质校验，配合上 eslint、prettier、stylelint 几乎不要太爽。你能够本人写一些脚本，比方我之前尝试本人用 node 实现了一个小性能，在 sentry 版本号同 changelog 版本号不匹配的状况下，回绝本次提交的逻辑。然而更不便的是用一下现成的库 husky 吧
• lint-staged
  一句话论述就是，束缚了 husky 脚本执行范畴。只去校验我本次提交的内容，它的意义可能在你重构一个旧我的项目或者增加代码品质及格调校验时，可能失去更好的体现。毕竟，没有人想只提交一行代码，会把前人写的骨灰级代码的格调或者品质问题都裸露进去吧，尽管有主动修复的问题，然而依然有的是编辑器不能主动帮咱们修复的，尤其是有强迫症的老哥，预计心态霎时爆炸
• eslint
  次要用来治理代码品质问题。托付你用 let，用var 我就给你报错！然而我也能够很仔细的帮你纠正错误，修复不了的，还得劳烦你本人手动操作一下
• prettier
  次要用来治理代码格调问题。束缚大家开发格调对立，防止每个人的格调不对立而导致的合并抵触或报错问题，比方语句开端要不要用分号，单个参数的函数需不需要有括号包裹、用双引号还是单引号。这个并没有好坏之分，本人团队磋商着出一套大家都能承受的标准即可
• stylelint
  次要用来治理款式代码的品质和格调问题。比方色彩应该用 #000 还是 #000000 亦或是black，还有就是款式属性的程序问题等。尽管任意一种形式都不会影响页面的展现成果，然而从久远的保护角度来看，它是十分有意义的。而且就下面提到的程序问题，也是解决性能优化的一个小点，因为它能够缩小浏览器的重排或是重绘
• commitlint
  束缚提交信息标准，别终日只会来一句 git commit -m 'update' 了，你倒是通知我，你 update 了什么呀？波及到的范畴有哪些呀？是重构还是删除？永远记住一句话，提交信息是给人看的，不是给神看的，没有哪个人可能通过你那强劲的 update 六个字母，窥见你的大脑思路。同时我也敢保障回过头的你本人再去看提交信息时，也是一脸懵逼

第四步：本库特点

到这里，咱们曾经能够正式着手实现咱们的性能代码了。该库 外围文件 不算正文大略 400 行代码。实现了一个轻量级的事件监测触发器。集体认为，如果你相熟 ES6 语法，还是很容易读懂的。具体的实现有趣味的能够参考 git commit 提交记录，有更好的实现思路的能够给我提 issue 或者通过 pr 参加到我的项目中来。

每次当接管到一个事件执行命令且函数执行后，控制台就会实时的将日志以表格的模式打印进去，不便调试进行问题定位。实际效果请参考 demo 控制台。大抵思路请参考该图：

该库的次要特点有

• 没有太多的束缚。因为我的集体认知就是束缚越少，应用起来越不便，就越违心有人去用它和理解它。有一种广泛场景就是，尽管你写的货色很好用，然而束缚太多了，实例化的时候，须要传递 N 个参数能力涉及它的灵魂，那么我很大可能性会放弃应用它。记住一点，应用老本越高，弃用它的概率就越大。然而话说回来，很多库看起来应用形式十分自在，用起来没有太多的心智累赘，那是因为它的很多逻辑被 高内聚 了。说直白点，就是开发者预判了你的所有应用习惯和场景，在库中实现的时候大部分都思考到了
• 设计之初思考过用对象还是用 map 来保护我的事件核心，因为波及到频繁的 add、remove、check 等逻辑。自认为抉择用 map 更加适合，毕竟它自带的一些办法着实好用。这里我想表白的是，有很多种形式都可能实现性能，然而在设计之初，你就要有肯定的大局观点。你应该思考怎么样去更好，更不便，更直观的实现它，而不是实现一半了，发现自己输在了 起跑线 上，颠覆从头再来几乎头皮发麻
• 反对实时监测能力。大抵意思就是咱们的业务代码中，可能有 N 处不起眼的中央，注册了 N 个事件监听器，也可能在 N 个角落中，默默的触发了它们。如果没有监测机制的话，很难弄状况它们执行的实在环境和状况，比方是什么类型的函数处理器？执行参数是什么？返回后果是啥？执行程序是什么等。然而有了实时观测的能力后，你就能够很不便的在控制台中，实时观测到事件的触发，包含它们的入参、出参、类型。这样更加不便定位问题，做到 有迹可循
• 大部分能用表格或者图片出现用意的事，就不要用苍白无力的文字去表白。因为这是个 快节奏的社会 ，人们大多数没有急躁。所以我将简单（ 这里的简单是指 map 类型的数据，在控制台打印后看上去不太清晰 ）的map 构造的事件执行快照，转换成数组模型，在控制台中以表格的模式出现给大家，更加容易浏览和调试。同时反对 mode 参数，也能够让你自在的抉择，你须要什么看到样的数据。目前反对default、cool
• 做了定制化的提示信息，依据你应用时传入的 scope 字段，实现在控制台中相干日志信息的分类展现。这样就能够做到不便地区分不同业务下呈现的问题，从而疾速定位及批改问题

而后就是一直的优化性能代码的实现，同时记得放弃代码的易读性 …

第五步：单元测试

当你认为你写的外围逻辑曾经实现的时候，你就要去发展 单元测试 了。你要确保你的代码在他人应用之前，呈现问题的概率降到最低。大部分的性能应用场景，你都须要通过单元自测的形式提前演练一遍。简直所有优良的库，都有单元自测模块。它的意义并不仅仅是发现错误并纠正，更有价值的是，它能测出一些你在实现时没有思考到的中央，驱使你去从新欠缺业务逻辑。

• jest
  单元测试框架。我之前也没用过，然而跟着文档尝试用了下，发现还是挺好了解和应用的。_这里有一些难堪，不太会写异步的，尽管看了文档的用法，然而具体到联合我的一步场景时还是不太了解该怎么去写，有善于的小伙伴能够帮忙欠缺下, 提个 PR,磕头致谢_

第六步：写一份合格的 README

当你感觉所有准备就绪筹备公布 npm 时。且慢，最重要 的一步来了。那就是写一个规范格局的 README.md，什么叫规范，我提炼几点我的了解：

• 纲要清晰，次要蕴含以下几局部

  • demo能用一个理论演示场景展现给他人你的库的特点，就不要用苍白无力的文字
  • why为什么用这个包。能够论述下该包的用处，以及它与现存的一些同类型包的区别，重点解决了什么问题
  • install该如何能力装置你的包，反对哪些环境下应用
  • usage最根本的应用形式
  • api反对的 api 有哪些，举一些例子，让人晓得该怎么用
  • config该包反对的参数有哪些，都有什么意义，类型是什么
  • todo接下来要实现的性能，以及记录下目前做的不好的点，后期待优化

• 正式、器重起来。如果你认为你要做的事，是一件有意义的事。那么就去把它做好，且让它看起来像那么回事。

  • 一些小图标 shields.io，比方你的库用了什么语言，单元测试覆盖率是多少，打包后的体积是多少。这些都是影响到他人是否违心应用你的库的关键点，且看起来 逼格满满 。想要提醒小伙伴的是，这里的图标，有的并不仅仅只是一个icon 展现动态的数据。比方我的 codecov 图标中的单元自测覆盖率，是在提交代码时通过 github action 实时将测试覆盖率报告上报到第三方的，还是很有意思的。这里想安利大家去学习下 github action，真的是太香了。我就是个前端小仔，你让我搞定一些太深的后盾服务器相干的业余配置，比方 nginx、jenkins 配置，臣妾真的不肯定能搞定呀。而学会了它，几乎就是赛神仙，你想实现的所有都能通过简略的几行代码实现。比方部署网站，定时执行工作，拦挡单元测试，有人提交 issue 的时候告诉我等等，有利用 github pages 写博客的小伙伴，肯定要去学着用它一下，难道当你只用执行一下 push 命令后，你的本地博客最新内容曾经部署到线上为别人所知，它不香吗？

第七步：写博客推广

写博客，推广你的库。你要可能用老练艰深的语言，通知大家你做了一件什么事，它有什么意义？给你带来了什么成长，同时又解决了什么问题。让大家可能从你的文章中，有所播种，同时也能吸引大家参加到你的我的项目中来

这里我想借用一个梗，那就是：

不写博客的程序猿不肯定是不合格的程序猿，然而违心去写博客的程序猿未来肯定会成为一名合格的程序猿

落笔

原创不易，且赞且珍惜。看官至此，何不来一波 mark 三连。

monitor-event-emitter 源码

demo 成果演示