vue仍是react？小孩子才作選擇題！

時間 2019-11-09

原文原文鏈接

vue or react？That's a question.

前言

近兩年前端技術層出不窮，目前市面上已經有了不少供前端人員使用的開發框架，轉眼19年已過大半，前端框架領域日趨成熟，實現了三足鼎立的局面，老大哥Angular依然佔據了半壁江山，react和vue也勢頭強勁，迎頭遇上，在國內發展迅速，形勢一片大好。css

最近在學習使用框架的時候，分別使用vue和react開發了兩個移動端產品，對這兩個框架的學習曲線有了一些感悟，這兩個都是如今比較熱門的js框架，它倆在使用方式上和學習複雜度上仍是有很大區別的，這裏簡單總結下二者的差別。html

主要從如下幾個方面入手方面展開：前端

框架的誕生
設計思想
編寫語法
腳手架構建工具
數據綁定
虛擬DOM
指令
性能優化
原生渲染native
ssr服務端渲染
生命週期函數
銷燬組件
狀態集管理工具

誕生

vue

vue由尤雨溪開發，一開始是我的項目，目前由餓了麼團隊進行維護。vue近幾年來特別的受關注，三年前的時候angularJS霸佔前端JS框架市場很長時間，接着react框架橫空出世，由於它有一個特性是虛擬DOM，從性能上碾軋angularJS，這個時候，vue1.0悄悄的問世了，它的優雅，輕便也吸引了一部分用戶，開始受到關注，16年中旬，VUE2.0問世，無論從性能上，仍是從成本上都隱隱超過了react，火的一塌糊塗，這個時候，angular開發團隊也開發了angular2.0版本，而且改名爲angular，吸取了react、vue的優勢，加上angular自己的特色，也吸引到不少用戶，目前已經迭代到5.0了。友情提示注意下vue的誕生時間，若是正好有小夥伴在面試，被問到你是從何時開始接觸而且使用vue的，你要是回答用了五、6年了那場面就十分尷尬了。vue

react

起初facebook在建設instagram（圖片分享）的時候，由於牽扯到一個東西叫數據流，那爲了處理數據流而且還要考慮好性能方面的問題，Facebook開始對市場上的各類前端MVC框架去進行一個研究，然而並無看上眼的，因而Facebook以爲，仍是本身開發一個纔是最棒的，那麼他們決定拋開不少所謂的「最佳實踐」，從新思考前端界面的構建方式，他們就本身開發了一套，果真大牛創造力仍是很強大的。java

React 起源於 Facebook 的內部項目，由於該公司對市場上全部 JavaScript MVC 框架，都不滿意，就決定本身寫一套，用來架設Instagram 的網站。作出來之後，發現這套東西很好用，就在2013年5月開源了。node

設計思想

vue

vue的官網中說它是一款漸進式框架，採用自底向上增量開發的設計。這裏咱們須要明確一個概念，什麼是漸進式框架。在聲明式渲染（視圖模板引擎）的基礎上，咱們能夠經過添加組件系統（components）、客戶端路由（vue-router）、大規模狀態管理（vuex）來構建一個完整的框架。Vue從設計角度來說，雖然可以涵蓋全部這些內容，可是你並不須要一上手就把全部東西全用上，由於沒有必要。不管從學習角度，仍是實際狀況，這都是可選的。聲明式渲染和組建系統是Vue的核心庫所包含內容，而客戶端路由、狀態管理、構建工具都有專門解決方案。這些解決方案相互獨立，你能夠在覈心的基礎上任意選用其餘的部件，不必定要所有整合在一塊兒。能夠看到，所說的「漸進式」，其實就是Vue的使用方式，同時也體現了Vue的設計的理念。react

react

react主張函數式編程，因此推崇純組件，數據不可變，單向數據流，固然須要雙向的地方也能夠手動實現，好比藉助 onChange 和 setState 來實現一個雙向的數據流。而vue是基於可變數據的，支持雙向綁定，它提供了v-model這樣的指令來實現文本框的數據流雙向綁定。android

編寫語法

vue

