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