Angular 8.0 迎來的新 rendering engine：Angular Ivy

近年大約六個月一次的 Angular 重要版本更新很快就要來了！其中最矚目的莫過於Angular v2 第三代的 rendering engine : Angular Ivy ，當中有什麼值得我們留意的？

Angular Ivy 早在 2018 年的 4 月的 Ng-conf 中就公佈了。有新的 rendering engine 出現，官方所強調的都莫過於容量細、速度較快、編碼層面上更簡單。不過，有幾點是 Angular 今次想透過 Ivy 來解決的：

Ivy 為了改善用家體驗，使瀏覽器需要下載的內容更少，從而使應用程式的啟動時間加快。
Ivy 通過簡化 API 和構建系統（build system），幫助開發人員更容易編寫源碼。
Ivy 通過將編譯管道（compilation pipeline）變得更平易近人，使得第三方的開發更為可能，有助 Angular 社區發展。

不過新事物的出現，程式員第一樣關心的事情就是用不用改之前的代碼？答案是：

100% Backwards Compatible！

皆因 Google 本身也有 600+ 個服務都是用 Angular 來編寫，Google 亦不容許當新的 Angular 版本推出時，仍然使用舊的版本，所以 Angular 幾乎不可能做出一個具斷裂性的改變，所以各位程式員請放心使用。

在編碼層面上，Ivy 有幾個重大的更新，其中包括：

Locality
Tree-Shaking
Low Memory Footprint

Locality

「locality」看來是 Angular 開發團隊所提出的新名詞，這裡容許我譯作為局部性。局部性的意思是指當 Angular 的編譯器（compiler）翻譯模板（template）的時候，編譯器只會允許使用對其來說是 屬於該局部（local）的信息，亦即是那些由其 component decorator 與 class 所定義的信息。當需要重新編譯某一組件時，因為不直接關聯的依賴（dependency）不會牽涉在編譯的過程之內，所以就能夠實行累加組建（incremental build），毋須每次都要渲染一整個全新的 virtual DOM tree，重新編譯的時間較短，產生出來的代碼體積亦較小。

Ng-conf 亦提到局部性的其他好處：

允許第三方的 library 將預先編譯好的模板，直接發送到 NPM。對於使用這些 library 的應用程式來說，能夠簡化和加速編譯過程。
AoT / JIT 所產生代碼近乎一樣，使開發、測試時能夠容易地合用這兩種代碼。
metadata.json 消失了，這大大簡化第三方 library 的發佈及開發，以及和現存工具鏈（tool chain）的互用性。
大量減省編譯圖（compilation graph），這能簡化組建工具，重建大型項目的時間亦能縮短。
允許元編程（meta-programming），能夠令 component 可以在執行期（run time）內創建，Higher Order Components 亦能完全實現。

Tree-Shaking

比起大量運用 Virtual DOM 的主流 framework，Ivy 所用的 incremental DOM 更有利於Tree-Shaking。Tree-Shaking 是死碼刪除（Dead code elimination／DCE）的一種，它的用途是移除對程式執行結果沒有任何影響的源碼。不過相對於傳統DCE 只是移除永遠不能執行的代碼，Tree-Shaking 能夠從程式的入口點開始，並且透過靜態程式分析（Static program analysis）來移除不會執行的代碼。上代的 Renderer2 和 Ivy Render 同樣都有運用Tree-Shaking，但 Ivy 將源碼分解為更細小、更原子化的 function，更有利 Tree-Shaking 的運用，從而產生更小的 bundle。

以下的 Angular 特性都是能夠被 Tree-Shaking：

Template syntax
Dependency injection
Content projection
Structural directives
Life cycle hooks
Pipes
Queries
Listeners

譬如上圖的例子，由於只有 someFn被 main 引用，而 unusedFn 沒有，所以最終Ivy Render 編譯出來的bundle 就不會包含unusedFn這個 function了。

但如果 unusedFn 牽涉到條件上的檢查，即使條件最終為false而不會用到unusedFn，Ivy Render 編譯出來的bundle 仍然會保留unusedFn。基於靜態程式分析只會嘗試在不實際運行程式的情況下，找出所需內容，而它通常要假設最壞的情況以確保編譯出來的程式是正確無誤，Ivy Render並不會清楚在 runtime 時該值為何，就會保留unusedFn。所以編寫源碼時就要避免這種情況，不要過份依賴 Ivy Render 的 Tree-Shaking。