摘要：自己英語一般，水平有限，獻上原文地址，還有我翻譯的中文地址，歡迎大家勘誤下面是自己的一點感想先說一下，我們知道，前端優化有這么幾步，第一步首先呢我們知道，一個應用要依賴好多條文件，而瀏覽器加載完一條，要執行完這條才加載下一條，所以呢，就很慢

自己英語一般，水平有限，獻上原文地址，還有我翻譯的中文地址，歡迎大家勘誤

先說一下webpack，我們知道，前端優化有這么幾步，

首先呢我們知道，一個應用要依賴好多條js文件，而瀏覽器加載完一條，要執行完這條才加載下一條，所以呢，就很慢，于是乎我們就得把它們合成一個，

我們知道瀏覽器是有緩存的，那發布新版本的時候為了防止瀏覽器緩存，每次發新版本我們都得和上一版文件名不一樣，所以我們用md5摘要算法將js文件生產摘要，作為js文件名的一部分

可是我們又想利用瀏覽器緩存，減少請求，加快加載速度，我們發現我們經常改的是我應用的業務邏輯部分的js，而js的依賴幾乎不該，而且js的依賴體積還不小呢。所以我們把js的所有的依賴放在一個文件（vendor.js）里，業務邏輯放一個文件(app.js)里，然后分別md5加密

如果是是單頁應用，而且又是一個比較龐大的應用，一上來就把所有的js 都加載了，，是不是很浪費，因為很多頁面，我們都點不進去啊。所以能我們需要按需加載。只有訪問要加載的頁面時，我們才加載相關js

還是單頁應用，為了加快第一次加載的速度，我們想如果要是css也能按需加載就好了，我們為什么不用js動態按需加載css呢，干脆將css和js 寫一起（我們該怎么寫就怎么寫，讓webpack讓他們在一起），加載js就把css 加載了，一條js請求就同時里面包含css。。這樣css的請求也變少了，而且他倆可以一起用gzip壓縮

圖標什么的很多很雜有不大，我們是不是為了減少 請求數將他們合在一起啊。。生成雪碧圖。。對這還不夠完美。要是能和js在一起就更好了。。咋做呢。。用base64 讓他變成字符串。然后就能和js在一起了。這樣的話還可以利用gizp壓縮百分之75。不過前提是小圖片或者小圖標。。不然。。。圖片太大的話還是。。
以上這6步。。webpack十幾行代碼就能幫你實現。demo看這里m.loutianxia.cn

我覺得性能大數據量高交互的應用，同樣是兩個大牛，分別用react和angular，react會比angular性能好很多。注意我的前提哦，我用了一年半angular，最后還是被他的臟檢查，傷痛了心，我們知道一個雙向綁定就代表一個watch，就代表一串臟檢查，當數據一大的時候。。唉。。。

我先說一個結論單向數據流要比mvc強好多，
我會在我翻譯的redux教程中詳細說明

啰嗦這么多開始教程

當我試著學redux的時候,我意識到通過依賴讀過的文章和個人經驗學習到的有關flux的知識，存在很多錯誤的地方我不是說那些關于flux的文章不好只是我沒有正確掌握這些概念。
最終, 讓我僅僅只是會用不同flux框架(Reflux, Flummox, FB Flux)的文檔,和試圖將他們和我讀過的理論概念（actions / actions creators, store, dispatcher, etc）生搬硬套只有當我開始用redux的時候，我才發現這個flux其實比我想象的簡單多了
，這多虧了redux擁有非常精良的設計而且不會向我以前以前用的那些框架一樣，有大量的“anti-boilerplate features”（反 范式 特征）現在 ，可以毫不夸張的說 我感覺通過redux學習flux比許多其他框架好多了。
用我自己的話講，這就是為什么我想把我掌握的和運用的有關redux的flux概念分享給大家的原因，你可能已經知道下圖呈現的是著名的單數據流flux應用

                 _________               ____________               ___________
                |         |             |            |             |           |
                | Action  |------------?| Dispatcher |------------?| callbacks |
                |_________|             |____________|             |___________|
                     ▲                                                   |
                     |                                                   |
                     |                                                   |
 _________       ____|_____                                          ____▼____
