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

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

先說一下webpack，我們知道，前端優(yōu)化有這么幾步，

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

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

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

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

還是單頁應(yīng)用，為了加快第一次加載的速度，我們想如果要是css也能按需加載就好了，我們?yōu)槭裁床挥胘s動態(tài)按需加載css呢，干脆將css和js 寫一起（我們該怎么寫就怎么寫，讓webpack讓他們在一起），加載js就把css 加載了，一條js請求就同時里面包含css。。這樣css的請求也變少了，而且他倆可以一起用gzip壓縮

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

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

我先說一個結(jié)論單向數(shù)據(jù)流要比mvc強(qiáng)好多，
我會在我翻譯的redux教程中詳細(xì)說明

啰嗦這么多開始教程

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

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

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

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

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

Models 就像 stores

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

(view)視圖層 就像 React views

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

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

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

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

所以知道我們?nèi)绾畏乐筍tore A 和 Store B產(chǎn)生直接聯(lián)系了吧 ?每一個store的修改只能通過action，
其他任何方式 都不可以的 （所以這樣就阻止你 watch Store A而直接改變Store B）
一旦和這個 acition有關(guān)的所有store 的都做出響應(yīng)的改變
views 最終也被更新了. 所以呢 數(shù)據(jù)只能沿著下面這條線傳遞:

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

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

未完待繼續(xù)翻譯