關於模板引擎一

前端模板引擎需要有開發時的透明性

透明性即指我在搭建好開發環境後，隨手寫代碼隨手刷新瀏覽器就能看到最新的效果，而不需要額外地執行任何命令或有任何的等待過程。

所以一切依賴編譯過程的模板引擎並不適合前端使用，編譯只能是模板引擎的一個特性，而不能是使用的前提

更嚴格地說，使用FileWatch等手段進行文件變更檢測並自動編譯也不在我的考慮範圍之內，因為這會造成額外的等待，

由此可以推出，前端的模板引擎應該是具備可在純前端環境中解析使用的能力的。

前端模板引擎要有良好的運行時調試能力

由於用戶行為的不確定性、執行環境的不確定性、各種第三方腳本的影響等，前端很難做到完全的錯誤處理和跟蹤，這也導致前端必然存在需要直接線上上排查問題的情況

而當問題出現在模板引擎這一層時，就需要模板引擎提供良好的調試能力

一般來說，編譯後生成的函數的調試能力是弱於原先手動編寫的模板片斷的，因為自動生成的函數基本不具備可讀性和可斷點跟蹤性

因此在這一點上，一個供前端使用的模板引擎應該具備在特定情況下從“執行編譯後函數獲取HTML”換回“解析原模板再執行函數獲取HTML”的模式，即應該支持在兩種模式間切換

或者更好地，一個強大的前端模板引擎編譯生成的函數，可以使用Source Map或其它自定義的手段直接映射回原模板片段，不過現在並沒有什麼模板引擎實現了這一功能

前端模板引擎要對文件合併友好

在提供編譯功能的模板引擎中，我們可以使用編譯的手段將模板變為JavaScript源碼，再在JavaScript的基礎上做文件合併

但是如果我們出於上文所說的調試能力等原因希望保留原模板片段，那就需要模板引擎本身支持模板片段合併為一個文件了

大部分僅支持將一段輸入的字元串作為模板解析的引擎並不具備這一能力，他們天生並不能將一整個字元串切分為多個模板片段，因而無法支持模板片段層面上的文件合併

需要實現對文件合併的支持，最好的辦法就是讓模板的語法是基於“片段”的

前端模板引擎要擔負XSS的防範

從安全性上來說，前端對XSS的控制是有嚴格要求的

前端對XSS的防範比較合適的方法是使用“預設轉義”的白名單式策略

基於此，一個合理的模板引擎是必須支持預設轉義的，即所有數據的輸出都預設經過escape的邏輯處理，將關鍵符號轉為對應的HTML實體符號，以從根源上杜絕XSS的入侵路徑

當然並不是所有的內容都必須經過轉義的，在系統中免不了有對用戶輸入富文本的需求，因此需要支持特定的語法來產生無轉義的輸出，但時刻註意無轉義輸出才是特例，預設情況下必須是轉義輸出的

前端模板引擎要支持片段的復用

1. 一個片段可以被引入到另一處，相當於一個變數到處用的效果
2. 一個片段被引入時，可以向其傳遞不同的數據，相當於一個函數到處用的效果
3. 一個片段可以被外部替換，但外部不提供此片段的話保持一個預設的內容，類似設計模式中的策略模式

滿足第1和第2點的模板引擎並不少，而滿足第3點的前端模板引擎卻不多見，而後端的Razor、Smarty等都具備這一功能

前端模板引擎要支持數據輸出時的處理

所謂數據輸出時處理，指一個數據要在輸出時做額外的轉換，最常見的如字元串的trim操作，比較技術性的如markdown的轉換等

誠然數據的轉換完全可以在將數據交給模板引擎前就通過JavaScript的邏輯處理完，但這會導致不少有些醜陋又有些冗餘的代碼，對邏輯本身的復用性也會造成負面的影響

通常模板引擎對數據做額外處理會使用filter的形式實現，類似bash中的管道的邏輯。filter的實現和註冊也會有不同的設計，如mustache其實註冊的是fitler工廠，而另一些模板引擎則會直接註冊filter本身，不同設計有不同的考量點，我們很難說誰好誰壞 

