compose 办法
compose 函数定义
compose办法利用数组的 reduce 办法，将多个办法依照肯定的程序组合为一个办法，从而达到一种函数主动有序执行的成果。其中各个办法的执行的程序取决于 reduce 办法如何利用。compose的简略实现如下：
// compose 承受多个函数作为入参 fun1 fun2function compose(...funs){ const len = funs.length // 解决两种非凡状况，函数数量 为 0 || 1 if(!len) return (...arg) => arg if(len === 1) return funs[0] // 以下组合形式 b 办法 会 先于 a 办法执行 return funs.reduce((a,b) => (...arg) => a(b(arg))) // 以下组合形式 a 办法会先于 b 办法执行 // return funs.reduce((a,b) => (...arg) => b(a(arg)))}被组合函数(a,b)的模式
b 函数的返回值为一般的数据，作为a 函数的入参
function b(){ // 如返回值为一般的对象 return {...}}function a(arg){ // arg 数据利用 || 解决 return {...}}依照以上模式的这种模式，a 函数若想利用b函数的返回值，最好事后晓得b函数返回值的数据类型及字段细节,这会导致 a,b 办法之间的耦合重大。
b 返回一个函数，作为 a 函数的入参
function b(){ // 返回值为函数 return (...arg) => { //... }}function a(next){ // next 前置操作 // next() 能够在这里操作 next // next 后置操作 return (...arg) => { // next 前置操作 // next() 能够在这里操作 next // next 后置操作 }}相比上一种模式，这种模式能够使得函数之间达到解偶成果，即函数 a 无需关怀函数 b 的返回值，只有晓得其返回值是一个函数，并在本人认为适合的机会调用即可，这样同时也对函数调用顺序控制，从而达到相似洋葱模型的执行成果。
applyMiddleware 办法
applyMiddleware函数模式
结构闭包，为内部定义的办法，提供外部指定的apis；如下示例
// 承受内部定义的办法数组 funsfunction applyMiddleware(...funs){ const apis = { dispatch: () => ({}) } // 遍历执行 内部定义的办法，结构一个闭包；并将返回值作为 后果返回 return funs.map(fun => fun(apis))}被操作的funs函数模式
为了结构一个闭包，fun 的返回值应该是一个应用了 apis 的函数。
function myMiddleware1(apis){ // 返回一个 办法，该办法中会调用 apis 中裸露的办法，造成一个闭包， return actions => { // apis 办法调用 const { dispatch } = apis dispatch(actions) }}const myMiddlewareWrappers = applyMiddleware(myMiddleware1)// myMiddlewareWrappers 为 [actions => { const { dispatch } = apis; dispatch(actions);}]可能会有疑难：既然只是 apis 内的函数调用，为什么要这么简单，借助闭包实现？调用者间接通过调用 apis 外部的函数不就能达到目标？
闭包的利用：
- 闭包能够使咱们在函数内部管制函数外部的执行逻辑，如常见的防抖、截流函数
- 利用闭包能够实现函数柯里化，从而达到函数入参缓存的成果，进而达到一种单例的成果
为什么不间接调用 apis 外部的办法：
- apis 外部的办法并不是一开始就存在的，可能是动静生成的，通过闭包能够起到1.b 所提到的单例成果
- 通常咱们并不是单纯的函数调用，往往附带着额定的操作，不利用闭包会导致以下成果
function fun1(arg){ console.log(arg) apis.dispatch(arg)}function fun2(arg){ arg.b = 100 apis.dispatch(arg)}// apis 办法的调用可能会随处可见，然而仔细观察，apis 办法的调用其实都是反复的代码比照利用闭包的成果// 没有反复的 apis 外部函数调用，结构的闭包函数会主动执行 apis 外部的办法// apis 裸露了然而没有齐全裸露const results = applyMiddleware(myMiddleware1,myMiddleware1)results[0](100)results[1](200)联合
如何联合 compose 与 applyMiddleware 两个办法，失去魔法成果呢？
首先依据以上定义的 myMiddleware 模式的办法进行思考，间接将 applyMiddleware 失去的 办法列表进行 composeconst myMiddlewareWrappers = applyMiddleware(myMiddleware1, myMiddleware2)// 通过 compose 将 办法列表组合为一个办法const result = compose(...myMiddlewareWrappers)// 此时 result 为何种模式呢？// 依据 compose 的 作用，不难想象 result 为一个函数// actions => myMiddleware1(myMiddleware2(actions))到这里，曾经将 compose 与 applyMiddleware 联合起来了。
然而仔细观察 myMiddleware1、2 函数的模式，会发现一些问题，myMiddleware1、2办法返回值不是一个函数，通过开篇对compose的剖析能够失去，这种模式会带来函数之间 耦合重大 的问题。因而须要对myMiddleware进行一步革新，如下function myMiddleware3(apis){ // 返回一个 办法，该办法中会调用 apis 中裸露的办法，造成一个闭包， // 同时为了 保障 compose 过程中 每个 函数的 入参依然为 一个函数，须要将以下返回值再 // 进行一层封装 return next => actions => { // ... next(actions) // ... }}魔法
然而咱们还是不满足以上的后果，apis 外部函数的调用不在函数调用者手里，即，函数调用者只能传入一个 actions 参数，而无法控制apis 函数的具体执行机会。如何达到管制反转的成果？
actions 其实能够是一个办法，此时就能够通过传参的形式将 apis 再传递给 actions，从而将 apis 控制权交给真正的函数调用者。如下function myMiddleware2(apis){ // 返回一个 办法，该办法中会调用 apis 中裸露的办法，造成一个闭包， return next => actions => { // 管制反转 actions(apis) } } // 能够 联合myMiddleware2 与myMiddleware1 两种模式的函数实现兼容 // 即 调用者须要 管制 apis 时通过 传入函数模式的 actions 即可，否则传入 apis 中指定模式入参即可 function myMiddleware2(apis){ // 返回一个 办法，该办法中会调用 apis 中裸露的办法，造成一个闭包， return next => actions => { // 管制反转 if(typeof actions === 'function') return actions(apis); next(actions) }}