前端優化感想以及[譯]redux 教程 第一部分（共四部分

本身英語通常，水平有限，獻上原文地址，還有我翻譯的中文地址，歡迎你們勘誤

下面是本身的一點感想

先說一下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性能

我以爲性能大數據量高交互的應用，一樣是兩個大牛，分別用react和angular，react會比angular性能好不少。注意個人前提哦，我用了一年半angular，最後仍是被他的髒檢查，傷痛了心，咱們知道一個雙向綁定就表明一個watch，就表明一串髒檢查，當數據一大的時候。。唉。。。

最後是可維護型

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

囉嗦這麼多開始教程

教程 0 -介紹

爲何會有這個教程呢?

當我試着學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  |
                |______________|         |___________|              |_________|

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

可是在開始以前, 讓咱們先聊聊爲啥flux會存在，又爲啥咱們須要它捏?

假設咱們正在開發一個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和flux的不一樣

咱們將在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開始吧

未完待繼續翻譯