但是，模板引擎支持數據的輸出處理後，會另我們在編碼過程中產生一個新的糾結，即哪些數據處理應該交由模板引擎的filter實現，哪些應該在交給模板引擎前由自己的邏輯邏輯實現。這個話題展開來又是一篇長長的論述，於當前的話題無關就略過吧

前端模板引擎要支持動態數據

在開發過程中，其實有不少數據並不是靜態的，如EmberJS就提供了Computed Property這樣的概念，Angular也有類似的東西，Backbone則可以通過重寫Model的get方法來變相實現

雖然ES5在語言層面上直接提供了getter的支持，但我們在前端開發的大部分場景下依舊不會使用這一語言特性，而會選擇將動態的數據封裝為某種對象的get等方法

而模板引擎在將數據轉為HTML片段的過程中，同樣應該關註這一點，對這些動態計算的數據有良好的支持

說得更明白一些，模板引擎不應該僅僅接受純對象（Plain Object）作為輸入，而應該更開放地接受類似帶有get方法的動態的數據

一個比較合理的邏輯是，如果一個對象有一個get方法（模板引擎決定這個介面），則數據通過該方法獲取，其它情況下視輸入的對象為純對象（Plain Object），使用標準的屬性獲取邏輯

前端模板引擎要與非同步流程嚴密結合

• 模板的輸出本身成了非同步的方法，而不再像現在一樣直接返回字元串
• 分析模板對非同步操作的依賴，整個字元串的拼接邏輯被打斷成多個非同步
• 非同步是需要等待的，且等待是未知的，從性能上考慮，是否需要考慮Stream式的輸出，以便完成一段提供一段
• 是提供內置的固定幾種非同步邏輯，還是基於Promise支持任何自定義的非同步邏輯，在複雜度和實用性上作出平衡

至今我還沒有完全明確模板與非同步結合的方式和介面，這個話題也沒辦法繼續深入探討了

前端模板引擎要支持不同的開發模式

• 最普通的HTML頁面，使用DOMContentLoaded等事件添加邏輯，特定交互下局部刷新頁面
• 採用傳統的MVC模型進行單頁式開發
• 使用MVVM方式以數據為核心，數據與視圖方向綁定進行開發
• 基於Immutable Data進行數據比對Diff轉DOM更新的開發（其中可能有Virtual DOM的引入）

• 能夠從模板中提取“這一模板對哪些數據有依賴”的元信息
• 能夠知道一個數據變化引擎的是模板的哪一塊，而不至於整個刷新

而通用模板引擎很少提供這兩個特性，所以沒辦法對不同的前端開發模式進行全面到位的支持
從模板引擎本身的實現上來說，一種方法是直接將模板解析後的類似AST的結構暴露出去，供其他框架合理地處理，同時提供對模板局部的刷新功能（也可與前面所說的模板片段一起考慮），但是大部分模板引擎為了性能等考慮，是不會解析出類似AST的語法結構來的

前端模板引擎要有實例間的隔離

在大型的前端項目，特別是單頁式的項目中，會有完全未知個數的模板片段同時存在，如果這些片段是帶有名稱（出於復用的考慮）的，就很容易造成名稱上的衝突

對於同一層級的邏輯（如大家都是業務層代碼，或者大家都是控制項層代碼），名稱衝突是可以通過一些開發時的約定來解決的。但不同層之間，由於封裝性的要求，外部不應該知道一些僅內部使用的片段的名稱，此時如果不幸有名稱與其它層有衝突，會讓情況變得比較麻煩，這類問題甚至都不容易跟蹤，往往會導致大量的精力和時間的浪費

因此，一個好的模板引擎應該是多實例的，且不同實例間應該相互具備隔離性，不會出現這種不可預期的衝突

將這個話題再往深地研究，就會發現單純的隔離是不夠的，不同層間除了不衝突的需求，同樣還有片段復用的需求，我們還會需要不同模板實例間可以開放一些固定的片段共用，因此模板引擎各個實例的關係是一種組合依賴但又具備基本的封裝和隔離的狀態說了這麼多。