摘要:前端模板的出現(xiàn)使得前后端分離成為可能??偨Y(jié)本文簡單介紹了模板引擎在前后端的使用,下文我們回到,重點分析下的使用方式以及源碼原理。樓主對于模板引擎的認識比較淺顯,有不正之處希望指出感謝
前言
這篇文章本來不打算寫的,實話說樓主對前端模板的認識還處在非常初級的階段,但是為了整個 源碼解讀系列 的完整性,在深入 Underscore _.template 方法源碼后,覺得還是有必要記下此文,為了自己備忘也好,為了還沒用上前端模板引擎的同學(xué)的入門也好。(熟悉模板引擎的可以幫樓主看看文中有沒有 BUG ..)
后端 MVC說起模板渲染,樓主首先接觸的其實并不是前端模板引擎,而是后端。后端 MVC 模式中,一般從 Model 層中讀取數(shù)據(jù),然后將數(shù)據(jù)傳到 View 層渲染(渲染成 HTML 文件),而 View 層,一般都會用到模板引擎,比如樓主項目中用到的 PHP 的 smarty 模板引擎。隨便上段代碼感受一下。
{{foreach from=$pageArray.result item=leftMenu key=key name=leftMenu}}
{{foreach from=$leftMenu key=key2 item=item2}}- {{$key2}}
{{/foreach}} {{/foreach}}
傳入 View 層的其實就是個叫做 $pageArray 的 JSON 數(shù)據(jù)。而 MVC 模式也是非常容易理解,推薦看下阮一峰老師的 談?wù)凪VC模式,然后再看看下面這張圖。
以前的 WEB 項目大多會采用這種后臺 MVC 模式,這樣做有利于 SEO,并且與前端請求接口的方式相比,少了個 HTTP 請求,理論上加載速度可能會稍微快些。但是缺點也非常明顯,前端寫完靜態(tài)頁面,要讓后臺去「套模板」,每次前端稍有改動,后臺對應(yīng)的模板頁面同時也需要改動,非常麻煩。頁面中如果有復(fù)雜的 JS,前端寫還是后端寫?前端寫的話,沒有大量的數(shù)據(jù),調(diào)試不方便,后端寫的話... 所以樓主看到的 PHPer 通常都會 JS。
前端模板AJAX 的出現(xiàn)使得前后端分離成為可能。后端專注于業(yè)務(wù)邏輯,給前端提供接口,而前端通過 AJAX 的方式向后端請求數(shù)據(jù),然后動態(tài)渲染頁面。
我們假設(shè)接口數(shù)據(jù)如下:
[{name: "apple"}, {name: "orange"}, {name: "peach"}]
假設(shè)渲染后的頁面如下:
- apple
- orange
- peach
前端模板引擎出現(xiàn)之前,我們一般會這么做:
其實樓主個人也經(jīng)常這么干,看上去簡單方便,但是這樣做顯然有缺點,將 HTML 代碼(View 層)和 JS 代碼(Controller 層)混雜在了一起,UI 與邏輯代碼混雜在一起,閱讀起來會非常吃力。一旦業(yè)務(wù)復(fù)雜起來,或者多人維護的情況下,幾乎會失控。而且如果需要拼接的 HTML 代碼里有很多引號的話(比如有大量的 href 屬性,src 屬性),那么就非常容易出錯了(這樣干過的應(yīng)該深有體會)。
這個時候,前端模板引擎出現(xiàn)了,Underscore 的 _.template 可能是最簡單的前端模板引擎了(可能還上升不到引擎的高度,或者說就是個前端模板函數(shù))。我們先不談 _.template 的實現(xiàn),將以上的代碼用其改寫。
這樣一來,如果前端需要改 HTML 代碼,只需要改模板即可。這樣做的優(yōu)點很明顯,前端 UI 和邏輯代碼不再混雜,閱讀體驗良好,改動起來也方便了許多。
前后端分離最大的缺點可能就是 SEO 無力了,畢竟爬蟲只會抓取 HTML 代碼,不會去渲染 JS。(PS:現(xiàn)在的 Google 爬蟲已經(jīng)可以抓取 AJAX 了 Making AJAX applications crawlable,具體效果未知)
Node 中間層單純的后端模板引擎(后端 MVC)以及前端模板引擎方式都有一定的局限性,Node 的出現(xiàn)讓我們有了第三種選擇,讓 Node 作為中間層。
具體如何操作?簡單地說就是讓一門后臺語言(比如 Java?PHP?)單純提供渲染頁面所需要的接口,Node 中間層用模板引擎來渲染頁面,使得頁面直出。這樣一來,后臺提供的接口,不僅 Web 端可以使用,APP,瀏覽器也可以調(diào)用,同時頁面 Node 直出也不會影響 SEO,并且前后端也分離,不失為一種比較完美的方案。
總結(jié)本文簡單介紹了模板引擎在前后端的使用,下文我們回到 Underscore,重點分析下 _.template 的使用方式以及源碼原理。
PS:樓主對于模板引擎的認識比較淺顯,有不正之處希望指出~感謝!
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/80708.html
摘要:置換型模板引擎的優(yōu)點實現(xiàn)簡單,缺點效率低,無法滿足高負載的應(yīng)用請求。用途百度詞條模板引擎可以讓網(wǎng)站程序?qū)崿F(xiàn)界面與數(shù)據(jù)分離,業(yè)務(wù)代碼與邏輯代碼的分離,提升開發(fā)效率,良好的設(shè)計也提高了代碼的復(fù)用性。前端模板的出現(xiàn)使得前后端分離成為可能。 模板引擎 模板引擎-百度詞條 什么是模板引擎?(百度詞條) 模板引擎(這里特指用于Web開發(fā)的模板引擎)是為了使用戶界面與業(yè)務(wù)數(shù)據(jù)分離而產(chǎn)生的,它可以生成...
摘要:前后端的界限是按照瀏覽器和服務(wù)器的劃分。前后端彼此互不關(guān)聯(lián)。關(guān)于作者本文部分圖片段落參考文章實踐中的前后端分離。淘寶前后端分離實踐本文源碼詳見服務(wù)端代碼。 一、起源 (故事純屬虛構(gòu),如有雷同,純屬巧合)傳說在很久很久以前,我們有志之士有了個創(chuàng)業(yè)的想法,于是乎開始了自己的創(chuàng)業(yè)之夢,但是人手不足啊,于是乎所有角色老子一個人全包了: Roles: PM, DBA, RD, FED, Des...
摘要:前后端的界限是按照瀏覽器和服務(wù)器的劃分。前后端彼此互不關(guān)聯(lián)。關(guān)于作者本文部分圖片段落參考文章實踐中的前后端分離。淘寶前后端分離實踐本文源碼詳見服務(wù)端代碼。 一、起源 (故事純屬虛構(gòu),如有雷同,純屬巧合)傳說在很久很久以前,我們有志之士有了個創(chuàng)業(yè)的想法,于是乎開始了自己的創(chuàng)業(yè)之夢,但是人手不足啊,于是乎所有角色老子一個人全包了: Roles: PM, DBA, RD, FED, Des...
摘要:但似乎他們的職責(zé)在以前甚至于現(xiàn)在都并不明確,雖然前端是跟瀏覽器打交道,但是最終瀏覽器拿到的頁面是服務(wù)器通過模板生成的一個臨時靜態(tài)頁面而已。當然,一般傳統(tǒng)上的開發(fā)協(xié)作模式有兩種一種是前端先寫一個靜態(tài)頁面,寫好后,讓后端去套模板。隨著不同終端(Pad/Mobile/PC)的興起,對開發(fā)人員的要求越來越高,純?yōu)g覽器端的響應(yīng)式已經(jīng)不能滿足用戶體驗的高要求,往往需要針對不同的終端開發(fā)定制的版本,為了提...
閱讀 2889·2021-09-10 10:51
閱讀 2244·2021-09-02 15:21
閱讀 3244·2019-08-30 15:44
閱讀 921·2019-08-29 18:34
閱讀 1684·2019-08-29 13:15
閱讀 3357·2019-08-26 11:37
閱讀 2723·2019-08-26 10:46
閱讀 1136·2019-08-26 10:26