我的前端封装之路

最近有粉丝提问了我一个面试中遇到的问题，他说面试的时候，面试官问我：你在以前的项目中封装过组件吗？或者做过npm公共库吗？遇到过什么问题吗？当时自己突然觉得好像没什么可回答的啊，但面试结束想起来，自己在前端开发工作中貌似又在不停的封装东西。但因为没有提前准备这类问题，所以回答的不是很理想。这篇文章，我说一些我的封装工作历程，希望对大家有帮助吧。

1 那是一个日历组件

1.1 S

1.2 T

1.3 A

1.4 R

2 那是一个小小的图片懒加载

2.1 S

2.2 T

2.3 R

3 js-tool-big-box

3.1 我的初衷

3.2 我的行动

3.3 我的成长

4 面试回答STAR法则

1 那是一个日历组件

1.1 S

我最初的工作呢，公司的项目是一个类电商平台，但售卖的不是生活用品，是一个网络售票的网站。当时我最初的工作除了日常的前端开发，那个时候还不太流行Vue和React，JQuery是我的吃饭家伙。一些日常组件封装啊，倒是常做，比如手风琴最初的jqueryUI只支持传入文字和HTML，但大家都开始以JSON格式传输数据了，所以我需要把JSON转成HTML再穿进去，这样将jqueryUI封装起来，再比如jqGrid的表格中的可输入，可提交做的很差，我就需要外部包一层。

但终于有一天，产品经理说，这个日历组件太不友好了，不好看，翻起来也费劲，更重要的是，也没个节假日啥的体现，对我们的用户太不友好了。

这项任务对于刚毕业的我来说，压力还是很大的，我当时翻了半天百度，竟然发现都是千篇一律的日历组件，要么就是讲解说明的，要么就是那种管理端使用的日历组件，让我很头疼。自己实现的话难度会不会太大了，而且当时虽然二次封装过jqery组件，但自己写还真么写过，如何把组件写好后，用于多处场景，如何定位不错乱，以及时间日期的各种API组合，这些我都还一知半解。但初生牛犊不怕虎，我依然接下啦这份间距的任务。

1.2 T

由于当时每个星期都会迭代新需求，而这个日历组件只是一个额外需求，这就要求我需要自己加班搞啦。而这就像是自己给自己提的一个需求，所以我需要自己按照产品的原话，再看着已有的那些日历组件，自己给自己列出需求条目。尽管自己对这些实现API了解不是太深，但我相信，只要条理逻辑是对的，我总会一步步实现出来的。于是我开始列需求：

要根据页面中的"预定日期"输入框，定位好自己的组件位置，不能便宜或者错乱；
日历只显示2个月份，分别是当月和下个月；
头部要采用2025年05月拼接的形式来展示；
星期几的展示呢，要从周一开始，而不是以往日历组件的从周日开始；
要计算出，当月有多少天，下个月有多少天；
要计算出每个月周一是星期几，然后一直排列到最后一天；
每个月最后一行是否需要展示，不需要则留白；
今天以前的的时间要置灰展示；
动态传入参数，有时候订票只能2个星期后，有时候是1个月以后，再往后的时间要置灰，不可点；
“今天”要在日历中有所展示；
法定节假日要在日历中有所展示；
点击日期的参数回传；
外部日期与内部日期的对准选中；

1.3 A

在罗列好需求以后，我深入学习了如何封装初始化jquery组件；按照预想的界面调控好主界面、年月、星期、日期面板；又开始从年月入手，获取每个月的日历，如何去根据周一的位置定位，如何获取今天去置灰之前的日期，如何根据入参置灰不可选的之后的日期，再维护好法定节假日，根据节假日去匹配日期显示等。

最终一步步按照自己的需求，开发、调整再开发，终于可以开始测试了。组件能够越来越完善，感谢测试同学的精心细点，把一些例如今年12月到明年1月啦、例如结束时间不准确啦等问题提出来，最终完成功能，达到上线效果。

1.4 R

其实现在回想起来，那个时候因为热爱前端开发工作，哪怕市面上没有的组件，有一定难度我还是很愿意尝试一下的。那个时候最大的难点就是，自己的JS基础还不是很牢固，一个组件有那么多的细小功能需要配合整理，需要自己整理好开发思路去完成整个功能。