|         |?----|  Action  |                                        |         |
| Web API |     | Creators |                                        |  Store  |
|_________|----?|__________|                                        |_________|
                     ▲                                                   |
                     |                                                   |
                 ____|________           ____________                ____▼____
                |   User       |         |   React   |              | Change  |
                | interactions |?--------|   Views   |?-------------| events  |
                |______________|         |___________|              |_________|

在這個教程我們會逐步介紹給你以上圖表中的概念.我們會分別嘗試理解每一模塊存在的理由和扮演著一種什么樣的角色，
而不是上來就解釋整張圖，這樣大家都會頭大的 一旦你理解了每一部分，就能集齊龍珠，召喚神龍啦，哈哈哈

假設我們正在開發一個web應用， 那么它是由啥構成的呢?
1) Templates(模版) / html = View(視圖)
2) 和我們View(視圖層)里綁定的數據= Models (模型)
3) 取數據的邏輯, 調度切換各種視圖層,響應用戶事件,數據的修改等= Controller(控制層)

這是我們所熟悉的非常經典的mvc模式.想必你心中也有這樣的疑惑，如果在表達上稍作修改，其實mvc模式也很想flux的概念

Models 就像 stores

用戶事件,數據操作和數據修改就像 "action creators" -> action -> dispatcher -> callback

(view)視圖層 就像 React views

所以說，難道flux就僅僅是單詞而已嗎? 不是這樣的.但是這個單詞至關重要，
因為我們可以表達的更精準一些通過這些術語（意思是說，，這么一比，難道flux僅僅是一個名字而已嗎，
其核心概念還和mvc一樣。不是這樣的,它其實和mvc思想是不同的。但flux的這個單詞也不能小覷哦，
因為它通過提出一些新的術語，可以更精準的描述flxu這一架構），舉個例子, 向后臺請求數據是可以稱為action, 就像一個點擊事件也是一個action，
input的change 事件也是一個action ...然后我們的操作都可以稱為action，action只是一個名字而已。
flux可以確保所有action都是由一個叫做dispatcher發出的 然后經過我們的stores，最后通過監聽store，發出一個通知。
而不是讓action直接修改你的Model層和View層(意思是說。。任何action,都必須通過dispatcher發起。
然后能引起stores改變，stores的改變會通知，再引起view的改變，而不像mvc那樣，一個事件過來了，
在這個事件的回調函數直接里改變model或者修改view)

我們將在mvc應用中寫一個經典的用例
1) 用戶點擊按鈕A
2) 按鈕A的點擊處理函數會觸發Model(模型) "A"的改變
3) Model"A"的改變，會使監聽Model "A"的函數執行，這個函數會觸發Model(模型) "B"的改變
4) Model"B"的改變，會使監聽Model "B"的函數執行，這個函數會觸發 View B的 重新渲染

在這種環境下想要快速找到bug的源頭，那將是一個巨大挑戰啊.
這是因為View監聽每一個Model，Model有監聽其他的Model，
所以呢數據可以來自于很多地方又有可能因為可多情況被該改變掉(可能是因為views也可能是因為models)
(數據的改變可能來自于多種情況，很混亂，不可預測)

然后 當 用flux以及它的單向數據流架構，上面的例子就變成這個樣子了
1) 用戶點擊按鈕A
2) 按鈕A的點擊處理函數會dispatch 一個action 出去，然后使 Store "A"接到通知發生改變
3) 用于 dispatch 出去的這個action也會通知其他的store，所以Store”B” 接到通知 也會做出相應的 改變
4) Store "A"，Store”B” 的改變 通知了 View B，使View B 發生重新渲染

所以知道我們如何防止Store A 和 Store B產生直接聯系了吧 ?每一個store的修改只能通過action，
其他任何方式 都不可以的 （所以這樣就阻止你 watch Store A而直接改變Store B）
一旦和這個 acition有關的所有store 的都做出響應的改變
views 最終也被更新了. 所以呢 數據只能沿著下面這條線傳遞:

action -> store -> view -> action -> store -> view -> action -> ...

就像我們的用例是從action開始一樣, 讓我們的教程也從action和創建一個action開始吧

未完待繼續翻譯