vue推薦的作法是webpack+vue-loader的單文件組件格式，vue保留了html、css、js分離的寫法，使得現有的前端開發者在開發的時候能保持原有的習慣，更接近經常使用的web開發方式，模板就是普通的html，數據綁定使用mustache風格，樣式直接使用css。其中<style>標籤還提供了一個可選的scoped屬性，它會爲組件內 CSS 指定做用域，用它來控制僅對當前組件有效仍是全局生效。webpack

模板和JSX是各有利弊的東西。模板更貼近咱們的HTML，可讓咱們更直觀地思考語義結構，更好地結合CSS的書寫。ios

同時vue也支持JSX語法，由於是真正的JavaScript，擁有這個語言自己的全部的能力，能夠進行復雜的邏輯判斷，進行選擇性的返回最終要返回的DOM結構，可以實現一些在模板的語法限制下，很難作到的一些事情。

react

用過react的開發者可能知道，react是沒有模板的，直接就是一個渲染函數，它中間返回的就是一個虛擬DOM樹，React推薦的作法是 JSX + inline style, 也就是把HTML和CSS全都寫進JavaScript了,即'all in js'。JSX實際就是一套使用XML語法，用於讓咱們更簡單地去描述樹狀結構的語法糖。在react中，全部的組件的渲染功能都依靠JSX。你能夠在render()中編寫相似XML的語法，它最終會被編譯成原生JavaScript。不只僅是 HTML 能夠用 JSX 來表達，如今的潮流也愈來愈多地將 CSS 也歸入到 JavaScript 中來處理。JSX是基於 JS 之上的一套額外語法，學習使用起來有必定的成本。

構建工具

vue

vue提供了CLI 腳手架，能夠幫助你很是容易地構建項目。全局安裝以後，咱們就能夠用 vue create命令建立一個新的項目，vue 的 CLI 跟其餘 CLI不一樣之處在於，有多個可選模板，有簡單的也有複雜的，可讓用戶自定義選擇須要安裝的模塊，還能夠將你的選擇保存成模板，便於後續使用。

極簡的配置，更快的安裝，能夠更快的上手。它也有一個更完整的模板，包括單元測試在內的各類內容都涵蓋，可是，它的複雜度也更高，這又涉及到根據用例來選擇恰當複雜度的問題。

react

React 在這方面也提供了 create-react-app，可是如今還存在一些侷限性：

它不容許在項目生成時進行任何配置，而 Vue CLI 運行於可升級的運行時依賴之上，該運行時能夠經過插件進行擴展。
它只提供一個構建單頁面應用的默認選項，而 Vue 提供了各類用途的模板。
它不能用用戶自建的預設配置構建項目，這對企業環境下預先創建約定是特別有用的。

而要注意的是這些限制是故意設計的，這有它的優點。例如，若是你的項目需求很是簡單，你就不須要自定義生成過程。你能把它做爲一個依賴來更新。

數據綁定

vue

vue是實現了雙向數據綁定的mvvm框架，當視圖改變動新模型層，當模型層改變動新視圖層。在vue中，使用了雙向綁定技術，就是View的變化能實時讓Model發生變化，而Model的變化也能實時更新到View。

Vue採用數據劫持&發佈-訂閱模式的方式，vue在建立vm的時候，會將數據配置在實例當中，而後經過Object.defineProperty對數據進行操做，爲數據動態添加了getter與setter方法，當獲取數據的時候會觸發對應的getter方法，當設置數據的時候會觸發對應的setter方法，從而進一步觸發vm的watcher方法，而後數據更改，vm則會進一步觸發視圖更新操做。

react

react是單向數據流，react中屬性是不容許更改的，狀態是容許更改的。react中組件不容許經過this.state這種方式直接更改組件的狀態。自身設置的狀態，能夠經過setState來進行更改。在setState中，傳入一個對象，就會將組件的狀態中鍵值對的部分更改，還能夠傳入一個函數，這個回調函數必須向上面方式同樣的一個對象函數能夠接受prevState和props。經過調用this.setState去更新this.state,不能直接操做this.state，請把它當成不可變的。
調用setState更新this.state，它不是立刻就會生效的，它是異步的。因此不要認爲調用完setState後能夠立馬獲取到最新的值。多個順序執行的setState不是同步的一個接着一個的執行，會加入一個異步隊列，而後最後一塊兒執行，即批處理。

