关于前端:redux中的compose与applyMiddleware

10次阅读

共计 3083 个字符，预计需要花费 8 分钟才能阅读完成。

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

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 的返回值，只有晓得其返回值是一个函数，并在本人认为适合的机会调用即可，这样同时也对函数调用顺序控制，从而达到 相似洋葱模型 的执行成果。

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

// 承受内部定义的办法数组 funs
function applyMiddleware(...funs){
  const apis = {dispatch: () => ({})
  }
  // 遍历执行 内部定义的办法，结构一个闭包；并将返回值作为 后果返回
  return funs.map(fun => fun(apis))
}

为了结构一个闭包，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 外部的函数不就能达到目标？

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

为什么不间接调用 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 失去的办法列表进行 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)
 }
}

正文完