关于前端: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)
    }
   }