面對需要修改數百個文件的代碼遷移，你還在手動一個個改嗎？今天介紹一款能讓代碼批量重構像查找替換一樣簡單的工具 —— Grit。 為什麼需要 Grit 作為開發者，我們經常遇到這樣的場景： 團隊決定統一使用 lodash-es 替代 lodash，需要修改幾百個 import 語句 項目要從 React 類組件遷移到 Hooks，涉及上千個組件 某個廢棄的 API 需要全面替換，但調用位置散
在 Web 開發中，前端資源的大小直接影響用户體驗。大型模板文件不僅佔用帶寬，還會延長頁面加載時間。雖然市面上有很多 HTML 壓縮工具，但對於使用了模板引擎的 HTML 文件（如 Askama、Jinja2 等），通用壓縮器往往會破壞模板語法。 於是個人寫了一個 Askama 模板壓縮工具 askama-minify，專門用於壓縮 Askama 模板文件，同時完美保留模板語法。 Askama 為
Million.js 是一個非常快速和輕量級的 ( 4kb) 虛擬 DOM。框架可以通過包裝 React 組件來提升性能（該框架目前版本只兼容 React 18 及以上版本）。 先説結論：Million.js 適應的場景極其有限，但在特定場景下也大放異彩。 如何使用 Million.js 集成 React 中使用非常簡單。先進行安裝和編譯器配置。 安裝與配置 npm install million
目前來説，無論是 to c 業務,還是 to b 業務，對於前端開發者的要求越來越高，各種絢麗的視覺效果，複雜的業務邏輯層出不窮。針對於業務邏輯而言，貫穿後端業務和前端交互都有一個關鍵點 —— 狀態轉換。 當然了，這種代碼實現本身並不複雜，真正的難點在於如何快速的進行代碼的修改。 在實際開發項目的過程中，ETC 原則，即 Easier To Change，易於變更是非常重要的。為什麼解耦很好？ 為
對於企業應用來説，完全不涉及到併發的問題，基本是不可能的。因為對於一個應用中很多的事情都是同時進行的。併發可能發生在數據獲取，服務調用乃至於用户交互中。併發問題有兩個重要的解決方案，一個是隔離，另一個是不變性。 併發問題會發生在多個執行單元同時訪問同一資源的時候，此時，一個好的方法就是分好“蛋糕”，讓每一個執行單元都能訪問到各自的資源。好的併發設計就是：找到創建好隔離區的辦法，然後通過分析工作流讓
三年前，我接觸了 Immutable 庫，體會到了不可變數據結構的利好。 Immutable 庫具有兩個最大的優勢: 不可修改以及結構共享。 不可修改(容易回溯，易於觀察。減少錯誤的發生) let obj = { a: 1 }; handleChange(obj); // 由於上面有 handleChange，無法確認 obj 此時的狀態 console.log(obj) 結構共享(
中介模式定義了一個單獨的（中介）對象，來封裝一組對象之間的交互。將這組對象之間的交互委派給與中介對象交互，來避免對象之間的直接交互。 在實際的項目中，程序由許多對象組成，對象間的交流錯綜複雜。 隨着應用程序的規模增大，對象越來愈多，他們之間的關係也越來複雜。對象間很容易出現相互引用而導致程序無法運行。同時開發者需要改變或者刪除某一個對象時候，需要查找並且改造所有引用到它的對象。這樣一來，改造的成
緩存是提升 web 應用程序有效方法之一，尤其是用户受限於網速的情況下。提升系統的響應能力，降低網絡的消耗。當然，內容越接近於用户，則緩存的速度就會越快，緩存的有效性則會越高。 之前個人寫過 前端 api 請求緩存方案。介紹的了內存中的緩存以及過期邏輯。後續也寫過 手寫一個前端存儲工具庫，該工具利用了適配器處理了不同的存儲介質（內存，IndexedDB, localStorage 等）。 不過，在
Signals 在目前前端框架的選型中遙遙領先！ 國慶節前最後一週在 Code Review 新同學的 React 代碼，發現他想通過 memo 和 useCallback 只渲染被修改的子組件部分。事實上該功能在 React 中是難以做到的。因為 React 狀態變化後，會重新執行 render 函數。也就是在組件中調用 setState 之後，整個函數將會重新執行一次。 React 本身做不到
PinMe 簡介 什麼是 PinMe？ PinMe 是一個免費的 IPFS 託管平台，專為靜態網站部署設計。它能讓開發者在幾秒鐘內將網站部署到 IPFS 網絡上，確保內容的持久性和抗審查能力。 PinMe 的核心價值是提供簡單、快速、免費的前端部署體驗，讓開發者專注於內容創作。 為什麼選擇 PinMe？ 相比傳統託管服務，PinMe 具有以下優勢： 完全免費：無需支付服務器費用或訂閲費用 去
在 JavaScript 開發中，定時器是常用的異步編程工具。然而，原生的 setTimeout 和 setInterval 存在一個鮮為人知的限制：它們無法處理超過 24.8 天的定時任務。 對於前端開發來説，該限制不太會出現問題，但是需要設置超長定時的後端應用場景，如長期提醒、週期性數據備份、訂閲服務到期提醒等，這個限制可能會導致嚴重的功能缺陷。 JavaScript 定時器的限制 原理 Ja
在前端開發中，開發者通常會使用 localeCompare 來進行中文字符的排序比較。但 localeCompare 還有一種較為少見的應用場景 —— 通過獲取中文字符的拼音首字母來實現檢索功能。本文將詳細介紹這一實用技巧及其應用。 原理 localeCompare 方法允許字符串按特定語言環境的排序規則進行比較。在中文環境下，它會默認按照漢字的拼音順序進行排序。基於這一特性： 準備一組具有代
眾所周知，MySQL 的 InnoDB 存儲引擎使用了 B+ 樹作為索引實現，那麼為什麼不使用其他的數據結構呢？數組、鏈表或者哈希表。實現存儲引擎究竟需要什麼條件呢？ 我們現在先以存儲最簡單的數據為例，這裏的數據類似於 json 對象。有 key 和 value。 { "0": "value1", "1": "value2" } 最簡單的存儲引擎必須實現以下三個方法： rea
