翻译0、1、2、3

Author: shenxl

.idea/encodings.xml

@@ -11,8 +11,22 @@
 // by other framework I tried before. I feel today that Redux is a much better way to learn about flux
 // than many other framework. That's why I want now to share with everyone, using my own words,
 // flux concepts that I am starting to grasp, focusing on the use of Redux.
+// 
+// 为什么开始这个教程？
+// 在学习redux的过程中，我意识到，之前通过阅读文章及个人经验积累的关于FLUX的认识是不正确的。
+// 我并不是说关于FLUX的介绍文章写得不好，而是我不正确把握的概念。
+// 最后，我得到的只是运用不同的FLUX框架（Reflux，Flummox，FB-FLUX），并试图让他们的匹配我所学到的理论概念，
+// （actions、actions creators，store，dispatcher等）。
+// 当我开始使用Redux时，我才意识到，FLUX比我想象的更简单。这一切都归功于Redux被设计得非常好，并已经删除了很多其他框架中
+// 我尝试引进过的“反样板特性”。
+// 现在，比许多其他的框架，我觉得通过Redux去了解FLUX是一个更好的方式。
+// 这就是为什么我要用自己的理解与大家一起分享FLUX概念。我开始尝试重点使用Redxu。
+
+
 
 // You may have seen this diagram representing the famous unidirectional data flow of a flux application:
