前端如何正确使用中间件？

const compose = (middlewares) => {  const reduce = (pre, cur) => {    if (pre) {      return (ctx) => cur(ctx, pre)    } else {      return (ctx) => cur(ctx,  () => ctx)    }  }  return [...middlewares].reverse().reduce(reduce, null);}

const middlware = async (ctx, next) => {  /**   * do something to modify ctx   */  if (/* let next run */true) {    await next(ctx)  }  /**   * do something to modify ctx   */}

• 在下个中间件执行之前做些什么?

• 是否让下个中间件执行？

• 在下个中间件执行之后做些什么？

const handler = compose([(ctx, next) => {
  if (ctx.question === 'hello') {
    ctx.answer = 'hello';
    return
  }
  if (next) [
    next(ctx)
  ]
}, (ctx, next) => {
  if (/age/.test(ctx.question)) {
    ctx.answer = 'i am 5 yours old';
    return
  }
  if (next) [
    next(ctx)
  ]
}])
const ctx = { question: 'hello' };
handler(ctx)
console.log(ctx.answer)  // log hello
ctx.question = 'how about your age?'
handler(ctx)
console.log(ctx.answer) // log i am 5 yours old

• 从支付宝小程序的视角来抹平其他小程序的JSAPI。

  
  

• Bridge拥有扩展能力，能够扩展JSAPI。

因为实在是有太多种不同的请求类型了，因此想实现在相同的入参下，通过adaptor参数来区分最终走怎样的请求逻辑。

fetch.use(commonMiddleware)fetch.use('adaptor-xxx', [middleware]) // 比如adaptor-jsonfetch({ ...requestConfig, adaotpr: 'adaptor-xxx' })

fetch.rpc = () => {}
fetch.mtop = () => {}
fetch.json = () => {}

不同请求实现之间的共享逻辑会不那么直观，说白了就是将中间件前置后置那堆东西拿放到各自的实现中，哪怕是抽了公共函数然后再放到各自函数的实现中，这些共享逻辑都不直观，而中间件那种共享逻辑的处理，可以减少一定的维护成本。

中间件的这种模式，应该作为某个函数的装饰者模式来使用。

the decorator pattern is a design pattern) that allows behavior to be added to an individual object), dynamically, without affecting the behavior of other objects from the same class).

装饰者模式是一个可以在不影响其他相同类的对象的情况下，动态修改某个对象行为的设计模式。

• 装饰器和我们需要扩展的Class都是实现了同一个接口。

• 装饰器是通过接收一个Component对象来运作的。

bridge.API('APINAME', handler)// 或者更加直接的bridge.APINAME = handler

bridge.use(middleware) // 对所有的API生效bridge.use('APINAME', middleware) // 对某个API生效

戳我，下载电子书。