前端优化感想以及[译]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和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开始吧

未完待继续翻译