redux基本原理我不想探讨，主要是想说说我在学习redux中的一个思维转变过程。详细的有关redux内容请参考redux文档，新手学习看一两遍不解决任何问题。看个十几遍就够了。里面的todolist的代码我打印了三份，开始像看天书，现在基本懂了。我说了这里有一个思维的转变过程，你的大脑中的神经元要形成connection，这个转变需要时间，经过就学会了，资深程序员估计很容易懂了。我们就谈谈connect 函数.

关于redux的状态和action

redux作为现在开发react-native/react程序的必选框架，理解起来有点复杂，尤其是对于新手而言。基于redux又衍生了一系列的组件，估计2年之内redux和react结合的生态系统都会存在，所以要开发rn-app最好要掌握这个框架。掌握这个框架的历程要从纷繁的代码中理出数据的流程，这一点是最重要的。学习redux代码时刻注意UI当中的操作是怎么导致state发生改变的，state又是怎么回到组件的。简单说就这么一句。UI和Redux是怎么藕断丝连的，理解了这里藕断丝连的比喻，redux-react-native基本就算懂了。可能有人觉得交互操作很神秘，可是其实一点都不神秘，你用过电灯吧，拉线的那种，没拉之前灯是灭的，这是一种状态（old state），你拉一下，灯亮了(new state)，这是另一种状态。反复拉，电灯就在灭--亮两个状态(state)发生改变，这是最简单的状态改变(state)，你拉电灯的线就是一个动作（action）。典型的todo app里面的toggle操作是不是就是这个日常生活的体现？回到电灯的例子，那么电灯的状态是怎么改变的呢？我们知道电灯要亮，需要有电流通过灯泡，所以在导线中我们把它截开来，用拉线开关来控制导线截开的地方是接上，还是断开。拉线开关里面有个棘轮，隔一段有一个铜片，拉一下开关，两边截开的导线通过铜片接上了，电灯有了电流就可以亮了。再拉一下没有铜片，导线接不上，没有电流，灯就灭了。我们再来更进一步说说，那个灯有个灯头，你心血来潮，买了10w,100W,1000W,暖色，冷色，白炽，led,荧光，流星，红色，黄色各种参数的组合的灯泡若干，发现拧上去以后，尽然可以用同样的拉线开关来控制不同灯的亮或者灭。原来开关只控制电流的通断，至于灯的功率，种类，颜色和开关是没有关系的。过一段时间发现灯坏了，好了换一个灯泡就好了也和开关没有关系。好了有人说楼道的灯长时间亮着太费电，冬天天黑的早，常常看不见开关，好吧我们把它换成声控的开关。这个里面的元件有点复杂，里面有个三极管和电容，还有麦克风，通过检测声波来控制导线是接上还是断开，电容是控制连接时间的，有点复杂。以后可以详细讲讲。你看灯的种类变化和开关的种类变化是没有关系的。决定灯的状态的是电流的有无(state)，开关是决定给灯电流还是不给，决定灯的状态是开关的动作（action）。电灯的拉线开关这个实际例子就是使用了模块化的设计，设想如果你把这个电灯换成了集成化很高的led小手电，灯泡和开关的变化还能这么容易吗？这样的分体式设计最终就是我前面讲到的藕断丝连。那么断开的藕之间的丝如果在电灯的例子中可以理解为导线，那么在react-native redux程序中又是谁呢？它就是connect函数。
如果把这个生活中的例子用rn-redux的代码来实现，你现在知道怎么做了吗？下面我在通俗讲一下我理解的connect.注意这都是为了好理解才这么说的，实际代码可能就复杂一点，我们主要集中注意力在数据流程上。

关于connect函数

我这样理解connect. 可以把所有的组件想象为装在一个罐子里（这个罐子是用container来做的），这个罐子有个口，且只有这一个口，罐子里的东西要改变只能通过这个口来实现。这个口就是connect。 redux所有的组件都在罐子外面呆着， reducer是用来改变state，state是什么？state可以说是组件们的粮食，需要的时候redux把粮食投到罐子里。action里是redux和组件们约定的信号。像是古代打仗，摔杯为号。 一旦组件们发了信号，这些信号会通过罐子口(connect),发出来。这些信号一旦和action里的约定匹配，那么外面就会执行reducer这个过程，执行的结果是决定是向罐子里投什么粮食，是米还是面，投多少斤。 这样看来，组件通过container包装以后和redux其实是完全隔绝的，组件只做组件的事情，redux只做redux的事情。 中间的纽带就是connect这个东西。 这样就把组件和行为处理解耦了。 所以redux文档里才说，redux并不一定是专门为react做的。可以是jquery,backbone等等。这个就很好理解了。 应为 罐子(container)里面装什么和罐子外面的东西并没与什么关系。 redux和组件们已经解藕了。 redux和组件之间只需要约定好action和state就可以了。 但是redux似乎偏向于处理state,所以才和react 般配。这种思想实际上在工业和军事中早已使用。举个战斗机的例子， 以前的战斗机上面会有很多仪表，最多的时候有200多个，这200多个仪表实际上每个都链接一个传感器，这些传感器有测量速度的，有测量油温的，有监视雷达的等等，实际数量还要多一倍，为了可靠性的备份。仪表和传感器之间的数据线多如牛毛，每种仪表的交互信号可能还不一样，这样设计和维护，操作都是很大的问题。 80年代以后的战斗机采用了总线技术，所有的传感器都采用数字编码方式，整合到一个数据总线上，交互信号都是约定好的，另一端的仪表都采用显示器来代替，所有的传感器信息都统一显示。 这样在战斗机中的模式有各自为战改为统一管理。 这个流程就是 组件(传感器们)<----connect（数据总线）------>redux(显示器)。看看这个模型，redux其实也没有什么神秘的地方。 实际上UI(用户界面)这个词应该也是美国在上世纪八十年代初设计未来战斗机的时候出现的概念，那个时候pc还在用dos系统呢！还没有图形界面。

f8app的connect怎么和todolist的connect不一样啊

这个很容产生错觉，因为redux文档讲最好有一个单独的组件用container来包装，恰好在redux文档中的connect也是在container里面出现的，所以很容产生的误解是connect 也只有一个。错了，简单的app可以这样写，复杂的app的state,action比较多再这样处理会很麻烦。真相是在你需要的UI组件中导入redux connect函数，接着导入该组件需要的方法和state.redux文档开篇就说只有一个state树，但是如果你的行为是要给一个爱哭的孩子喂一个苹果，只有这样他才会停止哭泣，要改变这个状态，你是不是要把整个苹果树都拔了弄回家呢？不是，我们可以通过一个select函数把苹果摘下来就行了。这样孩子就可以吃到苹果了，他就不会哭了，看看状态改变了。

经过这个思维模式的转变，我现在看世界都是想知道，事情发生的动作(action)是什么，状态（state）是什么？OMG！ 肚子有点饿了，现在要出去改变一下这个state了。那么这个action是什么呢?思考题 :-D。万物皆状态，JS皆对象。后面这一句其实是不准确的，参见《你不知道的javascript 上》。

有时间在写其他的理解吧！