redux中connect的使用(3)React/redux中的

前面学习redux始终不得法，经过一段时间,终于搞明白了其中的数据流程，
在这个系列1里面有描述，最近接触到几本javascript模式设计的书，感觉有几个模式似乎在react/redux里面出现了，所以写出来记录一下，遵循设计模式的要求，不断的去修改。这篇文章主要的目的是借模式来理解react/redux的工作原理和数据流程。react/redux框架具体的代码实现模式我没有能力去识别。
有人觉得redux很难学，和我开始处境一样，有人觉得很简单，有丰富编程经验的程序员可能花很短时间就可以了解redux的工作方式，模式是通用的。以我现在的观点，有一点设计模式的知识看这个框架会比较容易，毕竟最终是要解决数据的交互问题。理解数据流动和交互的模式方法，学习任何框架都会简单一点

手绘风格的图😁，很丑。

screenshot_22.png

这是我第一次理解react/redux是脑海里浮现的图，就是一个罐子，这个罐子包装着组件(component),redux中的conatainer,container和redux是有联系的。为什么要这样画呢？要实现中介者模式。

s26722906.jpg

整篇文章参考了几本js设计模式的书，但是以上面的为主，结论性话语都出自这本书
javascript设计模式 英文版 github

我先说两种识别出的最主要的模式：1 mvvm/mvp，2中介者(Mediator); 请对照相关章节查看，中文版的是由tom大叔翻译的，翻译的很好。下面简称js模式书

为什么首先提出中介者模式呢？因为这是我在react/redux构架中观察到的最重要的一种结构模式。
请看js模式书

字典里，中介者是指"协助谈判和解决冲突的中立方"，本书中中介者是一种行为设计模式，他允许我们公开一个统一的接口，系统不同部分可以通过该接口进行通讯。

那么你看到这里面系统是谁，接口是谁呢吗？
请接着js模式书里的描述

如果一个系统的各个组件(本人注释：看组件眼熟吗？)之间看起来有太多的直接关系，也许是时候需要一个中心控制点 ，以便于各个组件通过这个中心控制点来进行通讯。中介者促进松散的耦合方式是：通过这个中心点来处理的，而不是通过组件之间彼此引用。

mediator.png

在我眼里，这张图还不是太完美，你想想看，双十一你买东西，买家给你发货，你收货还不是都是通过淘宝这个统一的接口来进行的吗？

所以最理想的就是把所有的箭头都放到一起，统一和中介者发生链接。这样一来就是我手绘的那张图的意思。

react/redux这个组合中严格贯彻了中介者模式的思想，react自身并不能解决state的问题。或者说解决办法有限(我对flux缺乏了解，不知道他是怎么一种体现)，但是redux为单一state管理提供了解决方法。单一对象在处理复杂数据变化的时候可以协调指挥，不至于交叉变化引用。redux/react结合能处理简单的state变化吗？当然是可以的，中介者可以处理多个委托人的请求，处理一个委托人的请求也不在话下。而且在增加委托者的时候对系统中其他委托者是没有影响的，他们都是独立存在的，只和中介者发生通讯联系。如果用单元测试的方法来测试也很容易。

管理数据，协调分发和接受数据的就是Store这个部分。
组件(委托者)怎么和store发生联系的呢？ 通过connect函数。

拿手机来说，我们操作一个button,希望能执行一个操作，获得一个反馈，这是最简单的交互。这个交互过程要关注： 1 什么操作(发布操作)，2怎么执行操做(具体的逻辑)，3要吩咐操作做什么工作(吩咐厨师做饭，要告诉他做什么，给他一个菜谱，或者叫参数)，4 操作完成以后有怎么让我们知道结果。

处理以上流程的时候有很多种模式，但是考虑到组件的数量和组件之间可能存在的相互之间的交叉数据应用，应该要有一个人统一协调指挥。这个和十字路口的交警是一个道理。这就是中介者模式
以上是我识别出的最重要的一个模式是react/redux中处于核心思想的结构模式。

其实react/redux这里面我认为还隐藏着一个结构模式。这个隐含的架构模式就是MVVM.也可能有人绝对是什么mvc,mvp模式。但是这不重要，模式不是死板固定的，也是为了我们好理解，只要能理解就行。但是如果在框架选型的时候就要考虑的框架之间的微妙之处

React的含义用这本书的书名做解释

s28061237.jpg

react本身就没有什么神秘的，就是一个界面库，说的通俗一点就是web页面，与普通的页面不同的是react的dom元素是通过virtual-dom技术生成的。但是生成以后的dom元素操作方法和普通页面是完全相同的。上面那本社里有实例，在dom渲染完了以后，引入jqueryUI 的autocomplete组件都没有任何问题。