setState是異步的，致使獲取dom可能拿的仍是以前的內容，因此咱們須要在setState第二個參數（回調函數）中獲取更新後的新的內容。

diff算法

vue

vue中diff算法實現流程

在內存中構建虛擬dom樹
將內存中虛擬dom樹渲染成真實dom結構
數據改變的時候，將以前的虛擬dom樹結合新的數據生成新的虛擬dom樹
將這次生成好的虛擬dom樹和上一次的虛擬dom樹進行一次比對（diff算法進行比對），來更新只須要被替換的DOM，而不是所有重繪。在Diff算法中，只平層的比較先後兩棵DOM樹的節點，沒有進行深度的遍歷。
會將對比出來的差別進行從新渲染

react

react中diff算法實現流程

DOM結構發生改變-----直接卸載並從新create
DOM結構同樣-----不會卸載,可是會update變化的內容
全部同一層級的子節點.他們均可以經過key來區分-----同時遵循1.2兩點
（其實這個key的存在與否只會影響diff算法的複雜度,換言之,你不加key的狀況下,diff算法就會以暴力的方式去根據一二的策略更新,可是你加了key,diff算法會引入一些另外的操做）

React會逐個對節點進行更新，轉換到目標節點。而最後插入新的節點，涉及到的DOM操做很是多。diff總共就是移動、刪除、增長三個操做，而若是給每一個節點惟一的標識（key），那麼React優先採用移動的方式，可以找到正確的位置去插入新的節點。

vue會跟蹤每個組件的依賴關係，不須要從新渲染整個組件樹。而對於React而言,每當應用的狀態被改變時,所有組件都會從新渲染,因此react中會須要shouldComponentUpdate這個生命週期函數方法來進行控制。

指令

指令 (Directives) 是帶有 v- 前綴的特殊特性，指令的職責是，當表達式的值改變時，將其產生的連帶影響，響應式地做用於 DOM。

vue

vue中提供不少內部指令供咱們使用，它可讓咱們進行一些模板的操做，例若有時候，咱們的data中的存放的數據不是個簡單的數字或者字符串，而是數組Array類型，這個時候，咱們要把數組的元素展現在視圖上，就須要用到vue提供的 v-for 指令，來實現列表的渲染。

react

由於react中沒有v-for指令，因此循環渲染的時候須要用到map()方法來渲染視圖，而且將符合條件的元素放入一個新數組返回。

性能優化

vue

vue中的每一個組件內部自動實現了shouldComponentUpdate的優化，在vue裏面因爲依賴追蹤系統的存在，當任意數據變更的時，Vue的每個組件都精確地知道本身是否須要重繪，因此並不須要手動優化。用vue渲染這些組件的時候，數據變了，對應的組件基本上去除了手動優化的必要性。而在react中咱們須要手動去優化其性能，可是當數據特別多的時候vue中的watcher也會特別多，從而形成頁面卡頓，因此通常數據比較多的大型項目會傾向於使用react。在react官網中，官方也建議咱們使用React來構建快速響應的大型 Web 應用程序。

react

當props或state發生改變的時候會觸發shouldComponentUpdate生命週期函數，它是用來控制組件是否被從新渲染的，若是它返回true，則執行render函數，更新組件；若是它返回false，則不會觸發從新渲染的過程。

有的時候咱們但願它在更新以前，和以前的狀態進行一個對比，這個時候咱們就須要重寫shouldComponentUpdate來避免沒必要要的dom操做，對比當前的props或state和更新以後的nextProps或nextState，返回true時，組件更新；返回false，則不會更新，節省性能。

shouldComponentUpdate(nextProps, nextState) {
        if (this.props.a !== nextProps.a) {
            return true;
        }
        if (this.state.b !== nextState.b) {
            return true;
        }
        return false;
    }

