資訊專欄INFORMATION COLUMN
摘要：正文在年，框架的選擇并不少。特別的，通過思考這些框架分別如何處理狀態(tài)變化是很有用的。本文探索以下的數(shù)據(jù)綁定，的臟檢查的虛擬以及它與不可變數(shù)據(jù)結(jié)構(gòu)之間的聯(lián)系。當狀態(tài)產(chǎn)生變化時，只有真正需要更新的部分才會發(fā)生改變。
譯者言
近幾年可謂是 JavaScript 的大爆炸紀元，各種框架類庫層出不窮，它們給前端帶來一個又一個的新思想。從以前我們用的 jQuery 直接操作 DOM，到 BackboneJS、Dojo 提供監(jiān)聽器的形式，在到 Ember.js、AngularJS 數(shù)據(jù)綁定的理念，再到現(xiàn)在的 React、Vue 虛擬 DOM 的思想。都是在當前 Web 應(yīng)用日益復雜的時代，對于如何處理「應(yīng)用狀態(tài)」與「用戶界面」之間如何更新的問題，帶來更先進的解決方案。
本文是一篇從技術(shù)上，以數(shù)據(jù)變更和UI同步為方向，循序漸進的講述 JavaScript 框架如何演進過來的。
本篇文章，給了我一個更加高緯度的視角，來看待 JavaScript 這些個框架。
正文在 2015 年，JavaScript 框架的選擇并不少。在 Angular，Ember，React，Backbone 以及它們眾多的競爭者中，有足夠多的選擇。
雖然可以通過不少方面來對比這些框架的不同，但是最讓人感興趣的是它們分別如何管理狀態(tài)（state）的。特別的，通過思考這些框架分別如何處理狀態(tài)變化是很有用的。它們都提供了什么樣的工具讓你把這些變化呈現(xiàn)給用戶？
如何處理應(yīng)用狀態(tài)（app state）與用戶界面（user interface）之間的同步，長期以來都是用戶界面開發(fā)如此復雜的主要原因?，F(xiàn)在，我們有幾個不同的處理方案。本文探索以下：Ember 的數(shù)據(jù)綁定，Angular 的臟檢查、React 的虛擬DOM以及它與不可變數(shù)據(jù)結(jié)構(gòu)（immutable data structures）之間的聯(lián)系。
數(shù)據(jù)映射 Projecting Data我們首先討論程序內(nèi)部的狀態(tài)與屏幕所看到的內(nèi)容之間的映射。你把各種諸如 object，arrays，strings，以及 numbers 轉(zhuǎn)換成一顆由諸如 texts、forms、links、buttons 和 images 組成的樹狀結(jié)構(gòu)。在 Web 中，前者通常指 JavaScript 中的數(shù)據(jù)結(jié)構(gòu)，而后者指的是 DOM （Document Object Model）
我們經(jīng)常稱這個過程為渲染（rendering），你可以想象這個過程是從數(shù)據(jù)模型到用戶界面的一個映射。當你把數(shù)據(jù)渲染成一個模板，你得到的是一個 DOM（或者說 HTML）。
這個過程本身已經(jīng)足夠簡單了，數(shù)據(jù)模型到用戶界面之間的映射，并不總是那么的瑣碎。它基本只是一個接受輸入然后直接輸出的函數(shù)。
在我們需要考慮數(shù)據(jù)開始隨著時間而變化的時候，這件事就變得更有挑戰(zhàn)性了。當用戶進行操作或者其它某些操作導致數(shù)據(jù)產(chǎn)生變化的時候，用戶界面需要呈現(xiàn)出這些變化。而且，由于重新構(gòu)建 DOM 樹的代價是極其昂貴的，我們要盡可能產(chǎn)生小的影響。
因為狀態(tài)產(chǎn)生了變化，這比只是一次性渲染用戶界面變得更加難。這就到了以下解決方案開始表演的時候了。
服務(wù)器渲染 Server-Side Rendering宇宙是永恒不變的，沒有任何變化
在 JavaScript 新紀元之前，你的 Web 應(yīng)用的任何交互都會觸發(fā)一趟服務(wù)器的環(huán)繞旅行。每一個點擊和每一個表單提交都會卸載當前頁面，一個請求發(fā)送到服務(wù)器，服務(wù)器響應(yīng)一個新的頁面，然后瀏覽器重新渲染。
這種方式不需要前端管理任何的狀態(tài)（state）。就前端范疇而言，當一些事情發(fā)生了(后端返回的數(shù)據(jù))，整個過程就結(jié)束了。就算有狀態(tài)，那也只是后端的范疇。前端只是由 HTML 和 CSS 構(gòu)成，也許有時候會有些 JavaScript 撒在表面調(diào)味。
從前端來說，這是一個很簡單的實現(xiàn)方式，但也是一個很慢的方式。每一個交互并不僅僅觸發(fā)UI的重渲染，還涉及服務(wù)器的數(shù)據(jù)查詢以及服務(wù)端渲染。
大多數(shù)人已經(jīng)不再這樣做了，我們可以在服務(wù)器端初始化我們的應(yīng)用，然后轉(zhuǎn)移到前端來做狀態(tài)的管理（這也是 isomorphic JavaScript 致力于的。）。已經(jīng)有人在類似的更復雜的設(shè)計思想中取得成功。
JS第一代革命：手動重渲染我不知道哪些需要渲染的，你來告訴我。
第一代革命的 JavaScript 框架，如：Backbone.js, Ext JS 以及 Dojo。第一次在瀏覽器端引入了數(shù)據(jù)模型（Data Model）的概念，代替了以前那些直接操作 DOM 的輕量級的腳本代碼。這意味著你終于可以在瀏覽器端管理狀態(tài)了。當數(shù)據(jù)模型的上下文改變時，你需要做一些工作，讓改變呈現(xiàn)在用戶界面中。
這些框架的體系能分離你的模型和界面代碼，但同時也留下了一大部分同步的工作給你。你可以監(jiān)聽某類事件的發(fā)生，但是你有義務(wù)去計算如何重新渲染以及如何落實到用戶界面中。
基于這種模型，作為開發(fā)者，你需要考慮大量的性能問題。由于你能控制什么時候和怎么處理更新，你可以從中做任意的做一些調(diào)整。這經(jīng)常會面臨一些權(quán)衡：簡單的處理導致大面積的頁面更新，或者強性能的處理來更新一小塊頁面。
Ember.js: 數(shù)據(jù)綁定由于我在控制你的模型和試圖，我會確切知道如何重新渲染。
當應(yīng)用狀態(tài)改變的時候，手動處理渲染工作，無可避免的增加了復雜度。很多框架旨在解決這個問題，Ember.js 就是其中之一。
Ember，像 Backbone 一樣，當數(shù)據(jù)模型改變的時候會觸發(fā)某個事件。不同之處在于 Ember 同時提供了一些方法來接收這些事件。你可以把 UI 綁定到數(shù)據(jù)模型中，這意味著有一個監(jiān)聽器綁定到了 UI 上。該監(jiān)聽器當收到事件的時候，知道如何更新 UI。
這是一個高效率的機制。盡管設(shè)置全部的監(jiān)聽器需要在初始化時多出一些工作，但是之后就能保證同步狀態(tài)時的最小影響。當狀態(tài)產(chǎn)生變化時， 只有真正需要更新的部分才會發(fā)生改變。
這種方式最大的犧牲是 Ember 需要時刻盯著數(shù)據(jù)模型。這意味著你需要通過 Ember 的 API 封裝你的數(shù)據(jù)，以及你要更新數(shù)據(jù)的時候是使用 foo.set("x",42) 而不是 foo.x = 42，以此類推。
在未來 ES6 的 Proxies 可能會對這種模式產(chǎn)生一定的幫助。它讓 Ember 可以通過裝飾 object 來綁定那些監(jiān)聽器的代碼。這就不用像傳統(tǒng)方式那樣重寫 object 的 setter 方法了。
原文鏈接Changes and Its detection of JavaScript Framework
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/89424.html
摘要：對此沒有任何限制，它不關(guān)心這個。一種控制變化的辦法是不可改變的，持久化的數(shù)據(jù)結(jié)構(gòu)?？偨Y(jié)檢測變化時開發(fā)中的核心問題，而框架們以各種方式解決這個問題。因為組件內(nèi)的變化是不被允許的。 AngularJS：臟檢查 我不知道什么更新了，所以當更新的時候，我只能檢查所有的東西。 AngularJS 類似于 Ember，當狀態(tài)改變的時候，必須人工去處理。但不同的是，AngularJS 從不同的角度來...
摘要：正在暑假中的課多周刊第期我們的微信公眾號，更多精彩內(nèi)容皆在微信公眾號，歡迎關(guān)注。若有幫助，請把課多周刊推薦給你的朋友，你的支持是我們最大的動力。原理微信熱更新方案漲知識了，熱更新是以后的標配。 正在暑假中的《課多周刊》(第1期) 我們的微信公眾號：fed-talk，更多精彩內(nèi)容皆在微信公眾號，歡迎關(guān)注。 若有幫助，請把 課多周刊 推薦給你的朋友，你的支持是我們最大的動力。 遠上寒山石徑...
摘要：正在暑假中的課多周刊第期我們的微信公眾號，更多精彩內(nèi)容皆在微信公眾號，歡迎關(guān)注。若有幫助，請把課多周刊推薦給你的朋友，你的支持是我們最大的動力。原理微信熱更新方案漲知識了，熱更新是以后的標配。 正在暑假中的《課多周刊》(第1期) 我們的微信公眾號：fed-talk，更多精彩內(nèi)容皆在微信公眾號，歡迎關(guān)注。 若有幫助，請把 課多周刊 推薦給你的朋友，你的支持是我們最大的動力。 遠上寒山石徑...
摘要：精讀前端可以從多個角度理解，比如規(guī)范框架語言社區(qū)場景以及整條研發(fā)鏈路。同是前端未來展望，不同的文章側(cè)重的格局不同，兩個標題相同的文章內(nèi)容可能大相徑庭。作為使用者，現(xiàn)在和未來的主流可能都是微軟系，畢竟微軟在操作系統(tǒng)方面人才儲備和經(jīng)驗積累很多。 1. 引言 前端展望的文章越來越不好寫了，隨著前端發(fā)展的深入，需要擁有非常寬廣的視野與格局才能看清前端的未來。 筆者根據(jù)自身經(jīng)驗，結(jié)合下面幾篇文章...
摘要：前端每周清單第期與模式變遷與優(yōu)化界面生成作者王下邀月熊編輯徐川前端每周清單專注前端領(lǐng)域內(nèi)容，以對外文資料的搜集為主，幫助開發(fā)者了解一周前端熱點分為新聞熱點開發(fā)教程工程實踐深度閱讀開源項目巔峰人生等欄目。 showImg(https://segmentfault.com/img/remote/1460000013279448); 前端每周清單第 51 期: React Context A...
閱讀 1202·2023-04-26 00:12
閱讀 3425·2021-11-17 09:33
閱讀 1124·2021-09-04 16:45
閱讀 1266·2021-09-02 15:40
閱讀 2349·2019-08-30 15:56
閱讀 3070·2019-08-30 15:53
閱讀 3611·2019-08-30 11:23
閱讀 2005·2019-08-29 13:54