React单独拿出来只能和backbone.js的view层来相提并论。FB也是这么宣传的。如果和backbone.js这样的完整框架来比，还缺点东西。

React缺少backbone.js的model层和viewModel层
如果按照标准的MVVM模式，react/redux也应该有vm层才对。但是这一层还不太好找，在哪里呢？来段代码看看

let nextTodos = todos(state.todos, action);
 let nextVisibleTodoFilter = visibleTodoFilter(state.visibleTodoFilter,
 action);

return {
   todos: nextTodos,
   visibleTodoFilter: nextVisibleTodoFilter
 };

在backbone.js中viewModel负责数据的一些逻辑处理。view层始终是保持一个叫做被动模板的状态，只接受交互和数据，不对数据进行逻辑处理。

react没有这一层。但是在redux的reduxer里面可以完成数据对象的逻辑处理，然后通过combineReducer合并成一个单一的state,传递给react组件。这个可以套用来解释，但是是不是正真的就是mvvm模式,看你怎么理解了。

react/redux中的model又是什么呢？如果非要对号入座那就是state对象了。为了统一协调处理这里就只有一个store,为了数据的协调统一，这里只有一个state

以上是我识别出的两个架构模式，中介者模式是用来解决react界面组件的相互交互的复杂问题。mvvm是用来解决数据的传递问题。
整体的架构模式就是这两个.

下面的开始都是解决一些细节问题。可能有遗漏，慢慢添加。

看redux的文档有这样的描述： store中的state发生改变了以后，组件会根据state的变化来渲染组件。这些组件都是自己渲染自己的，可能是同一个state,但是互补干涉。

组件是怎么感知state的变化的呢？ 简单的例子，中午了，你去麦当劳，人很多，点完餐以后，服务员给你一张号码，告诉你，汉堡好了会通知你。 这就是发布/订阅者模式。pub/suscribe.看代码

 这个新的树就是应用的下一个 state！
所有订阅 store.subscribe(listener)
 的监听器都将被调用；监听器里可以调用 store.getState() 获得当前 state。

这里的pub/subscribe实际和中介者模式一起工作的。

命令模式(Command)模式。实际上这个模式是react/redux里面比较难懂的地方，因为，react中的操作，一下跳到了redux中，不是太好理解。 这里为了设计的方便，把组件的交互操作进行了解耦和，目的是把视觉组件和交互操作逻辑彻底分开来，设计组件和操作逻辑各自改变的时候不会影响到对方。 我前面举过一个例子，手电和拉线开关的电灯。手电的集成度很高，如果要更换灯泡会很难。但是拉线电灯更换灯泡就不会这么难，因为开关，电线和灯泡是分离开的，在灯头上换led，白炽灯不会影响开关的工作，反过来如果我们要把拉线开关换成声控开关也可以，不影响灯泡的工作

Comman模式背后的思想是：为我们提供一种分离职责的手段。实施明智的，简单的命令对象就是把 action动作和调用该动作(实际的操作过程)，绑定起来。我们看代码

//在组件中
let action = TodoActionCreators.addTodo('Use Redux');
   
 return <TodoList todos={todos} dispatch={action} />;

//在redux中，组件你绑定完了，你的活我来干


export function addTodo(text) {
  return {
    type: 'ADD_TODO',
    text
  };
}

//react组件只知道发号命令，redux负责来执行具体的任务

我们单独谈谈react组件的设计模式，这个模式开始还不太好理解，对于组件state和props的设计和享元模式几乎是完全吻合的。

下面看看享元模式(flyweight)

先看定义：享元有两个状态概念，内部和外部，对象中的内部方法需要内部信息，没有内部信息，他们就无法运行，但是外部信息是可以删除或存储在外部的。
这样的好处是：我们能够密切注意已经被实例化的对象，新副本只需要关注与现有对象不同的部分。别说话，看看react组件的state，和props.一个是内部的状态，一个是外部的状态。
Redux中不太好理解的地方这里也算一个。 State是内部状态，react/redux要使用中介者模式来统一处理状态的变化，要把状态放到组件外面去处理，这不是违反了state的定义了吗？ redux为了和react适配，所有有 mapStateToProps()这个函数来吧state转为Props外部状态，这样就可以从外部又回到组件内了。你看这个就是适配器模式(Adaptor).这个模式我还不是太确定，是在刚才修改的时候才想到的

如果现在让我重新学习react/redux，我会选择首先学习设计模式，然后再去学。

这就是从react/redux使用层面和数据流程角度上看到的一些设计模式。希望大家能帮助大家。

2016年12月1日，ver.1.0.0 感言太多，太啰嗦
2016年12月1日，ver.20.0 脱水版，突出主题