繼承是javascript中實現代碼複用的一種方式，也能綁定對象或者函數之間的關係 為什麼要繼承 比如以下代碼，Person、Student和Teacher構造函數，可以發現他們有一些特徵 Person和Student都有姓名、年齡的屬性和吃的方法，但Student還有學號、分數的屬性和學習的方法 Person和Teacher都有姓名、年齡的屬性和吃的方法，但Teacher還有教學的方法
定義 類是構造函數、原型鏈的語法糖。 定義類有兩種方式 class Student { } var Student = class { } 某些瀏覽器可能無法解析es6及以上的語法，這時候需要通過babel將代碼解析成瀏覽器可識別的語法，定義類的語法通過babel編譯之後就是通過function定義的構造函數。 類和構造函數是一樣的，通過new關鍵字創建，具有prototype屬性 class
webStorage 基本概念 webStorage提供了兩種存儲方式，localStorage和sessionStorage。 localStorage是持久化存儲，不主動刪除存儲的內容會永久存在 sessionStorage為會話級存儲，關閉瀏覽器則銷燬 具體的區別在於 關閉網頁後重新打開，localStorage會保留，sessionStorage不會被保留 在頁面內實現跳轉，
javascript中對象由key和value組成，key是標識符，value可以為任意類型 創建對象的方式 1、通過構造函數 var obj = new Object() obj.name = 'alice' obj.age = 18 2、通過字面量 var obj = { name: 'alice', age: 18 } 屬性描述符 對屬性進行精準的操作，比如定義屬性是否可被刪除、遍歷或修
目前，前端開發已經離不開由 CommonJS、ES Modules 和 Webpack 構建的模塊化開發環境。無論是 JavaScript、CSS、圖片還是其他資源，都可以作為一個模塊來處理。那麼，模塊化究竟是如何發展到今天的呢？ 全局函數模式 最初的前端模塊化嘗試是通過 全局函數來實現的。例如，在一個 util.js 文件中定義了一個變量 count 和一個工具函數 formatNumberWi
為什麼要使用this 在javascript中，this可謂是無處不在，它可以用來指向某些元素、對象，在合適的地方使用this，能讓我們減少無用代碼的編寫 varuser={ name:"aclie", sing:function(){ console.log(user.name+'在唱歌') }, dance:function(){ console.log(user.name+'在跳舞') },
call、bind、apply都是Function原型上的方法，用於改變this的指向 自定義函數 js中的call、bind、apply是用c++代碼實現的，我們這裏使用js代碼做一個模式，沒有把所有的邊界情況考慮進來，僅做一個簡單的實現，三個函數在使用的時候有一些需要注意的地方，在定義的時候需要把這些情況考慮進去 當傳入的值是基本數據類型時，call、apply、bind方法會將它轉變成引
在上一篇測試指南中，我們介紹了Jest 的背景、如何初始化項目、常用的匹配器語法以及鈎子函數的使用。這一篇篇將繼續深入探討 Jest 的高級特性，包括 Mock 函數、異步請求的處理、Mock 請求的模擬、類的模擬以及定時器的模擬、snapshot 的使用。通過這些技術，我們將能夠更高效地編寫和維護測試用例，尤其是在處理複雜異步邏輯和外部依賴時。 Mock 函數 假設存在一個 runCallBac
在現代軟件開發中，創建 定製化的命令行工具(CLI) 已成為滿足公司業務需求的關鍵一環。這類工具可以輔助執行諸如代碼檢查、項目初始化等任務。為了提高開發效率並簡化維護過程，我們將功能模塊化，並通過多個子包來組織這些功能。本文將介紹如何使用 Lerna 來管理一個多包項目，並基於 Commander 實現一個基礎的 CLI 腳手架框架。 初始化：創建入口文件 項目結構 我們以 ice-basic-c
通過 webpack 命令編譯源代碼時，如果我們對源代碼進行了修改，需要重新執行命令才能看到編譯後的效果。 這樣在開發中非常的影響效率，如果存在一種方式，當文件被修改時，webpack 自動監聽重新編譯，並反饋給開發者，這樣就能更高效的進行開發。 watch 我們通過 webpack 執行命令時，編譯完成之後進程會停止，而 webpack --watch 編譯完成後，不會停止進程，並且當文件內容發
事情的起因是這樣的，在一個已上線的項目中，其中一個包含登錄和獲取菜單的接口因響應時間較長，後端讓我嘗試未經服務轉發的另一域名下的新接口，舊接口允許跨域請求，但新接口不允許本地訪問（只允許發佈測試/生產的域名訪問）。 問題 那麼問題來了，本地環境該如何成功訪問到新的接口並驗證業務功能是否生效呢？ 嘗試過程 我首先就想到了直接在 webpack 項目中配置 devServer，並且修改接口地址
公司項目一般都是使用集團封裝好的腳手架，腳手架內部實現咱看不到也摸不着，好不容易組內推行新的UI框架，需要自行定義 webpack 配置，這可是個絕佳的好機會，我對配置過程進行了梳理，把商業項目的成熟配置小跑着送上。 初始化 首先新建一個空文件夾，執行 npm init 初始化生成 package.json 文件。 創建 src 文件夾，項目的業務代碼都放在這裏，再創建 index.js，這是項目
gulp 是一個使用“流”來實現自動化的工具，正如 官方文檔 首頁展示的這副動圖一樣，以“流動”的狀態去處理 TypeScript、PNG、Markdown 資源。 與webpack比較 類別 webpack gulp 核心理念 module bundler task runner 執行任務 模塊化
gulp 一般用於處理自動化任務，默認情況無法處理模塊化，也不會用於大型項目，但它可以使用各種插件來編譯 html、css、js 等資源。 不清楚如何使用 gulp 開啓任務的朋友可以參考 gulp使用指南 處理html 處理 html 資源使用到 gulp-htmlmin 這個插件，和 webpack中使用到的html-webpack-plugin 比較相似。 // gulpfile.js co
因歷史遺留原因，接手的項目沒有代碼提醒/格式化，包括 eslint、pretttier，也沒有 commit 提交校驗，如 husky、commitlint、stylelint，與其期待自己或者同事的代碼寫得完美無缺，不如通過一些工具來進行規範和約束。 eslint eslint 是一個代碼校驗工具，用來規範項目代碼風格。 初始化 通過 npm install eslint 後使用 npx esl
在日常的前端開發中，我們常常藉助各種基於 Node.js 的腳手架工具來加速項目搭建和維護，比如 create-react-app 可以一鍵初始化一個 React 項目，eslint 則幫助我們保持代碼的整潔和一致。而在公司內部，為了更好地滿足特定業務的需求，我們往往會構建自己的腳手架工具，如自定義的 React 或 Vue 框架、內部使用的代碼檢查工具等。本篇文章來和大家分享一下如何用 Node
在日常的前端開發工作中，我們經常依賴各種命令行工具來提高效率和代碼質量。例如，create-react-app 和 eslint 等工具不僅簡化了項目的初始化過程，還能自動執行代碼檢查和格式化任務。當我們使用這些工具時，它們通常會通過一系列互動式的問答來收集必要的信息，從而根據我們的選擇進行相應的配置和安裝。 以 eslint 工具為例（如下圖所示），當你首次運行 eslint --init 命令
需求背景 主管和其他同事基於公司的業務特點，開發了一套自研前端框架。技術選型是 React + JavaScript 的組合，上線後表現還不錯。現在他們想把這個組件庫推廣到其他團隊使用，所以讓我琢磨一下：怎麼能讓使用者用得更順手一點？尤其是能不能在寫代碼的時候有自動提示？ 我調研了一下市面上常見的幾種方案，大致有以下幾類： 把整個項目從 JavaScript 重構為 TypeScript，這樣
項目背景 最近我們團隊自研了一個基於 React 的 H5 前端框架，領導讓我來負責編寫框架的使用文檔。我選擇了 dumi 來搭建文檔站點，大部分內容都是手動寫 Markdown 來介紹各種功能，包括：初始化、目錄結構、生命週期、狀態管理、插件系統 等等。 框架裏有個很重要的子包，主要負責多個 App 的橋接能力，深度集成了各端環境的監測和橋接邏輯。這個子包對外提供了一個 App 實例對象，裏面封
為什麼我們需要測試？ 我們的 React+TypeScript 業務組件庫已經穩定運行了一段時間，主要承載各類UI展示組件，如卡片、通知等。項目初期，迫於緊張的開發週期，我們暫時擱置了自動化測試的引入。當時團隊成員對組件邏輯瞭如指掌，即便沒有測試也能遊刃有餘。 然而隨着時間推移，問題逐漸顯現。當新成員加入或老組件需要迭代時，我們常常陷入兩難：修改代碼可能破壞原有功能，但不修改又無法滿足新需求。特別
隨着JavaScript在前後端開發中的廣泛應用，測試已成為保證代碼質量的關鍵環節。 為什麼需要單元測試 在我們的開發過程中，經常需要定義一些算法函數，例如將接口返回的數據轉換成UI組件所需的格式。為了校驗這些算法函數的健壯性，部分開發同學可能會手動定義幾個輸入樣本進行初步校驗，一旦校驗通過便不再深究。 然而，這樣的做法可能會帶來一些潛在的問題。首先，邊界值的情況往往容易被忽視，導致校驗不夠全面，
平時我除了業務需求，偶爾會投入到UI組件的開發中，大多數時候只會負責自己業務場景相關或者一小部分公共組件，極少有從創建項目、集成可視化、測試到發佈的整個過程的操作，這篇文章就是記錄組件開發全流程，UI組件在此僅作為調試用，重點在於集成項目環境。 組件 我們使用 React + TypeScript 來開發UI組件庫，為了簡化 webpack 環境和 Typescript 環境配置，這裏直接使用 c
功能描述 產品要求在h5頁面實現集錨點、吸頂及滑動高亮為一體的功能，如下圖展示的一樣。當頁面滑動時，內容區域對應的選項卡高亮。當點擊選項卡時，內容區域自動滑動到選項卡正下方。 佈局設計 css 佈局 為了更清晰的描述各功能實現的方式，將頁面佈局進行了如下的拆分。 ★ 最外層的元素定義為 contentWrap，是使用 Intersection 定義的觀察根元素。 ★ 所有可縱向滑動的元素包
背景介紹 我們存在着大量在PC頁面通過表格看數據業務場景，表格又分為兩種，一種是 antd / fusion 這種基於 dom 元素的表格，另一種是通過 canvas 繪製的類似 excel 的表格。 基於 dom 的表格功能豐富較為美觀，能實現多表頭、合併單元格和各種自定義渲染（如表格中渲染圖形 / 按鈕 / 進度條 / 單選框 / 輸入框），以展示為主，不提供圈選、整列複製等功能。 canv
