資訊專欄INFORMATION COLUMN
摘要：對此沒有任何限制，它不關心這個。一種控制變化的辦法是不可改變的，持久化的數據結構。總結檢測變化時開發中的核心問題，而框架們以各種方式解決這個問題。因為組件內的變化是不被允許的。
AngularJS：臟檢查
我不知道什么更新了，所以當更新的時候，我只能檢查所有的東西。
AngularJS 類似于 Ember，當狀態改變的時候，必須人工去處理。但不同的是，AngularJS 從不同的角度來解決問題。
當你在 Angular 模板中引用你的數據，例如這樣的語句 {{foo.x}} ，Angular 不僅僅只是渲染數據，而且會這個特定的數據創建一個觀察者。如此，只要你的應用中發生任何變化，Angular 都會檢查這個觀察者檢視著的數據是否發生了改變。如果發生了改變，就會重新渲染這個數據對應的用戶界面。這個過程稱作臟檢查（Dirty Checking）。
這種監聽改變的風格最大的好處就是，你可以在你的數據模型中使用任何姿勢。Angular 對此沒有任何限制，它不關心這個。沒有基礎的對象需要擴展，也沒有 API 需要調用。
但壞處就是現在數據模型沒有任何內建的檢測手段告訴告訴框架哪些東西發生了改變，框架對是否或者哪里發生了改變沒有任何洞察力。這意味著數據模型需要通過外部來監聽改變，而 Angular 就是這樣子做的：所有觀察者在任何時間發生的任何改變，都需要被執行一次。點擊事件，HTTP 響應，timeout 方法的觸發，對于這些，觀察者都需要執行一遍。
經常去執行所有觀察者，這聽起來像是性能的噩夢，但是它令人驚訝的快。這主要是因為在檢查到任何改變之前，沒有 DOM 的操作過程，而原生的 JavaScript 引用對象的檢查平均消耗的性能是廉價的。但是當你要處理大量的 UI 或者經常性觸發重新渲染，那么額外的性能優化手段就變得很有必要了。
Ember 和 Angular 都即將得益于即將到來的標準：ECMAScript7 的 Object.observe 功能，很適合 Angular。它提供了原生的 API 給你用來監聽對象屬性的變化。盡管這樣，Angular 不需要支持所有的用例，因為 Angular 的觀察者相對于簡單的監聽對象屬性，可以做到的更好。
即將到來的 Angular 2 在檢測改變這件事上帶來了很多有趣的更新，最近 Victor Savkin 的一篇文章有介紹到。
關于這個主題，也可以看：Victor"s ng-conf talk
React: 虛擬 DOM我不知道到底哪些發生了變化，所以我只能重新渲染所有東西，然后看一下有哪些不同。
React 有很多有趣的特性，但是我們討論的最有趣的特性是虛擬 DOM。
像 Angular 一樣，React 不會對數據模型進行限制，而是讓你使用你認為合適的任何對象和數據結構。那么，它是如何在存在改變的情況下使 UI 保持最新呢？
React 所做的是有效的把我們帶回服務器渲染時代，當時我們還不關心狀態變化：每當某處發生改變的時候，它會從頭重新渲染整個 UI。這可以顯著的簡化 UI 的代碼。大部分情況，你不會關心如何在 React 中維護狀態。就像服務器渲染一樣，渲染一次就算了。當組件需要變更時，它只能再次重新渲染。組價的初始化渲染和更細它的數據之間，沒有任何區別。
如果故事就這么結束的話，它看起來的確非常低效。然而，React 在重新渲染方面，有點特殊。
當 React 進行重新渲染時，它首先會渲染到虛擬 DOM 中，這不是一個實際的 DOM 對象的圖。而是一個輕量級的，有純粹的 object 和 array 組成的純 JavaScript 的數據結構，它代表著一個真實的 DOM 對象的圖。
然后，一個獨立的進程會根據虛擬 DOM 的結構來創建那些在屏幕上顯示的真實的 DOM 元素。
之后，當變化發生的時候，一個新的虛擬 DOM 會被從頭到尾創建出來。這個新的虛擬 DOM 將映射出數據模型的新的狀態。現在 React 在手上有兩個虛擬 DOM：一個新的，一個舊的。然后會對兩個虛擬 DOM 進行一個對比算法，得出它們之間的一組變化。有且只有這些更改會被應用到真實 DOM 中：此元素已添加，此屬性以改變，等等。
所以 React 起碼至少有一個好處，就是你不用追蹤變化了。你只需要每次重新渲染整個 UI ，然后無論改變了什么最終都會得到相應的結果。React 的虛擬 DOM 對比算法，能讓你做到這一點，并且最大限度的節省昂貴的 DOM 操作。
Om: 不可改變的數據結構我確切的知道哪些沒有改變。
雖然 React 的虛擬 DOM 相當的塊，但是當你的 UI 非常龐大或者經常性渲染的時候（例如：每秒高達 60 次），它依然會面臨瓶頸。
問題在于，真的沒辦法每次都渲染出整個虛擬 DOM，除非你引入一些方法來控制數據模型的改變，就像 Ember 做的一樣。
一種控制變化的辦法是 不可改變的，持久化的數據結構。這些看起來似乎很適合使用在 React 的虛擬 DOM 中，正如 David Nolen 在 Om 庫中所做的 工作 那樣，一個構建于 React 和 ClojureScript 之上的庫。
有一點關于不可改變數據結構的是，顧名思義，你永遠不能改變它，只能產生新的版本。如果你想改變一個對象的屬性，你只能新建一個對象和屬性，因為你不能改變已經存在的那一個。由于持久化數據結構的工作方式，這比聽起來更加有效率。
這意味著在檢測變化方面，當 React 組件都只由不可變數據組成的時候，只有一個逃生窗口：當你重新渲染一個組件時，組件的狀態仍然指向上次渲染時的相同數據結構，你就可以跳過這次重新渲染。你可以使用該組件的先前的虛擬 DOM 以及源自該組件的整個組件樹。沒有必要進一步挖掘，因為在這個狀態中所有東西都不可能改變。
就像 Ember 一樣，像 Om 的這種庫不允許在你的數據中使用舊的 JavaScript 對象圖。你必須在不可變數據結構中構建你的數據模型，從而才能在其中得到好處。我會贊同這樣的做法，因為這一次你這樣做并不是為了取悅框架本身。你這樣做只是因為這是一個又簡單又好的方式去管理你的應用狀態。使用不可變數據結構的主要好處，并不是提升渲染性能，而是簡化你的應用結構。
雖然 Om 和 ClojureScript 已經講 React 和不可變數據結構融合起來，但是他們并不是圈子里面的唯一組合。而僅僅使用 React 和 Facebook 的 Immutable-js 是完全可能的。這個庫的作者 Lee Byron 在最近的一次 React.js 為主題的會議中進行了一個 精彩的介紹。
同時我建議看一下 Rich Hickey"s 的 Persistent Data Structures And Managed References, 去了解狀態管理的方法。
我自己現在一直在為不可變數據數據結構 寫詩，但我絕對沒有預見到它會進入前端 UI 框架行列。它看起來似乎不遺余力的發生著，而 Angular 的人 正在為支持這個而努力著。
總結檢測變化時 UI 開發中的核心問題，而 JavaScript 框架們以各種方式解決這個問題。
EmberJS 能在它們發生變化的時候檢測到，因為它控制著你的數據模型 API，并且可以在你調用它的時候觸發事件。
Angular.js 是事后進行檢測， 它通過重新運行你已經在 UI 中注冊的所有數據綁定，來檢測它們的值是否已經發生變化。
React 的檢測方法是通過把整個 UI 重新渲染成一個虛擬 DOM，然后和舊的版本進行對比。無論改變了什么，都可以給真實 DOM 打上個補丁。
React 和 不可變數據結構的組合，對比純粹的 React 有所增強，通過快速的在組件樹中標記不可變的節點。因為組件內的變化是不被允許的。但是，這不是主要出于性能的原因，而是由于它對整個應用程序體系結構有積極的影響。
原文鏈接Changes and Its detection of JavaScript Framework
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/90159.html
摘要：正文在年，框架的選擇并不少。特別的，通過思考這些框架分別如何處理狀態變化是很有用的。本文探索以下的數據綁定，的臟檢查的虛擬以及它與不可變數據結構之間的聯系。當狀態產生變化時，只有真正需要更新的部分才會發生改變。 譯者言 近幾年可謂是 JavaScript 的大爆炸紀元，各種框架類庫層出不窮，它們給前端帶來一個又一個的新思想。從以前我們用的 jQuery 直接操作 DOM，到 Backb...
摘要：正在暑假中的課多周刊第期我們的微信公眾號，更多精彩內容皆在微信公眾號，歡迎關注。若有幫助，請把課多周刊推薦給你的朋友，你的支持是我們最大的動力。原理微信熱更新方案漲知識了，熱更新是以后的標配。 正在暑假中的《課多周刊》(第1期) 我們的微信公眾號：fed-talk，更多精彩內容皆在微信公眾號，歡迎關注。 若有幫助，請把 課多周刊 推薦給你的朋友，你的支持是我們最大的動力。 遠上寒山石徑...
摘要：正在暑假中的課多周刊第期我們的微信公眾號，更多精彩內容皆在微信公眾號，歡迎關注。若有幫助，請把課多周刊推薦給你的朋友，你的支持是我們最大的動力。原理微信熱更新方案漲知識了，熱更新是以后的標配。 正在暑假中的《課多周刊》(第1期) 我們的微信公眾號：fed-talk，更多精彩內容皆在微信公眾號，歡迎關注。 若有幫助，請把 課多周刊 推薦給你的朋友，你的支持是我們最大的動力。 遠上寒山石徑...
摘要：前端每周清單第期與模式變遷與優化界面生成作者王下邀月熊編輯徐川前端每周清單專注前端領域內容，以對外文資料的搜集為主，幫助開發者了解一周前端熱點分為新聞熱點開發教程工程實踐深度閱讀開源項目巔峰人生等欄目。 showImg(https://segmentfault.com/img/remote/1460000013279448); 前端每周清單第 51 期: React Context A...
摘要：精讀前端可以從多個角度理解，比如規范框架語言社區場景以及整條研發鏈路。同是前端未來展望，不同的文章側重的格局不同，兩個標題相同的文章內容可能大相徑庭。作為使用者，現在和未來的主流可能都是微軟系，畢竟微軟在操作系統方面人才儲備和經驗積累很多。 1. 引言 前端展望的文章越來越不好寫了，隨著前端發展的深入，需要擁有非常寬廣的視野與格局才能看清前端的未來。 筆者根據自身經驗，結合下面幾篇文章...
閱讀 1035·2023-04-25 17:51
閱讀 2852·2021-11-23 09:51
閱讀 1469·2021-11-08 13:21
閱讀 2428·2021-09-22 15:14
閱讀 1514·2019-08-30 12:48
閱讀 1076·2019-08-29 12:44
閱讀 1137·2019-08-26 12:21
閱讀 1396·2019-08-26 10:47