咱們也能夠建立一個繼承React.PureComponent的React組件，它自帶shouldComponentUpdate，能夠對props進行淺比較，發現更新以後的props與當前的props同樣，就不會進行render了。

class Test extends React.PureComponent{
    constructor(props){
        super(props);
    }
    render(){
        return <div>hello...{this.props.a}</div>
    }
}

因爲React.PureComponent進行的是淺比較，也就是說它只會對比原對象的值是否相同，當咱們的props或state爲數組或者對象這種引用類型的時候，咱們修改它的數值，因爲數據引用指針沒有發生改變，因此組件也是不會從新渲染的。這個時候咱們就須要進行深拷貝，建立一個新的對象或數組，將原對象的各項屬性的"值"（數組的全部元素）拷貝過來，是"值"而不只僅是"引用地址"。咱們可使用slice()方法：

ew_state.todos = new_state.todos.slice();

或者引入immutable庫來實現數據不可變。

原生渲染native

native指的是使用原生API來開發App，好比ios使用OC語言，android使用java。

vue

vue和Weex進行官方合做，weex是阿里巴巴發起的跨平臺用戶界面開發框架，它的思想是多個平臺，只寫一套代碼，weex容許你使用 vue 語法開發不只僅能夠運行在瀏覽器端，還能被用於開發 iOS 和 Android 上的原生應用的組件。即只須要編寫一份代碼，便可運行在Web、iOS、Android上。

weex相對來講上手比較簡單，安裝vue-cli以後就可使用，學習門檻低，可是它的社區目前還處於成長期，react native的社區很是成熟活躍，有很是豐富的組件可供擴展。

react

react native是Facebook在2015年3月在F8開發者大會上開源的跨平臺UI框架，需針對iOS、Android不一樣編寫2份代碼，使用react native須要按照文檔安裝配置不少依賴的工具，相對比較麻煩。weex的思想是多個平臺，只寫一套代碼，而react-native的思想是多個平臺能夠寫多套代碼，但其使用的是同一套語言框架。
weex的目標在於抹平各個平臺的差別性，從而簡化應用開發。而react-native認可了各個平臺之間的差別，退而求其次，在語言和框架層面對平臺進行抽象，從方法論的角度去解決多平臺開發的問題。

ssr服務端渲染

服務端渲染核心在於方便seo優化，後端先調用數據庫，得到數據以後，將數據和頁面元素進行拼裝，組合成完整的html頁面，再直接返回給瀏覽器，以便用戶瀏覽。

vue

2016 年 10 月 25 日，zeit.co背後的團隊對外發布了 Next.js，一個 React 的服務端渲染應用框架。幾小時後，與 Next.js 殊途同歸，一個基於 Vue.js 的服務端渲染應用框架應運而生，咱們稱之爲：Nuxt.js。

服務端渲染支持流式渲染，由於HTTP請求也是流式，Vue 的服務端渲染結果能夠直接 pipe 到返回的請求裏面。這樣一來，就能夠更早地在瀏覽器中呈現給用戶內容，經過合理的緩存策略，能夠有效地提高服務端渲染的性能。

基於 Vue.js
自動代碼分層
服務端渲染
強大的路由功能，支持異步數據
靜態文件服務
ES2015+ 語法支持
打包和壓縮 JS 和 CSS
HTML 頭部標籤管理
本地開發支持熱加載
集成 ESLint
支持各類樣式預處理器： SASS、LESS、 Stylus 等等
支持 HTTP/2 推送

react

Next是一個React框架，容許使用React構建SSR和靜態web應用

服務器渲染，獲取數據很是簡單
無需學習新框架，支持靜態導出。
支持CSS-in-JS庫
自動代碼拆分，加快頁面加載速度，不加載沒必要要的代碼
基於Webpack的開發環境，支持模塊熱更新（HMR）
支持Babel和Webpack自定義配置服務器、路由和next插件。
可以部署在任何能運行node的平臺
內置頁面搜索引擎優化（SEO）處理
在生產環境下，打包文件體積更小，運行速度更快