通过这个小日历组件的开发，很好的锻炼了自己的底层开发技术，这对我后续封装其他通用组件打好了基础。同时，由于法定节日假使需要一年一维护的，这就使得我需要将这个日历组件的文档整理好，哪怕离职的时候也要交接好，不至于来年日历组件显示异常。这也很好的锻炼了我对待工作的责任心。

2 那是一个小小的图片懒加载

2.1 S

最初接手这个项目的时候呢，里面其实是有一个图片懒加载的组件的，看似很好用的样式，lazy.vue，可以传入图片，先显示一个小Logo，等待图片加载完成再显示，但在不断进行性能优化的过程中，发现这个图片懒加载的功能捉襟见肘。

我们最初只是在一个元素内展示这个img，img也是lazy.vue最终返回的内容。但慢慢的对这个小lazy需求就多样化起来了，

比如需要高清显示的时候呢，我们需要加载2倍图，甚至3倍图，不高清的时候，1倍图就可以了；
有的浏览器呢，图片宽高跟着父元素走，因为我们设置了父元素宽高，而子元素这个img呢，我们设置了100%，但有的浏览器呢，子图片宽高不跟着父元素走，很奇怪；
最初的窗口监听也有问题，有时候滑到这里了，还不加载呢，或者很慢；
有的网页很长很长，得有四五屏那么高，结果图片如果都加载同一个域名下的，慢慢就很卡很卡，那种卡，特别卡；慢慢的，
外部公司又想打广告，图片域名又跟之前的不同了；
有时候是个gif，你怎么弄它就是慢，而且体积还很大；
有时候吧，比如首屏，又不需要图片懒加载了，但我们又希望图片都走同一个出口来显示，首屏你再给他懒加载会弄得显示起来更慢；
有时候用户一下滑到最底部了，你懒加载也是慢，因为图片还没反应过来呢；
有时候，访问曝光的时候，产品又希望图片如果显示在当前区域时间不足多久不曝光

反正就是，别看小小的图片懒加载，但却承载了他不该承载的期望。

2.2 T

不过这个图片懒加载组件丰满牢固倒不是一下子完成的，也是在前端项目优化、项目迭代、学习优化知识的过程中一点点积累起来的。而这过程中，我采用了以下方案：

2.3 R

组件虽小，但在优化改进过程中，发现最大的难点莫过于多样化的需求。而在每次改进过程中，都会涉及到一些技术盲区，这就需要我不断的学习与实践。

通过不断完成这个图片懒加载组件，显著减少了页面首屏初始化加载的时间，提升了用户体验。此外，组件的多样化配置选项使得它可以灵活地应用在不同的场景中，团队开发效率得到了很大提升。

而我也在不断完善与学习中，不断加强了对前端性能优化的理解、提高了对复杂需求的解决能力以及增强了对用户体验的重视。整体来说，它使得我对前端项目开发整体认知的提升起到了很大的帮助。

3 js-tool-big-box

3.1 我的初衷

其实我在前端项目开发中，一直是需要哪些公共方法，临时写，然后大家互相在群里说一声：我在utils目录里加了一个方法，大家需要发送jsonp的时候，需要获取uuid的时候，需要设置localStorage的时候，你们可以直接用啊，不用单独写啦。然后干着干着，发现大家写了好几份，有的单独写到业务组件里，有的几乎又在utils目录里加了一份，然后悄么声的，不review代码，你看不到。又有时候，张三需要用到copy文字到剪贴板的时候，自己引入了一下组件，也没有说，结果第二天来了，李四发现项目起不来了，然后大喊，项目起不来啦，谁干的？然后李四大喊一声：你引入一下copy组件。张三大喊：好啦。又有时候呢，A项目用到了这个方法，写了一套，B项目又需要了，怎么办呢？拷过去吧，又有时候发现，A项目的代码找不到了，算了，接着写吧。

简单的说，今天的你我，还在重复昨天的故事，这一行破代码，接续放入你的破项目。

3.2 我的行动

最近呢，我业余时间开始了js-tool-big-box的开发，这个npm包已经开始有小伙伴开始下载使用了，给我提了一些建议，有的是改进建议，有的是新需求建议，还是挺不错的，功能还在不断丰富中。大家也不比担心包太大，影响项目部署后的加载。我们使用了模块化引入，你使用的少，最终打包到项目中的代码就会少。