前端同構MVC實踐分析
1、同構的概念和意義
1.1、isomorphic 是什么？
isomorphic，讀作［?a?s?’m?：f?k］，意思是：同形的，同構的。
維基百科對它的描述是：同構是在數學對象之間定義的一類映射，它能揭示出在這些對象的屬性或者操作之間存在的關系。若兩個數學結構之間存在同構映射，那么這兩個結構叫做是同構的。一般來說，如果忽略掉同構的對象的屬性或操作的具體定義，單從結構上講，同構的對象是完全等價的。
同構，也被化用在物理、化學以及計算機等其他領域。
1.2、isomorphic java
isomorphic java（同構 js），是指一份 js 代碼，既然可以跑在瀏覽器端，也可以跑在服務端。
圖 1
同構 js 的發展歷史，比 progressive web app 還要早很多。2009 年， node.js 問世，給予我們前后端統一語言的想象；更進一步的，前后端公用一套代碼，也不是不可能。
有一個網站 isomorphic.net，專門收集跟同構 js 相關的文章和項目。從里面的文章列表來看，早在 2011 年的時候，業界已經開始探討同構 js，并認為這將是未來的趨勢。
可惜的是，同構 js 其實并沒有得到真正意義上的發展。因為，在 2011 年，node.js 和 ECMA 都不夠成熟，我們并沒有很好的基礎設施，去滿足同構的目標。
現在是 2017 年，情況已經有所不同。ECMA 2015 標準定案，提供了一個標準的模塊規范，前后端通用。盡管目前 node.js 和瀏覽器都沒有實現 ES2015 模塊標準，但是我們有 Babel 和 Webpack 等工具，可以提前享用新的語言特性帶來的便利。
2、同構的種類和層次
2.1、同構的種類
同構 js 有兩個種類：「內容同構」和「形式同構」。
其中，「內容同構」指服務端和瀏覽器端執行的代碼完全等價。比如：
functionadd（a， b）{returna + b}
不管在服務端還是瀏覽器端，add 函數都是一樣的。
而「形式同構」則不同，從原教旨主義的角度上看，它不是同構。因為，在瀏覽器端有一部分代碼永遠不會執行，而在服務端另一部分代碼永遠不會執行。比如：
functiondoSomething（）{ if（isServer） { // dosomething inserver-side } elseif（isClient） { //dosomething inclient-side }}
在 npm 里，有很多 package 標榜自己是同構的，用的方式就是「形式同構」。如果不作特殊處理，「形式同構」可能會增加瀏覽器端加載的 js 代碼的體積。比如 React，它的 140+kb 的體積，是把只在服務端運行的代碼也包含了進去。
2.2、同構的層次
同構不是一個布爾值，true 或者 false；同構是一個光譜形態，可以在很小范圍里上實現同構，也可以在很大范圍里實現同構。
-function 層次：零碎的代碼片斷或者函數，支持同構。比如瀏覽器端和服務端都實現了 setTimeout 函數，比如 lodash/underscore 的工具函數都是同構的。
-feature 層次：在這個層次里的同構代碼，通常會承擔一定的業務職能。比如 React 和 Vue 都借助 virtual-dom 實現了同構，它們是服務于 View 層的渲染；比如 Redux 和 Vuex 也是同構的，它們負責 Model 層的數據處理。
-framework 層次：在框架層面實現同構，它可能包含了所有層次的同構，需要精心處理支持同構和不支持同構的兩個部分，如何妥善地整合在一起。
我們今天所討論的 isomorphic-mvc（簡稱 IMVC），是在 framework 層次上實現同構。
3、同構的價值和作用
3.1、同構的價值
同構 js，不僅僅有抽象上的美感，它還有很多實用價值。
SEO 友好：View 層在瀏覽器端和服務端都可以運行，意味著可以在服務端吐出 html，支持搜索引擎的抓取。
加快訪問體驗：服務端渲染可以加快瀏覽器端的首次訪問的渲染速度，而瀏覽器端渲染，可以加快用戶交互時的反饋速度。
代碼的可維護性：同構可以減少語言切換的成本，減小代碼的重復率，增加代碼的可維護性。
不使用同構方案，也可以用別的辦法實現前兩個的目標，但是別的辦法卻難以同時滿足三個目標。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%