生命週期

vue

【初始化階段（4個）】

（1）beforeCreate

此鉤子函數不能獲取到數據，dom元素也沒有渲染出來，此鉤子函數不會用來作什麼事情。

（2）created

此鉤子函數，數據已經掛載了，可是dom節點仍是沒有渲染出來，在這個鉤子函數裏面，若是同步更改數據的話，不會影響運行中鉤子函數的執行。能夠用來發送ajax請求，也能夠作一些初始化事件的相關操做。

（3）beforeMount

表明dom節點立刻要被渲染出來了，可是尚未真正的渲染出來，此鉤子函數跟created鉤子函數基本同樣，也能夠作一些初始化數據的配置。

（4）mounted

是生命週期初始化階段的最後一個鉤子函數，數據已經掛載完畢了，真實dom也能夠獲取到了。

【運行中階段（2個）】

（5）beforeUpdate

運行中鉤子函數beforeUpdate默認是不會執行的，當數據更改的時候，纔會執行。數據更新的時候，先調用beforeUpdate，而後數據更新引起視圖渲染完成以後，再會執行updated。運行時beforeUpdate這個鉤子函數獲取的數據仍是更新以前的數據（獲取的是更新前的dom內容），在這個鉤子函數裏面，千萬不能對數據進行更改，會形成死循環。

（6）updated

這個鉤子函數獲取的數據是更新後的數據，生成新的虛擬dom，跟上一次的虛擬dom結構進行比較，比較出來差別（diff算法）後再渲染真實dom，當數據引起dom從新渲染的時候，在updated鉤子函數裏面就能夠獲取最新的真實dom了。

【銷燬階段（2個）】

（7）beforeDestroy

切換路由的時候，組件就會被銷燬了，銷燬以前執行beforeDestroy。在這個鉤子函數裏面，咱們能夠作一些善後的操做，例如能夠清空一下全局的定時器（created鉤子函數綁定的初始化階段的事件）、清除事件綁定。

（8）destoryed

組件銷燬後執行destroyed，銷燬後組件的雙向數據綁定、事件監聽watcher相關的都被移除掉了，可是組件的真實dom結構仍是存在在頁面中的。

添加keep-alive標籤後會增長active和deactive這兩個生命週期函數，初始化操做放在actived裏面，一旦切換組件，由於組件沒有被銷燬，因此它不會執行銷燬階段的鉤子函數，因此移除操做須要放在deactived裏面，在裏面進行一些善後操做，這個時候created鉤子函數只會執行一次，銷燬的鉤子函數一直沒有執行。

react

【初始化階段（5個）】：

（1）getDefaultProps：實例化組件以後，組件的getDefaultProps鉤子函數會執行

這個鉤子函數的目的是爲組件的實例掛載默認的屬性

這個鉤子函數只會執行一次，也就是說，只在第一次實例化的時候執行，建立出全部實例共享的默認屬性，後面再實例化的時候，不會執行getDefaultProps，直接使用已有的共享的默認屬性

理論上來講，寫成函數返回對象的方式，是爲了防止實例共享，可是react專門爲了讓實例共享，只能讓這個函數只執行一次

組件間共享默認屬性會減小內存空間的浪費，並且也不須要擔憂某一個實例更改屬性後其餘的實例也會更改的問題，由於組件不能本身更改屬性，並且默認屬性的優先級低。

（2）getInitialState：爲實例掛載初始狀態，且每次實例化都會執行，也就是說，每個組件實例都擁有本身獨立的狀態。

（3）componentWillMount：執行componentWillMount，至關於Vue裏的created+beforeMount，這裏是在渲染以前最後一次更改數據的機會，在這裏更改的話是不會觸發render的從新執行。

（4）render：渲染dom

render()方法必須是一個純函數，他不該該改變state，也不能直接和瀏覽器進行交互，應該將事件放在其餘生命週期函數中。若是shouldComponentUpdate()返回false，render()不會被調用。

（5）componentDidMount：至關於Vue裏的mounted,多用於操做真實dom

【運行中階段（5個）】

