本身英语平常，程度有限，献上原文地点，另有我翻译的中文地点，迎接人人订正
下面是本身的一点感受
先说一下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最先吧
未完待继承翻译
