关于前端:redux中的compose与applyMiddleware

compose 办法

compose 函数定义

compose 办法利用数组的 reduce 办法，将多个办法依照肯定的程序组合为一个办法，从而达到一种函数 主动有序执行 的成果。其中各个办法的执行的程序取决于 reduce 办法如何利用。compose 的简略实现如下：

// compose 承受多个函数作为入参 fun1 fun2
function 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) 的模式

1. b 函数的返回值为一般的数据，作为 a 函数的入参

   function b(){
     // 如返回值为一般的对象
     return {...}
   }
   function a(arg){
     // arg 数据利用 || 解决
     return {...}
   }

   依照以上模式的这种模式，a 函数若想利用 b 函数的返回值，最好事后晓得 b 函数返回值 的数据类型及字段细节, 这会导致 a,b 办法之间的 耦合重大。

2. b 返回一个函数，作为 a 函数的入参

   function b(){
     // 返回值为函数
     return (...arg) => {//...}
   }
   function a(next){
     // next 前置操作
     // next() 能够在这里操作 next
     // next 后置操作
     return (...arg) => {
    // next 前置操作
    // next() 能够在这里操作 next
    // next 后置操作
     }
   }

   相比上一种模式，这种模式能够使得函数之间达到 解偶 成果，即函数 a 无需关怀函数 b 的返回值，只有晓得其返回值是一个函数，并在本人认为适合的机会调用即可，这样同时也对函数调用顺序控制，从而达到 相似洋葱模型 的执行成果。

   applyMiddleware 办法

   applyMiddleware 函数模式

   结构闭包，为内部定义的办法，提供外部指定的 apis；如下示例

   // 承受内部定义的办法数组 funs
   function 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 外部的函数不就能达到目标？

3. 闭包的利用：

   1. 闭包能够使咱们在 函数内部管制函数外部 的执行逻辑，如常见的 防抖、截流 函数
   2. 利用闭包能够实现函数柯里化，从而达到 函数入参缓存 的成果，进而达到一种 单例 的成果

4. 为什么不间接调用 apis 外部的办法：

   1. apis 外部的办法并不是一开始就存在的，可能是动静生成的，通过闭包能够起到1.b 所提到的单例成果
   2. 通常咱们并不是单纯的函数调用，往往附带着额定的操作，不利用闭包会导致以下成果

   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 失去的 办法列表进行 compose

   const 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)
    }
   }