摘要:背景需要包寫起來爽,然而如果遇到沒有現成的化的工具函數,就需要自己想辦法弄出一份類型聲明文件了。最為重要的是,這種遷移方面我們可以隨意自定義化中所需要的工具函數,遷移粒度都可以由自己控制。
1、背景 1.1、需要 TS 包
TypeScript 寫起來爽,然而如果遇到沒有現成的 TS 化的工具函數,就需要自己想辦法弄出一份類型聲明文件了。
前兩天要寫的小工具庫(Typescript 語言寫的),因其用到 debounce 和 throttle,雖說 lodash 中帶了這兩個庫,可我又不想將整個 lodash 引入,畢竟我僅僅是寫一個小工具,將整個 lodash 打包進去不太合適。
首先想到的就是到社區中有沒有現成的 TS 包,當然是有,但并不完美;社區中有 ts-debounce、throttle-typescript 等 TS 包可以直接拿來使用,只不過它們沒有同時提供這兩個函數,而且其提供的 API 和 lodash 的有出入,使用起來不太順手。(也可能是我自己沒找到正確的 TS 包)
1.2、兩種方案既然如此,只能自己動手解決,有兩種解決方式:
【方案一】使用 webpack 4 的 code split 能力,先整體引入 lodash ,而在打包的時候只將所需要的 debounce 和 throttle 部分打包進入;
【方案二】自己動手將 lodash 中的 debounce 和 throttle 這兩部分代碼 copy 出來形成多帶帶的一個 TS 包
這兩種方案都可行,視具體的情況而定,比如大工程項目中使用【方案一】比較合適;而我這邊因為多個小工具庫都使用到這兩個函數,所以采用【方案二】比較合適;
剩下的問題,就是如何完全快速遷移 lodash 中的 debounce 和 throttle,而且需要保證遷移過來的功能是和 lodash 官方的 API 保持一致 —— 最為保險的操作就是去官方源碼中獲取這兩個函數的源碼,然后將 JS 寫法用 TS 改寫一遍。
2. 動手遷移接下來用簡單的文字記錄下這個遷移過程
2.1、獲取官方源碼lodash 作為廣泛使用的基礎工具庫,它很貼心地提供了自助打包服務,可以定制自己所需要的函數集合,而不用整個引入。
按照官方教程 custom-builds 中的步驟,先安裝 lodash-cli 工具
npm i -g npm npm i -g lodash-cli lodash -h
接著我們只選擇打出 debounce 和 throttle 的功能,直接以 ES 方式打包出結果
lodash modularize exports=es include=debounce,throttle
使用 ES 方式導出必須使用 modularize 模式,獲取的源碼效果如下:所有的 ES 模塊放在 modularize 文件夾下:
2.2、改寫成 TS 成源碼由于打包獲取的都是 JS 源碼,接下來這一步就是將這些代碼改寫成 TS 格式的。
我主要是為了使用 TS 格式,并非那么注重聲明文件的嚴謹性,所以使用了較為寬松的 TS 語法約束,可以參考我的 tsconfig.json 文件。
將源碼經過簡單的改寫整理,盡可能不更改其源碼實現,頂多是調節文件夾結構,最終將源碼結構參考 github 倉庫中的 src 文件夾
2.3、添加單元測試用例為了證明這次遷移和官方原有的功能保持一致,特意找到官方的 test 文件夾 lodash/test 中有關 throttle 和 debounce 的測試用例,將其遷移過來,自檢這兩個函數是否遷移正確
改寫后的單元測試用例放在 倉庫的 test 文件夾中,單元測試覆蓋率如下
這些單元測試用例都是從官方遷移來的,針對 debounce 和 throttle 的覆蓋率都超過 90% 以上;
2.4、最終成果按上面的步驟最終獲取的 TS 化版本,源碼放在 github 上的 github 倉庫 ,同時為方便后續使用也發了 npm 包 包。
通過 npm install ts-debounce-throttle 就能在項目中直接引用使用,親測可正常使用該 TS 包;
3、總結從上面過程來看,這種遷移沒有難度,頂多屬于體力活;
只遷移 debounce 和 throttle 這兩個函數工作量并沒有想象中那么大,不到 1 個小時就搞定了上述整個遷移過程。
最為重要的是,這種遷移方面我們可以隨意自定義 TS 化 lodash 中所需要的工具函數,遷移粒度都可以由自己控制。
如果你也有這方面的需求,不妨按本文的過程親自實踐一番。
在遷移過程中,我順帶閱讀這兩個函數源碼,詳細源碼解讀請參考文章《源碼分析 - lodash 中的 debounce & throttle》
下面的是我的公眾號二維碼圖片,歡迎關注交流。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/105948.html
摘要:最簡單的案例以最簡單的情景為例在某一時刻點只調用一次函數,那么將在時間后才會真正觸發函數。后續我們會逐漸增加黑色鬧鐘出現的復雜度,不斷去分析紅色鬧鐘的位置。 序 相比網上教程中的 debounce 函數,lodash 中的 debounce 功能更為強大,相應的理解起來更為復雜; 解讀源碼一般都是直接拿官方源碼來解讀,不過這次我們采用另外的方式:從最簡單的場景開始寫代碼,然后慢慢往源碼...
摘要:如果我們的回調函數較為復雜,頁面的性能就會變差。而可以保證穩定的時間間隔執行一次回調函數。但需要弄清楚的是,無論是還是,控制的都是回調函數的執行,而不是事件的監聽。 前言 假設現在有個需求:監聽滑動事件,并執行回調。當你用觸摸板或者鼠標滑動頁面時,每秒鐘大概會觸發幾十次scroll事件,而當你在手機等移動終端上滑動頁面時,每秒就會觸發一百次scroll事件。如果我們的回調函數較為復雜,...
摘要:舉例舉例通過拖拽瀏覽器窗口,可以觸發很多次事件。不支持,所以不能在服務端用于文件系統事件。總結將一系列迅速觸發的事件例如敲擊鍵盤合并成一個單獨的事件。確保一個持續的操作流以每毫秒執行一次的速度執行。 Debounce 和 Throttle 是兩個很相似但是又不同的技術,都可以控制一個函數在一段時間內執行的次數。 當我們在操作 DOM 事件的時候,為函數添加 debounce 或者 th...
摘要:自己嘗試一下年在的文章中第一次看到的實現方法。這三種實現方法內部不同,但是接口幾乎一致。如你所見,我們使用了參數,因為我們只對用戶停止改變瀏覽器大小時最后一次事件感興趣。 前幾天看到一篇文章,我的公眾號里也分享了《一次發現underscore源碼bug的經歷以及對學術界拿來主義的思考》具體文章詳見,微信公眾號:showImg(https://segmentfault.com/img/b...
摘要:如果使用的是防抖,那么得等我們停止滾動之后一段時間才會加載新的內容,沒有那種無限滾動的流暢感。這時候,我們就可以使用節流,將事件有效觸發的頻率降低的同時給用戶流暢的瀏覽體驗。調用,瀏覽器會在下次刷新的時候執行指定回調函數。 本文來自我的博客,歡迎大家去GitHub上star我的博客 本文從防抖和節流出發,分析它們的特性,并拓展一種特殊的節流方式requestAnimationFrame...
閱讀 2096·2023-04-26 02:41
閱讀 2152·2021-09-24 09:47
閱讀 1553·2019-08-30 15:53
閱讀 1211·2019-08-30 13:01
閱讀 1892·2019-08-29 11:27
閱讀 2867·2019-08-28 17:55
閱讀 1763·2019-08-26 14:00
閱讀 3392·2019-08-26 10:18