关于后端:Taro框架完美使用Axios

前言

家喻户晓，在 H5 前端开发中，axioshttp 库简直是必选。大部分人都对它的应用十分相熟。然而在小程序开发中，axios怎么没法用，须要应用对应平台提供的 http 接口，如微信小程序的 wx.request，在这时，天然不须要也无奈应用axios，这所有都看似没故障，实则有一大痛点：H5 我的项目基于axios 封装的一些通用类，在小程序开发中不能应用，不同的我的项目不同的框架，可能都要封装一遍，无疑增大保护老本，而且因为封装的成果不统一，团队也存在更多的学习老本。

门面模式

下面的痛点有一种设计模式能够很好的解决，就是设计模式中的 门面模式 或外观模式，在阿里开发手册中就曾提到：

请不要在你的 Java 代码中呈现任何 Log4j 等日志框架的 API 的应用，而是应该间接应用 SLF4J 这种日志门面。

这样做的最大益处，就是业务层的开发不须要关怀底层日志框架的实现及细节，也合乎 依赖倒置准则 的思维，使咱们的程序更加容易保护。

对立 H5 和小程序 http 库

门面模式简略来说就是咱们进行一层封装，咱们本人实现一个相似代理类，在多个不同前端框架中，咱们应用不依赖 axios 的接口，而是依赖咱们的 包装类, 在 H5 环境中咱们包装类代理axios, 在小程序环境中代理wx.request。这样咱们业务层都能够做到对立，对立的api.js，对立的拦挡逻辑等，这思路是没问题，应该不少人这么干了，然而本文并没采纳这种形式封装，因为在我封装的过程中发现一个更简略的形式，看下节~

Axios 适配器

在封装过程中看了下 axios 源码，发现 adapters 这个文件夹，这命名让人一看就想到了 适配器模式 ，事实证明，这正是应用了 适配器模式。如下图，默认有两个适配器的具体实现：

适配器模式 带来的益处和 门面模式 殊途同归，既然 axios 反对自定义适配器，那咱们罗唆将 axios 作为门面，不同的平台实现下适配器进行替换即可，对于 门面外 咱们提供 axios 的 api 作为规范，即可实现各个平台或框架业务层高度对立。

Taro 框架下的 Axios 适配器

这里举荐应用 npm 包：axios-taro-adapter，合乎设计准则中的 优雅准则

开启优雅准则

就和平时应用 Vue 框架一样，装置axios，而后装置适配器axios-taro-adapter

1. npm i axios

2. npm i axios-taro-adapter

   本文为 Gui.H 原创，首发于公众号：dotnet 之美，欢送关注~

而后创立 axios 实例的中央如下：

import {TaroAdapter} from "axios-taro-adapter";

const API_URL = "https://api.xxxx.com/";
const instance = axios.create({
  baseURL: API_URL,
  timeout: 10000,
  adapter: TaroAdapter, // 增加这一行替换默认的适配器
});

当初你就能够齐全专一于 axios，齐全不用晓得Taro.request 是怎么用的，你在 Vue 我的项目中基于 axios 封装的各种库都能够照搬到 Taro 我的项目中来，当然依据咱们的 优雅准则 ，你最好不要间接复制各种通用逻辑代码，而是封装成一个npm 包，通过 npm 来依赖。

总结

通过应用适配器模式完满对立不同平台下 http 库，提供对立的 门面 (这里的门面就是axios) 作为对立的规范，也能够在 Taro 框架中应用 100% 的 axois 库。

本文由 mdnice 多平台公布