+// 
+// 您可能已经看到过这个表示Flux的应用单向数据流的著名图表：
 
 /*
                  _________               ____________               ___________ 
@@ -39,20 +53,36 @@
 // to explain this complete diagram and the overall flow it describes, we'll take each piece separately and try to
 // understand why it exists and what role it plays. In the end you'll see that this diagram makes perfect sense
 // once we understood each of its parts.
+// 
+// 在本教程中，我们将逐步向您介绍上图的概念。我们不试图完整的解释图表中数据流的描述，而是
+// 分别介绍每个部件并试图了解它为什么存在，它发挥什么样的作用。
+// 最后，一旦我们了解它的每一个部分，你会看到，这个图是非常合情合理的。
+// 
 
 // But before we start, let's speak a little bit about why flux exists and why we need it...
 // Let's pretend we're building a web application. What are all web applications made of?
 // 1) Templates / html = View
 // 2) Data that will populate our views = Models
 // 3) Logic to retrieve data, glue all views together and to react accordingly to user events,
 //    data modifications, etc. = Controller
+//    
+// 在我们开始之间，我们先聊一下Flux存在的意义以及我们为什么需要它...
+// 假设我们正在构造一个web application.  一般的Web application是由什么构成的呢？
+// 1） Templates / html = View
+// 2) 数据将填充我们的Views = Models
+// 3) 检索数据的逻辑，将所有的View组织起来，并根据用户事件、数据修改做出相应的改变 = Controller   
 
 // This is the very classic MVC that we all know about. But it actually looks like concepts of flux,
 // just expressed in a slightly different way:
 // - Models look like stores
 // - user events, data modifications and their handlers look like
 //   "action creators" -> action -> dispatcher -> callback
 // - Views look like React views (or anything else as far as flux is concerned)
+// 
+// 我们都知道，这是非常经典的MVC模型。但是这个Flux的概念还是有很多相似之处的，只是通过不同的方式表达了出来
+// - Model 很像 stores
+// - 用户事件、数据变更已经他们的处理程序很像"action creators" -> action -> dispatcher -> callback
+// - Views就是React的View(对flux而言，可以是其他任何东西)
 
 // So is flux just a matter of new vocabulary? Not exactly. But vocabulary DOES matter, because by introducing 
 // these new terms we are now able to express more precisely things that were regrouped under 
@@ -61,6 +91,12 @@
 // applications, we were just calling them differently. And instead of having handlers for those
 // actions directly modify Models or Views, flux ensures all actions go first through something called
 // a dispatcher, then through our stores, and finally all watchers of stores are notified.
+// 
+// 那么Flux只是科技人员创造的一个新词汇？这并不准确。但是新的词汇很重要，通过引入这个新词，
+// 我们可以重新集结一些新的术语来进行更准确的表达。举个例子：数据获取不就是一个action吗？就像点击也是一个action一样。
+// 改变输入框中的值也是一个action。既然我们已经习惯了从我们的应用中发起action,我们只是用不同的方式调用他们。
+// 在这些action修改Models或是Views之前，flux确保所有的actions先通过一个被称之为dispatcher的组件，再通过我们的stroes.
+// 最后，所有观察srotes的组件会被通知。
 
 // To get more clarity how MVC and flux differs, we'll
 // take a classic use-case in an MVC application:
@@ -69,23 +105,45 @@
 // 2) A click handler on button "A" triggers a change on Model "A"
 // 3) A change handler on Model "A" triggers a change on Model "B"
 // 4) A change handler on Model "B" triggers a change on View "B" that re-renders itself
+// 
+// 为了举例说明传统的MVC对象模型与Flux有哪些不同，我们来看一个典型的MVC应用程序：
+// 在这个典型模型中，你可以很简单的执行：
+// 1）用户点击按钮“A”
+// 2）在按钮“A”的单击处理程序中，触发了模块（model） “A”的变化
+// 3）模块（model）“A”的变化处理程序中，触发了模块（model）“B”的变化
+// 4）模块（model）“A”的变化处理程序中，触发了视图（View）“B”的重新渲染
 
 // Finding the source of a bug in such an environment when something goes wrong can become quite challenging
 // very quickly. This is because every View can watch every Model, and every Model can watch other Models, so 
 // basically data can arrive from a lot of places and be changed by a lot of sources (any views or any models).
+// 
+// 在这种环境中，当出现问题时查找bug将会变得非常有挑战性。这是因为所有的View都可以观察每个model。
+// 并且每个model也可以观察其他的model。所以基本数据将会从很多地方到达，并在很多代码中产生影响(任何的views或是models).
 
 //  Whereas when using flux and its unidirectional data flow, the example above could become:
 // 1) user clicks on button "A"
 // 2) a handler on button "A" triggers an action that is dispatched and produces a change on Store "A"
 // 3) since all other stores are also notified about the action, Store B can react to the same action too
 // 4) View "B" gets notified by the change in Stores A and B, and re-renders
+// 
+// 在上面的例子中使用Flux及单向数据流后：
+// 1）用户点击按钮“A”
+// 2）按钮“A”的单击处理程序触发一个dispatch的action.并产生对Store“A”的改变
+// 3）由于其他所有的stores都被通知了相关的action.Store“B”也会对相同的action做出响应。
+// 4）View“B”获得StroeA与StoreB的变化通知，并重新渲染
 
 // See how we avoid directly linking Store A to Store B? Each store can only be 
 // modified by an action and nothing else. And once all stores have replied to an action, 
 // views can finally update. So in the end, data always flows in one way: 
 //     action -> store -> view -> action -> store -> view -> action -> ...
+//     
+// 来看一下我们是如何避免Store A直接连接到Store B的？每一个store只能通过action来进行修改。
+// 一旦所有的store相应同一个action后，views就被最终更新。所以一整套流程下来，数据总是单向的
+//    action -> store -> view -> action -> store -> view -> action -> ... 
 
 // Just as we started our use case above from an action, let's start our tutorial with
 // actions and action creators.
+// 
+// 正如我们上面由action开始，让我们也由actions及action creator来开启我们的教程
 
 // Go to next tutorial: simple-action-creator.js

.idea/jsLibraryMappings.xml

@@ -2,45 +2,72 @@
 
 // We started to talk a little about actions in the introduction but what exactly are those "action creators"
 // and how are they linked to "actions"?
+// 
+// 在前言中，我们谈了一些actions的概念，那么究竟什么是“action creators”,他们又是怎么与“action”关联的呢？
 
 // It's actually so simple that few lines of code can explain it all!
+// 
+// 他实际上非常简单，只需要几行代码就可以解释一切了
 
 // The action creator is just a function...
+// 
+// action creator 仅仅是一个function而已..
 var actionCreator = function() {
     // ...that creates an action (yeah the name action creator is pretty obvious now) and returns it
+    // ... 创建（create） 一个 action(当然 action creator的名字就已经很明显了) 并返回他
     return {
         type: 'AN_ACTION'
     }
 }
 
 // So is that all? yes.
+// 仅仅是这些？是的
 
 // However one thing to note is the format of the action. This is kind of a convention in flux
 // that the action is an object that contains a "type" property. This type allow for further
 // handling of the action. Of course, the action can also contain other properties to 
 // pass any data you want.
+// 
+// 有一点要注意的是action的格式。在flux的约定中，action是一个包含 “type”属性的对象。这个“type”属性在action中允许
+// 被进一步处理。当然，action也包含其他属性来传递你需要的数据。
 
 // We'll also see later that the action creator can actually return something else than an action,
 // like a function. This will be extremely useful for async action handling (more on that 
 // in dispatch-async-action.js). 
+// 
+// 后期我们也会发现action creator可以返回除action以外的其他类型，比如function。这个功能在异步处理action时会
+// 显着非常有用(更多信息请参考 dispatch-async-action.js)
 
 // We can call this action creator and get an action as expected:
+// 我们可以调用action creator来得到预期的action
 console.log(actionCreator())
 // Output: { type: 'AN_ACTION' }
 
 // Ok, this works but it does not go anywhere...
 // What we need is to have this action to be sent somewhere so that 
 // anyone interested could know that something happened and could act accordingly.
 // We call this process "Dispatching an action".
+// 
+// 好了，已经正常工作了，但是并没有任何用处...
+// 我们需要的是将这个action发送到对它感兴趣的人那里，让他知道这件事情已经发生了，并做相应的处理。
+// 我们将这个过程称之为"Dispatching an action"。
+// 
 
 // To dispatch an action we need... a dispatch function ("Captain obvious"). 
 // And to let anyone interested know that an action happened, we need a mechanism to register
 // subscribers.
+// 
+// 派发这个动作我们需要一个 dispatch function(“拼写就已经很明显了”)
+// 来让所有对这个动作感兴趣的人知道动作已经发生了。现在我们需要有一套注册订阅者（subscribers）的机制
 
 // So far here is the flow of our application:
 // ActionCreator -> Action
+// 
+// 总结下：目前为止我们的流程是：
+// ActionCreator -> Action
 
 // Read more about actions and action creators here:
+// 在以下链接获取action creators更多的信息
 // http://gaearon.github.io/redux/docs/recipes/ReducingBoilerplate.html
 
 // Go to next tutorial: simple-subscriber.js

.idea/libraries/redux_tutorial_node_modules.xml

@@ -1,20 +1,27 @@
 // Tutorial 2 - simple-subscriber.js
 
 // First things first, let's write a theoretical subscriber
+// 首先，我们先写一个理论上的订阅者
 
 var mySubscriber = function() {
     console.log('Something happened')
     // do something
 }
 
 // Simple isn't it?
+// 很简单是吧
 // It's still not registered anywhere but soon it will be.
+// 目前它仍然没有注册在任何地方，但是很快就可以了。
 
 // And when called, it will do what it was designed for (here just a console.log)
+// 当他被调用时，他将完成在设计时赋予他的动作(例子中仅仅是打印一个 console.log)
 
 mySubscriber()
 
 // So far here is the flow of our application
 // ActionCreator -> Action ... Subscriber
+// 
+// 目前为止 我们应用数据流向为：
+// ActionCreator -> Action ... Subscriber
 
 // Go to next tutorial: about-state-and-meet-redux.js

.idea/watcherTasks.xml

@@ -2,33 +2,60 @@
 
 // Sometimes the actions that we'll handle in our application will not only inform us
 // that something happened but also tell us that data needs to be updated.
+// 
+// 在我们的应用中处理actions，有时不仅需要通知我们发生了，还需要告知我们哪些数据需要被改变。
 
 // This is actually quite a big challenge in any apps.
 // Where do I keep all the data regarding my application along its lifetime?
 // How do I handle modification of such data?
 // How do I propagate modifications to all parts of my application?
+// 
+// 这对任何应用来说都是一个巨大的挑战
+// 我在哪里保持整个程序生命周期的数据？
+// 我要如何处理这些数据的修改？
+// 我怎么将修改传播到应用程序的所有部分？
 
 // Here comes Redux.
+// 于是 Redux 出现了
 
 // Redux (https://github.com/gaearon/redux) is a "predictable state container for JavaScript apps"
+// Redux (https://github.com/gaearon/redux) 是一个“针对JavaScript的应用程序可预见的状态容器”
 
 // Let's review the above questions and reply to them with 
 // Redux vocabulary (flux vocabulary too for some of them):
+// 
+// 让我们回顾一下上面的问题，然后用Redux的词汇回答一下。（flux的词汇跟这个基本一致） 
 
 // Where do I keep all the data regarding my application along its lifetime?
+// 我在哪里保持整个程序生命周期的数据？
 //     You keep it the way you want (JS object, array, Immutable structure, ...).
 //     Data of your application will be called state. Makes sense since we're talking about
 //     all the applications data that will evolve over time, it's really the applications state.
 //     But you hand it over to Redux (Redux is "state container", remember?).
+//     你可以用你希望的形式保存（JS object，array,Immutable structure,）.
+//     应用程序的数据将被称之为state.这是有道理的，因为我们正在谈论的所有应用程序的数据都会随着时间的推移而变化。
+//     它才是真正的application的状态（state）
+//     你把它交给了Redux处理（还记得吧，Redux被称作“状态容器”）
+//     
 // How do I handle modification of such data?
+// 我要如何处理这些数据的修改？
 //     Using reducers.
+//     使用 reducers.
 //     A reducer is a subscriber to actions.
+//     reducers 就是 actions的订阅者。
 //     A reducer is just a function that receives the current state of your application, the action,
 //     and returns a new state modified (or reduced as they call it)
+//     reducers只是一个函数。他接受应用当前的state和action.并返回一个修改过的新state。
+//     （或就像名字里描述的一样 一个减少了的state）
+//     
 // How do I propagate modifications to all parts of my application?
+// 我怎么将修改传播到应用程序的所有部分
 //     Using subscribers to state's modifications.
-
+//     对state的改变使用订阅者
+//     
 // Redux ties all this together for you.
+// Redux将这一切整合起来。
+// 
 // To sum up, Redux will provide you:
 //     1) a place to put your application state
 //     2) a mechanism to subscribe to state updates

00_introduction.js

@@ -47,11 +47,11 @@
 // Here is how it looks like (translated to es5 for readability):
 
 var thunkMiddleware = function ({ dispatch, getState }) {
-    // console.log('Enter thunkMiddleware');
+    console.log('Enter thunkMiddleware');
     return function(next) {
-        // console.log('Function "next" provided:', next);
+       console.log('Function "next" provided:', next);
         return function (action) {
-            // console.log('Handling action:', action);
+            console.log('Handling action:', action);
             return typeof action === 'function' ?
                 action(dispatch, getState) :
                 next(action)