
Schematics 是 Angular CLI 用來產生程式碼骨架的基礎,在接下來的幾篇文章中,我會分享如何使用 Schematics 來幫助專案或團隊產生一些必要的重複程式碼,以及一些個人在使用上的經驗及技巧。
今天就先來簡單介紹一下到底什麼是 Schematics 與基本的觀念吧!
有在使用 Angular 開發程式的朋友想必都知道,我們可以使用 Angular CLI 來快速產生許多基礎的程式碼,這些程式碼是必要的,但手動產生卻是很無聊的一件事情,而透過 Angular CLI,我們能輕易的將這些動作自動化,不僅節省時間,也能避免不小心的人為疏失。
而 Schematics 就是 Angular 團隊開發出來方便我們自行定義程式碼產生規則的架構,Angular CLI 也是基於這個架構來幫助我們快速產生程式碼的。
雖然一直都說 Schematics 是「程式碼產生器」,但我覺得更貼切的說法是「變更檔案系統的架構」;而所謂的變更檔案系統,說穿了就是幫助我們新增/修改/刪除檔案的行為,也因此,其實 Schematics 不僅僅是幫助我們「產生程式碼」,只要是跟變更檔案相關的行為,都是 Schematics 可以運用的情境。
以我自己的例子來說,最近有一個跟客戶一起合作開發的專案,由於開發到中期決定有個架構需要調整,這個調整會導致數百的地方需要作出對應的轉換,且許多正在開發中的分支未來也需要作出對應修正;這時候我們就決定使用 Schematics 架構來寫一隻程式來針對原始碼中有需要調整的部分做進行檢查與修正,最終完成了整個架構的調整,同時正在開發中的分支合併回主線時,只需再次執行一次同樣的程式,即可完成所有架構異動需要的修正!
對於變更檔案系統內容,其實我們也能使用 node.js 提供的相關 API 來處理,那麼使用 Scheamtics 的優勢到底有什麼呢?個人認為主要有兩個好處:
今天我們先把基本但重要的名詞及相關行為解釋一下,之後在實際看程式碼時,會比較知道發生了什麼事情。
Schematics 是一個「產生器」,用來根據我們的指令進行檔案系統的變更,且沒有副作用。
用來說明有哪些 Schematics 及有哪些重要相關資訊的檔案。
Tree 是使用 Schematics 時最重要的觀念之一,在撰寫 Schematics 程式碼時,我們目前要異動的檔案系統來源使用一個 Tree (也就是將檔案系統想像成一個樹狀結構) 來表示,而這時候所有的檔案異動都是針對 Tree 來異動,因此不會真正異動到檔案系統,等到一切就緒時,再將異動結果一次影響到真正的檔案系統上,達到沒有副作用的目標!
請記得,撰寫 Schematics 時所有的行為都是針對 Tree 來做異動!
如下圖:假設我們起始要異動的檔案系統包含了一個 src
目錄,此目錄下還有 A.txt
和 B.txt
兩個檔案,我們可以輕易的想像成有一個如下的樹狀結構,是我們即將要變更的來源:
實際上對 Tree 操作的行為,如新增檔案等等,也是真正異動檔案系統的主要行為。
下圖說明一個 delete
的 Action,目的是將某個檔案移除:
將一個 Tree 轉換成另一個 Tree 的行為,其實就是一個函式 (function),整個架構會將目前的 Tree 傳入,我們可以在函式內透過 Action 設計相關的異動行為,來產生並回傳另外一個新的 Tree。
除此之外,由於 Rule 本身就是一個傳入與傳出 Tree 的函式,因此我們也能輕易的組合各種 Rule 來完成一連串複雜的行為。
當我們說在撰寫 Schematics 程式時,其實幾乎都是在設計 Rule。
如下圖,整個實際上將某個 Tree 變成另外一個 Tree 的行為,即稱作 Rule
除了異動代表目前檔案系統的 Tree 以外,我們也可以直接跟另外一個來源結構合併,通常這個來源就稱為 Source。
如下圖:我們將 Tree 與另外一個 Source 使用 merge 的方式,在一個 Rule 內進行異動
Source 也是一個回傳 Tree 的函式,不同在於它並不是將目前的檔案檔案系統 (Tree) 作轉換,而是有其他來源。未來實作練習時我們再來說明。
除此之外還有一些名詞,但相對遇到或使用的頻率比較少,或是不了解對於開發也不會有太大的影響,因此就不多做說明,請直接參考 Schematics 的名詞表。
今天我們大致說明了 Schematics 的功能及相關名詞和觀念,下一篇文章讓我們實際來建立一隻 Schematics 程式,看看到底怎麼撰寫 Schematics 程式碼,以及到底會發生什麼樣的事情。