Hi， 我是 Curt 家人，是 Web 前端工程師

Hi 大家好我是 Curt 家人 系列相關文章 SOLID Principles With React SOLID Principles With React - SRP (單一職責原則) SOLID Principles With React - OCP (開放封閉原則) SOLID Principles Without React - LSP (里氏替換原則) SOLID Principles With React - ISP (介面隔離原則) SOLID Principles With React - DIP (依賴反轉原則) LSP 前言 這篇文章要來介紹不好理解的原則：里氏替換原則，開始讀的時候可能很容易一頭霧水，並且網路上有蠻多 Bird 、 Duck 與 Triangle 的範例，自己看完之後還是有點沒想法， 不過隨著看越多的相關文章，好像就可以慢慢地體會到核心理念，並且要達到他的要求好像也不難。 wiki 的資料中有提到：LSP 在論文內說明 subtyping 的擴充行為與 design by contract 有著相似的概念，因此以下也會將其一起說明。 在開始之前需要提醒一下，因為 LSP 強調的是物件繼承間的問題，也就是子類與父類的繼承關係合不合適，然而 React 的開發風格不需使用繼承，每個 component 只需要 extends React 就好， 因此本篇不會有 React 的範例。...

Hi 大家好我是 Curt 家人 系列相關文章 SOLID Principles With React SOLID Principles With React - SRP (單一職責原則) SOLID Principles With React - OCP (開放封閉原則) SOLID Principles Without React - LSP (里氏替換原則) SOLID Principles With React - ISP (介面隔離原則) SOLID Principles With React - DIP (依賴反轉原則) OCP SOLID 的第二個原則 OCP，中文又稱作開放封閉原則，意思是說 我允許我的 class、module、function 給你擴充，但不允許你修改它 定義上也是這麼說 software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification 我們先來釐清什麼是擴充、什麼是修改 擴充：在原本的功能上擴充一些東西，但別人想用原本的功能也不影響，是可以選擇的。 修改：將核心的邏輯、功能換掉，所有人都會用到同一個功能。 舉個生活中的例子， EX: 機車是用來交通的工具，如果有導航需求自己可以加裝手機架，給其他人騎的時候，如果他覺得不需要可以隨時拆掉，不影響原本的功用。...

Hi 大家好我是 Curt 家人 系列相關文章 SOLID Principles With React SOLID Principles With React - SRP (單一職責原則) SOLID Principles With React - OCP (開放封閉原則) SOLID Principles Without React - LSP (里氏替換原則) SOLID Principles With React - ISP (介面隔離原則) SOLID Principles With React - DIP (依賴反轉原則) SRP 首先來看第一個規則 SRP，中文又叫單一職責原則， 其實從字面上可以很簡單的猜到他要表達的意思， 也就是說每個 module、class 或 function 只需要負責做一件事情就好，不要將太多無關或複雜的邏輯放在裡面。 比如說湯匙就是拿來挖食物的工具，但卻設計成可以挖食物又可以拿來當作吸管喝飲料的東西， 這樣一來如果要將吸管的功能改成可以彎折的效果，那就要考慮到會不會影響湯匙的功能，進而增加他們之間的耦合度。 我們來看一下定義是怎麼描述的 A class should have only one reason to change - Robert C. Martin 中文意思是 每個類別只能有一個可以修改它的理由...

Hi 大家好我是 Curt 家人 系列相關文章 SOLID Principles With React SOLID Principles With React - SRP (單一職責原則) SOLID Principles With React - OCP (開放封閉原則) SOLID Principles Without React - LSP (里氏替換原則) SOLID Principles With React - ISP (介面隔離原則) SOLID Principles With React - DIP (依賴反轉原則) 前言 最近在準備面試時候發現蠻多公司都會問 SOLID 這個題目， 雖然是面後端比較有機會被問到，不過我就在想如果面前端的時候被問到該怎麼回答比較好， 以及是否能夠提出一個合理的範例來沿用到 React 開發上。 Why SOLID SOLID 的概念是 2000 年由 Robert C. Martin 在此篇論文 - Design Principles and Design Patterns 內首次提出，主要是為了讓 物件導向 的程式設計可以有更好的 可讀性、維護性、彈性。...

React Fiber 廣義上可以代表整個新版架構， 而狹義上 Fiber 只是一個 object，這個 object 是 reconciler 藉由 react element 作為模板建立出來。 什麼是 React Element 平常寫 React Component 時，通常會在 render function 裡面使用 JSX 語法，而背後其實只是 JSX compiler 幫我們加入 React.createElement。 例如： render(){ return( <div onClick={() => null}> <div>Hello Element</div> </div> ) } 會被轉成 render(){ return React.createElement( 'div', { onClick: myClick }, React.createElement('div', null, 'Hello Element'); ); } 如果直接將 createElement 的結果 console.log 出來大概會長這樣 { $$typeof: Symbol(react.element), type: "div" key: null props: { children: { $$typeof: Symbol(react....

雖然這個技術已經存在一段時間，但在現今大 Web 時代，若要增進網站的使用者經驗（UX）、效能、程式碼重複使用性……等等，依舊少不了 Code Splitting。 基本上此篇會 follow Webpack 官網上的 Code Splitting - Guild 並加上一些自己的想法來做介紹。 本篇適合給剛使用 Webpack 打包自己專案，並瞭解基本設定的開發者，如果你已熟悉它們的教程，那麼此篇其實可以考慮使用 cmd + w 或是 ctrl + w 進入彩蛋模式 什麼是 Code Splitting ? 從字面上來看 Code Splitting 即為將我們的 code（程式碼）給 Split（拆開），也就是說原本使用 Webpack 的打包出來的檔案，可能只有一個，但透過 Code Splitting 技術之後，可以將這一個檔案變成無數多個。 為什麼要這樣做？ 隨著需求日漸增加的專案，檔案以及資源只會越來越龐大，試想如果你一進到 SWAG Web App ，立刻就載入一份 50 MB 的 JS 檔案會是什麼情況？在網路不穩時可能會導致 Loading 長達 5 ~ 10 秒。 以 UX 來說，正常人類能夠感知到時間的差別為 0.1 秒，如果介於 0.1 秒 ~ 1 秒 之間會被使用者發現有東西正在載入或是運行，但完全可以接受，但如果到了 1 秒 ~ 5 秒 ，使用者會出現焦慮甚至懷疑程式出錯了，更不用提 5 秒之後，大部分使用者可能會選擇離開。...