當組件mount到頁面中以後，就進入了運行中階段，在這裏有5個鉤子函數，可是這5個函數只有在數據（屬性、狀態）發送改變的時候纔會執行

（1）componentWillReceiveProps(nextProps,nextState)

當父組件給子組件傳入的屬性改變的時候，子組件的這個函數纔會執行。初始化props時候不會主動執行

當執行的時候，函數接收的參數是子組件接收到的新參數，這個時候，新參數尚未同步到this.props上,多用於判斷新屬性和原有屬性的變化後更改組件的狀態。

（2）接下來就會執行shouldComponentUpdate(nextProps,nextState),這個函數的做用：當屬性或狀態發生改變後控制組件是否要更新，提升性能,返回true就更新，不然不更新，默認返回true。

接收nextProp、nextState，根據根據新屬性狀態和原屬性狀態做出對比、判斷後控制是否更新

若是shouldComponentUpdate()返回false，componentWillUpdate,render和componentDidUpdate不會被調用。

（3）componentWillUpdate,在這裏，組件立刻就要從新render了，多作一些準備工做，千萬千萬，不要在這裏修改狀態，不然會死循環至關於Vue中的beforeUpdate

（4）render，從新渲染dom

（5）componentDidUpdate，在這裏，新的dom結構已經誕生了,至關於Vue裏的updated

【銷燬階段】

當組件被銷燬以前的一剎那，會觸發componentWillUnmount，臨死前的掙扎

至關於Vue裏的beforeDestroy，因此說通常會作一些善後的事情，例如使定時器無效，取消網絡請求或清理在componentDidMount中建立的任何監聽。

銷燬組件

vue

vue在調用$destroy方法的時候就會執行beforeDestroy生命週期函數，而後組件被銷燬，這個時候組件的dom結構還存在於頁面結構中，也就說若是想要對殘留的dom結構進行處理必須在destroyed生命週期函數中處理。

react

react執行完componentWillUnmount以後把事件、數據、dom都所有處理掉了，也就是說當父組件從渲染這個子組件變成不渲染這個子組件的時候，子組件至關於被銷燬，因此根本不須要其餘的鉤子函數了。react銷燬組件的時候，會將組件的dom結構也移除，vue則否則，在調用destory方法銷燬組件的時候，組件的dom結構仍是存在於頁面中的，this.$destory組件結構仍是存在的，只是移除了事件監聽，因此這就是爲何vue中有destroyed，而react卻沒有componentDidUnmount。

狀態集管理工具

vue

vuex是一個專門爲vue構建的狀態集管理工具，vue和react都是基於組件化開發的，項目中包含不少的組件，組件都會有組件嵌套，想讓組件中的數據被其餘組件也能夠訪問到就須要使用到Vuex。

[圖片上傳失敗...(image-2a0a7e-1565257938346)]

vuex的流程

將須要共享的狀態掛載到state上：this.$store.state來調用

建立store，將狀態掛載到state上，在根實例裏面配置store，以後咱們在組件中就能夠經過this.$store.state來使用state中管理的數據，可是這樣使用時，當state的數據更改的時候，vue組件並不會從新渲染，因此咱們要經過計算屬性computed來使用，可是當咱們使用多個數據的時候這種寫法比較麻煩，vuex提供了mapState輔助函數，幫助咱們在組件中獲取並使用vuex的store中保存的狀態。

咱們經過getters來建立狀態：經過this.$store.getters來調用

能夠根據某一個狀態派生出一個新狀態，vuex也提供了mapGetters輔助函數來幫助咱們在組件中使用getters裏的狀態。

使用mutations來更改state：經過this.$store.commit來調用

咱們不能直接在組件中更改state，而是須要使用mutations來更改，mutations也是一個純對象，裏面包含不少更改state的方法，這些方法的形參接收到state，在函數體裏更改，這時，組件用到的數據也會更改，實現響應式。vuex提供了mapMutations方法來幫助咱們在組件中調用mutations 的方法。

使用actions來處理異步操做：this.$store.dispatch來調用

