我的前端封裝之路

最近有粉絲提問了我一個面試中遇到的問題，他說面試的時候，面試官問我：你在以前的項目中封裝過組件嗎？或者做過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包已經開始有小伙伴開始下載使用了，給我提了一些建議，有的是改進建議，有的是新需求建議，還是挺不錯的，功能還在不斷豐富中。大家也不比擔心包太大，影響項目部署后的加載。我們使用了模塊化引入，你使用的少，最終打包到項目中的代碼就會少。