是否可以增加全局中间件来替代全局的请求、响应拦截器

[viilon]

希望增加全局中间件功能来替代全局的请求响应拦截器
这样一来代码可以解耦，并且不同功能的中间件可以在不同的alova实例中自由组合，书写代码相对来说更加优雅

[viilon]

const request = createAlova({
    ....,
    middleware: [  // 此处中间件按顺序执行
        middleware1,
        middleware2,
        (next)=>{
            // .... 请求之前操作
            const response = next();  
            // .... 响应之后操作
            return response;
        }
    ]

})

目前全局的请求响应拦截器也算是一种中间件，完全可以用中间件的形式来替代
至于useRequest里面的中间件使用场景太过局限，使用时必须用method套useRequest才能使用，如果想直接使用method发送请求的时候使用中间件，目前为止我觉得是不太现实的。
其次在定义method的时候使用中间件也是一个不错的选择。

[JOU-amjs]

@viilon 这个想法真的很棒，是koa2中的经典洋葱模型，当时在设计useRequest的中间件时也考虑过这种多中间件的设计。

我的结论是，其实初一看是挺优雅和吸引人的，但是我再想下感觉是不划算的。
首先，这个中间接想法主要是用来控制请求前、请求后的动作，但其实现在我们的beforeRequest和responded，就已经实现了这个功能，现在的这个方案可以解决绝大部分需求，因为axios的缘故，用户也很熟悉这套写法，学习成本降低了一些。

其次，中间件设计确实可以很好地解耦，但解耦的设计有很多种，实际上现在的方案，我们也可以把beforeRequest和responded单独成一个对象也算是解耦了，例如我们token认证拦截器的方案。

再其次，想法是真的很棒，找到场景配对上就无敌，毕竟场景不同，设计就不同，需要找到最适合对应场景的设计，例如在某个场景下会产生什么问题，然后我们应该如何设计功能来解决这个问题，从而为用户带来好处（节约时间精力、提高维护性、或原来难以实现的功能实现了之类的），而且必须是具体的问题，例如beforeRequest可以解决请求前统一改参数等，responded可以统一转换数据等，这些为用户带来的好处是方便了很多，再比如alova的useHook的中间件，是为了可以在useRequest/useWatcher/useFetcher的基础上衍生出很多特定场景的请求方案，省掉用户写这些逻辑的时间和精力。

这个全局中间件的方案，它的叠加机制、中间件设计具体能解决什么问题呢，这边好像没有提到，我思考了一下好像也没有想到，那我会认为这个方案是一个只有其表面但没有内含的方案，当然也可能在有对应的场景，我觉得不划算的点就是用现在已知的简单熟悉的方案去换这个未知的好处。

如果这个方案有实际的场景，而且我觉得很有想象空间的话，可能是一个可以考虑的方案，毕竟收益大于现有的才有冒着一点风险更换的价值嘛。

[viilon]

说的也很有道理，我想了一下beforeRequest和responded直接废弃确实有点太激进了。
其次提到的叠加机制我认为可以这样，beforeRequest -> middleware -> responded ，请求前对数据进行转换，再执行中间件，在对返回结果进行转换操作。

再其次我觉得增加全局中间件机制确实是有必要的
上文提到的token拦截器方案，这种方案也确实可以实现类似中间件的功能。但是他是分别分两部分分别套到beforeRequest和responded中的。

我先假设有一个场景
有个实例依赖token认证拦截器方案并且这个实例需要再请求前向服务A上报请求的参数日志，响应后也向服务A上报请求响应的日志
按照目前的写法是

const AlovaA = createAlova({
    beforeRequest: onAuthRequired(method => {
        // 向服务A上报请求的参数日志
        sendRequestLogA(method.data)
    }),
    responded: onResponseRefreshToken((response, method) => {
        // 向服务A上报请求响应的日志
        const data = response.json();
        sendResponseLogA(data);
        return data;
    })
})

如果换成中间件写法

const loggerMiddleware = defineMiddleware((next, method)=>{
    // 请求前向服务A上报请求的参数日志
    sendRequestLogA(method.data);
    const response = next();
    // 响应后向服务A上报请求响应的日志
    sendRequestLogA(response);
    return response;
})

const AlovaA = createAlova({
    middleware: [
        authMiddleware,
        loggerMiddleware,
    ]
})

由此可见代码更加简洁直观而，且中间件可以自由随意组合，最重要的一点请求前和响应后的操作都可以统一在一个方法中处理，而不用分成两部分分别放到beforeRequest和responded。

极端一点 假如请求前和响应后有很多的操作，全都放到beforeRequest和responded中代码势必会越来越乱越来越长，如果采用中间件的方式想加一个中间件直接在配置数组里加上就可以，不想用直接删除。

第二点，如果有多个实例需要同时维护的话，beforeRequest和responded中必定有很多重复的代码；如果使用中间件方式的话，就没有这种问题了，直接指定对应的中间件就可以了。

以上是我的想法，可能在现实的业务场景中没有这么多极端的情况，但我的想法可能大多数都是从代码维护和开发的便利性的点来出发的。这对我们开发人员是相当友好的。

望采纳！

[fangmuke]

洋葱模型的特性真的是 alovajs 所需要的吗？

客户端的库基本上都没有这样做的，更多的应用场景还是在服务端。

[viilon]

useRequest的hook里面有个middleware的配置，也实现了类似于洋葱模型的特征，我的想法不是为了需要洋葱模型而要洋葱模型，，而是想为了更好的整理请求响应拦截器中的重复的代码，以及更好的组合相关的操作