Actions相似於mutations，不一樣在於：Actions提交的是mutations，而不是直接變動狀態。Actions能夠包含任意異步操做。也就是說，若是有這樣的需求：在一個異步操做處理以後，更改狀態，咱們在組件中應該先調用actions，來進行異步動做，而後由actions調用mutations來更改數據。在組件中經過this.$store.dispatch方法調用actions的方法，固然也可使用mapMutations來輔助使用。

react

2015年Redux出現，將 Flux 與函數式編程結合一塊兒，很短期內就成爲了最熱門的前端架構。它的出現主要是爲解決react中組件之間的通訊問題。建議把數據放入到redux中管理，目的就是方便數據統一，好管理。項目一旦出現問題，能夠直接定位問題點。組件擴展的時候，後續涉及到傳遞的問題。原本的話，組件使用本身的數據，可是後來公用組件，還須要考慮如何值傳遞，在redux中能夠存儲至少5G以上的數據。

redux的流程

建立store：
從redux工具中取出createStore去生成一個store。
建立一個reducer，而後將其傳入到createStore中輔助store的建立。
reducer是一個純函數，接收當前狀態和action，返回一個狀態，返回什麼，store的狀態就是什麼，須要注意的是，不能直接操做當前狀態，而是須要返回一個新的狀態。

想要給store建立默認狀態其實就是給reducer一個參數建立默認值。
組件經過調用store.getState方法來使用store中的state，掛載在了本身的狀態上。
組件產生用戶操做，調用actionCreator的方法建立一個action，利用store.dispatch方法傳遞給reducer
reducer對action上的標示性信息作出判斷後對新狀態進行處理，而後返回新狀態，這個時候store的數據就會發生改變， reducer返回什麼狀態，store.getState就能夠獲取什麼狀態。
咱們能夠在組件中，利用store.subscribe方法去訂閱數據的變化，也就是能夠傳入一個函數，當數據變化的時候，傳入的函數會執行，在這個函數中讓組件去獲取最新的狀態。

小結

vue和react的核心都是專一於輕量級的視圖層，雖然只是解決一個很小的問題，可是它們龐大的生態圈提供了豐富的配套工具，一開始它並不會給你提供全套的配置方案，將全部的功能都一次性給你打包好，它只會給你提供一些簡單的核心功能，當你須要作一個更復雜的應用時，再增添相應的工具。例如作一個單頁應用的時候才須要用路由；作一個至關龐大的應用，涉及到多組件狀態共享以及多個開發者共同協做時，纔可能須要大規模狀態管理方案。

框架的存在就是爲了幫助咱們應對不一樣的項目複雜度，當咱們面對一個大型、複雜的開發項目時，使用太簡陋的工具會極大的下降開發人員的生產力，影響工做效率，框架的誕生就是在這些工程中提取一些重複的而且已經受過驗證的模式，抽象到一個已經幫你設計好的API封裝當中，幫助咱們去應對不一樣複雜度的問題。因此在開發的過程當中，選擇一個合適的框架就會事半功倍。可是，框架自己也有複雜度，有些框架會讓人一時不知如何上手。當你接到一個並不複雜的需求，卻使用了很複雜的框架，那麼就至關於殺雞用牛刀，會遇到工具複雜度所帶來的反作用，不只會失去工具自己所帶來優點，還會增長各類問題，例如學習成本、上手成本，以及實際開發效率等。

因此並非說作得少的框架就不如作的作的框架，每一個框架都有各自的優點和劣勢，並不能找到徹底符合需求的框架，最重要的適合當前項目，目前兩大框架的生態圈一片繁榮，react社區是當前最活躍的，最快的時候三天更新一個版本，一個問題可能存在幾十種不一樣的解決方案，這就須要咱們前端人員去在不一樣的功能之間作取捨，之後前端框架的發展方向應該是小而精、靈活以及開放的，核心功能+生態附加庫能夠幫咱們更加靈活的構建項目，爲了跟上前進的腳步，就須要不停的吸取最新的內容，這也是從事前端開發領域的一大樂趣，但願你們都能在學習中得到長足的進步。