最近有粉丝提问了我一个面试中遇到的问题，他说面试的时候，面试官问我：你在以前的项目中封装过组件吗？或者做过npm公共库吗？遇到过什么问题吗？当时自己突然觉得好像没什么可回答的啊，但面试结束想起来，自己在前端开发工作中貌似又在不停的封装东西。但因为没有提前准备这类问题，所以回答的不是很理想。这篇文章，我说一些我的封装工作历程，希望对大家有帮助吧。
目录
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包已经开始有小伙伴开始下载使用了，给我提了一些建议，有的是改进建议，有的是新需求建议，还是挺不错的，功能还在不断丰富中。大家也不比担心包太大，影响项目部署后的加载。我们使用了模块化引入，你使用的少，最终打包到项目中的代码就会少。
3.3 我的成长
其实开发npm包这种第三方工具，与自己在公司项目里开发功能还是不同的。毕竟这要被更多的开发者使用了，之前写的功能没问题，可能一下子使用的人多了，因为时间、地理、系统平台、浏览器、人的不同，也许就有问题了。
但这是一件很值得去做的事情，因为我热爱自己的工作，我希望自己可以更长久一些的在这个职位这个行业继续干下去。所以，自己的团队有这么一套东西，也是希望自己可以有个可以更值得自己喜欢，自己去维护的小产品。
通过这个项目呢，我也可以认识更多的开发者，更多的共同爱好者，可以帮助更多的同样热爱前端开发的小伙伴。当然，通过这个项目，我也使得自己的专业只是更加精进，使得这些工具方法们更加的健壮，那将是一件此生非常值得开心的事情。
4 面试回答STAR法则
说到面试呢，掌握STAR法则，我觉得是非常重要的。我们上面分别使用了S T A R，放到你面试的时候呢，就可以套用这个公式：
S： （Situation）你要做一件事情遇到的问题，或者说当前的现状，你要解决这个问题所带来的困难；
T： （Task）列举你要完成这项任务，所要解决的问题和难点；
A：（Action）说出你的行动，你都做了哪些方案来解决问题；
R：（Result）这个最重点，说出你做完这件事，有哪些结果，对项目有哪些正向的影响，对团队有哪些正向的帮助，对个人有哪些很棒的提升。
这个法则固然是用来套用的，但如果你掌握熟练了，就不比非得往4个步骤去套用了，可以灵活运用。
- 总之就是这件事呢，他很难，非常难，别人干不了；
- 怎么难呢，哎呀，这里难，哪里难，哪哪都难；
- 我这么干，吭哧吭哧的，救了火，打扫了火星子和烂煤炭；
- 屋子也干净了，大家也干净了，我也厉害了
2082
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
