Axios: 応答インターセプターを使用するときにTypeScriptでAxiosを使用する方法（AxiosResponseの問題）

axios.request<T>(...args)スタイル定義を使用します。
配列内の最後のResponse-interceptorは、 (currentResponse: any) => Tのようなインターフェイスに暗黙的に準拠しています。

したがって、 dataが次のようなものである場合：

interface ServerResponse {
  data: ServerData
}

interface ServerData {
  foo: string
  bar: number
}

次に、あなたは言うことができます：

axios.request<ServerData>({
  url: 'https://example.com/path/to/data',
  transformResponse: (r: ServerResponse) => r.data
}).then((response) => {
  // `response` is of type `AxiosResponse<ServerData>`
  const { data } = response
  // `data` is of type ServerData, correctly inferred
})

@zcei ooh実際、これはグローバルインターセプターでは機能しません。例： axios.interceptors.response.use

私はそう思います-インターセプターは現在非常に「リラックスした」タイプ（別名any ）なので、応答インターセプターを接続して(r: any): any => r.dataにすることができます（これは基本的には非厳密モードでの入力は省略してください）。

axios.requestを呼び出した時点でのみ、ジェネリックを構成できます。ジェネリックは、 dataプロパティのタイプとして渡されます。

（実際、上記のコードスニペットを間違えました。 dataは実際にはAxiosResponse<ServerData>であり、タイプServerDataの.dataというフィールドがあります-更新しました）

@zceiこんにちは、申し訳ありませんが、これは私の例では実際には機能しません。この問題を強調するためのコードサンドボックスを作成しました。

こちらをチェックしてください

同じ問題があるため、インターセプターは基本的に次のように要約できます。

this.instance.interceptors.response.use(response => response.data);

それにもかかわらず、リターンタイプの

this.instance.post<string>(...);

はAxiosPromise<string>であり、データがラップされることを想定しています。

これは意図的にです。 インターセプターでデータを変換することになっていますが、応答キーを上げることはできません。

https://github.com/axios/axios/blob/0b3db5d87a60a1ad8b0dce9669dbc10483ec33da/lib/core/dispatchRequest.js#L63 -L67

私はあなたが次のようなサーバー応答を持っていると思いました

{
  "data": {
    "foo": 42
  }
}

response.data.dataの入れ子を取り除きたいと思っていました。 インターセプターでresponse.dataを返すと、後でresponse.data.data.foo response.data.fooを介してアクセスできます。

ただし、 response.fooへのアクセスは機能しません。これは、応答コードなどの他のものを追跡する「ルート」応答レベルであるためです。

申し訳ありませんが、少なくとも機能面では、あなたの前提に同意しません。
インターセプターを使用してデータプロパティをアンラップしないと、

this.instance.post<string>(...).then(response => response.data);
this.instance.get<number>(...).then(response => response.data);

私が定義する_every_エンドポイントで。 そのすべてのコードの繰り返しのポイントは何ですか？

リクエストが成功するたびに、つまりthenがある場合は、応答コードなどはあまり気にしません。何かが機能しなかった場合にのみ応答コードを気にします。これがエラーハンドラーの目的です。 、インターセプターと特定のエンドポイントの両方で。

this.instance.interceptors.response.use(response => {
  // Everything went well, pass only relevant data through
  return response.data;
}, error => {
  // Something went wrong, figure out how to handle it here or in a `.catch` somewhere down the pipe
});

リクエストが成功するときはいつでも、それはそれを意味します、私は応答コードを本当に気にしません

さて、あなたは他の情報を気にしないかもしれませんが、あなたが体だけを気にするHTTPクライアントを使用するすべての人に制約することは実際には解決策ではありません。
通話が成功した場合でも、ステータスコードとヘッダーには十分な正当なユースケースがあります。 204と200を区別する、レート制限ヘッダーを確認する、追加のリソース用にLinkヘッダーを抽出する（ページネーション）などのように。

気にしない場合は、Axiosをラップして、すべてを破棄します。

this.instance.request = <T>(...args) => {
  return axios.request<T>(...args).then(({ data }) => data)
}

this.instance.request<string>({ method: 'post', ... }).then(data => { ... });
this.instance.request<number>({ method: 'get', ... }).then(data => { ... });

誰もが1つのプロジェクトで私と同じように物事を行うべきだという考えをどこで得たのかわかりません。 私は単に、リクエストごとにデータを自動的にアンラップする方法の問題を解決しようとしています。この問題が私の前にあったことを考えると、その問題を抱えているのは私だけではありません。

インターセプターは、名前とreadmeでの説明の両方で、それを行うための正しい場所が好きです（すべての応答で何かを行います）。 204と200などを処理してからデータを渡すことも、インターセプターで意味があります。これは、1つの中央の場所で行うことができるためです。

私の意見では、直感的な解決策は、ライブラリに一方向に強制させるのではなく、インターセプターから必要なものを返すことです。

データの一部のフィールドを変換する場合：

this.instance.interceptors.response.use(response => {
  response.data.foo = JSON.parse(response.data.bar);
  return response;
});

Axiosのデータをアンラップするだけの場合：

this.instance.interceptors.response.use(response => response.data);

これは開発者に何をするかの選択を任せます、それは私の意見では非常に強く意見のあるインターセプターよりも優れています。 もちろん、あなたは自由に反対することができます。

あなたは「そのすべてのコードの繰り返しの要点」について推論していたので、私は情報が必要な理由を説明しようとしました。

インターセプターが共通の構造なしで応答全体をスクランブルできる場合、インターセプターと応答で型安全性を維持する方法を実際に見つけることはできません。 ：/
リクエストの応答タイプはanyになる必要があります。私は推測し、開発者が正しいことを行うように努力します。

それは、少なくとも1つのプロパティにアクセスするよりも、タイプが緩和されているためにエラーが発生しやすいように思えます。

「80％のユースケース」の型安全性を維持しながら、インターセプターがルート応答を上書きできるPRを考え出すことができれば、私はとても幸せです。

問題は、私が作成した上記の例は両方とも、私が説明したように、機能的にはすでに機能しているということです。間違っているのはタイプだけです。 インターセプターで（変更された）応答以外のものを返すことが間違っている場合は、そこで期待されるタイプを更新するのが良いと思います。

まず、 @ Etheryteで同じことをしていることを知るのは興味深いことです。

私たちのアプリでは、 r => r.dataがチェーンの最終応答インターセプターであり、更新トークンなどを処理するためにステータスコードに依存する他のものを使用しますが、特定の目的でこれを処理する必要がないため、グローバルレベルで使用します呼び出します。

TSではこのユースケースに対応できない可能性があることを理解しています。 ただし、 @ zceiは、Axios API（インターセプター）の公式部分を使用しているため、これがAxiosを使用するための正当な方法であることは否定できません:)。

ドー！ 私はいつも間違ったコードを見てきました🤦‍♂️そしてインターセプターではなくtransformResponseセクションにいました-ごめんなさい！

インターセプターがリターンタイプを変更することを考慮して、タイピングをどのように更新しますか？

多分このようなもの？

interface AxiosInstance {
  request<T = any, R = AxiosResponse<T>> (config: AxiosRequestConfig): Promise<R>;
}

あなたはそれをこのように呼ぶでしょう：

axios.request<User, string>({
  method: 'get',
  url: '/user?id=12345'
})
  .then((foo: string) => { // <-- you could leave out the type annotation here, it's inferred
    console.log(foo)
  })

ローカルで試してみたところ、探していることを実行しているようです。
たぶん私は夕方に一緒にPRを取得して、すべてのメソッドのPRを更新することができます。

@zceiよさそうだ！ もちろん、デフォルトでAxiosResponseを使用することは、99％の確率で理にかなっています👍

聞いてよかった！ 混乱してすみません😓

@zceiは問題ありません！ 興味深いことに、Axiosのリリースサイクルは何ですか？

何もありません-v1alpha（＃1333）についてはまだ保留中のものがいくつかあり、その間、 @ nickuraltsev / @ emilyemorehouseは必要に応じてリリースを行っています。
v0.18以降、ある程度の牽引力があり（私のお気に入り：インスタンスへのスコープオプションを含む）、リリースを削減できると思います。 詳細については、 Gitterにご招待しますので、問題を適切に保つことができます🙂

0.19リリースを出すことを望んでいましたが、最後に確認したところ、マスターはCIに失敗していました。 1.0がリリースされたら、より確実で定期的なリリーススケジュールを確実に望んでいます。

同じ問題に対応します。 解決策はありますか？

@qidaneixは、リリースが行われるまでnpm install axios/axios#masterをインストールしてみることができます。 ＃1605はそれを修正する必要がありました。 テストだけでなく、実際のユースケースに本当に役立つかどうか、フィードバックをいただければ幸いです🙂

@zcei明日やってみます

@zceiいつリリースされるのか聞いてもいいですか？

1.0.0がリリースされるときに+1？

これは確かに1.0より前のリリースになります。 @KhaledgarbayaもMattによってNPMに追加されましたか？ それ以外の場合は、それをリリースする残りのメンテナに親切にする必要があります😉

やあみんな。 私は現在、NPMリリースを管理しています。 1.0.0より前の別のリリースを発行したいのですが、Travisテストが失敗し、まだ修正する機会がありません。 それらが修正されたら、私はこれをすぐに出すことができてとても幸せです😬

@zcei npmリポジトリに追加されませんでした、変更をマージすることしかできません

この問題に関する更新はありますか？2か月目など、近い将来にリリースされる予定ですか？

+1

❤️これが今リリースされる可能性がある場合

認識していますが、現在ブロックされています。 🙁ここで詳細情報を入手できます： https ：//github.com/axios/axios/issues/1657#issuecomment -410766031

0.19.0-beta.1の一部としてリリースされました。

これは、 npm install [email protected]またはnpm install axios@nextを使用してインストールできます

多分このようなもの？

interface AxiosInstance {
  request<T = any, R = AxiosResponse<T>> (config: AxiosRequestConfig): Promise<R>;
}

あなたはそれをこのように呼ぶでしょう：

axios.request<User, string>({
  method: 'get',
  url: '/user?id=12345'
})
  .then((foo: string) => { // <-- you could leave out the type annotation here, it's inferred
    console.log(foo)
  })

ローカルで試してみたところ、探していることを実行しているようです。
たぶん私は夕方に一緒にPRを取得して、すべてのメソッドのPRを更新することができます。

User（T、最初の汎用パラメーター）は使用されていないようです。カスタムの戻り値を使用したい場合は、奇妙に見えます😕

axios.request<void, string>({
    ...
})

voidを使用すると、より明確になる場合があります。

@emilyemorehouse恩知らずではありませんが、0.19ベータ版が3か月間オープンしていますが、GAリリースのETAはありますか？ 私たちのプロジェクトには、これらの修正の1つを必要とする問題があります。 私はGitterチャンネルでこれを尋ねましたが、メンテナが向こうで応答しているようには見えません...

おそらく、より良い言い回しは、リリース前に解決する必要のある問題は何であり、それを追跡する場所はありますか？ 多くの関心があるように思われるので、作業を広げ、必要な作業を明確に理解することは、物事をスピードアップするのに役立つ可能性があります。

0.19のプロジェクトマイルストーンはすでにありますが、リストされているチケットは数か月間変更されていません。

const func1：any =（）=> {return axios.request（...）}

axios.d.tsのAxiosResponseをオーバーライドします：

import axios from 'axios'

declare module 'axios' {
  export interface AxiosResponse<T = any> extends Promise<T> {}
}

この問題をぶつけます。 それは機能します... AxiosInstance定義をローカルタイピングにコピーしただけで問題ありませんが、（Typescriptの専門家ではなく）何か間違ったことをしていない限り、実装されたソリューションは私の意見では非常に冗長です。 axios.createで作成された別のaxiosインスタンスを使用しており、このインターセプターを使用しているため、次のようになります。

AxiosClient.interceptors.response.use(
  response => response && response.data,
  error => error && error.response && error.response.data
);

ここで、 response.dataは常に次の形式になります。

export interface APIResponse<T = any> {
  data: T;
  message: string;
  status: boolean;
}

次のようにAxiosClient.postを使用する必要があるようです。

AxiosClient.post<EndpointAPIResponse, APIResponse<EndpointAPIResponse>>('/endpoint', { someData });

.thenに適切な型を設定します。 私はここで何か間違ったことをしているのでしょうか、それとも本当に冗長なのでしょうか？ そうでない場合は、インスタンスの作成時に期待される応答スキーマを渡すことができればはるかに良いでしょうが、それを機能させることはできません。

export interface AxiosInstance<R> {
  <T = any>(config: AxiosRequestConfig): Promise<R<T>>;
  <T = any>(url: string, config?: AxiosRequestConfig): Promise<R<T>>;
  defaults: AxiosRequestConfig;
  interceptors: {
    request: AxiosInterceptorManager<AxiosRequestConfig>;
    response: AxiosInterceptorManager<R>;
  };
  getUri(config?: AxiosRequestConfig): string;
  request<T = any>(config: AxiosRequestConfig): Promise<R<T>>;
  get<T = any>(url: string, config?: AxiosRequestConfig): Promise<R<T>>;
  delete<T = any>(url: string, config?: AxiosRequestConfig): Promise<R<T>>;
  head<T = any>(url: string, config?: AxiosRequestConfig): Promise<R<T>>;
  post<T = any>(url: string, data?: any, config?: AxiosRequestConfig): Promise<R<T>>;
  put<T = any>(url: string, data?: any, config?: AxiosRequestConfig): Promise<R<T>>;
  patch<T = any>(url: string, data?: any, config?: AxiosRequestConfig): Promise<R<T>>;
}

export interface AxiosStatic extends AxiosInstance<AxiosResponse> {
  create<T = AxiosResponse>(config?: AxiosRequestConfig): AxiosInstance<T>;
  Cancel: CancelStatic;
  CancelToken: CancelTokenStatic;
  isCancel(value: any): boolean;
  all<T>(values: (T | Promise<T>)[]): Promise<T[]>;
  spread<T, R>(callback: (...args: T[]) => R): (array: T[]) => R;
}

ジェネリック型がなくてもaxios.create()でも、またはaxiosだけでも問題なく動作しますが、次のようにインターフェイスを渡すと次のようになります。

const AxiosClient = axios.create<APIResponse>({
  // ...
});

AxiosClient.post<string>('/endpoint').then(value => value.data) 、 value.dataにはタイプがあります...T。さらに、上記のバージョンは、node_modulesでこれらのタイプを実際に置き換えた場合にのみ機能します。そうしないと、完全に混同されてしまいます。いくつかの完全な災害に終わります。 誰かがこれで私を助けることができますか？

編集：わかりました、ジェネリックをそのように使用することはできないため、機能しないと思います（したがって、Rがジェネリック型の場合のR<T>は正しい構文ではありませんが、何らかの理由でWebStormが強調表示されなかったと思います私にとっては）; https://github.com/Microsoft/TypeScript/issues/1213これで解決できると思いますが、実装されるかどうかはわかりません。

const request = <T>(options: AxiosRequestConfig) => {
    return axios.request<IResponse<T>>(options).then<T>(response => {
        const data = response.data;
        if (data.c !== '0') {
            return Promise.reject(new Error(data.m || 'error'));
        }
        return data.d;
    });
}

使用する：

request<IApiGetBrandGoodsInfoByIds>({
        method: 'GET',
        url: '/api/a/b',
    });

@zceiこれはもう解決されましたか？ フォローを機能させることができません：

// so I created an axios instance:
const instance = axios.create(someOptions);

// then used interceptors
instance.interceptors.response.use((res) => res.data.data);   // server response will always have 'data'

// then when using the following to make a request
instance.get<string>(someURI);  // suppose server response was {data: 'some message'}

// ^^ the above returns type AxiosPromise<string>. How do I get it to return type Promise<string> instead?

同じ問題があり、バージョン0.19betaをインストールします。また、tsは正しいタイプを解析できません

axios.d.tsのAxiosResponseをオーバーライドします：

import axios from 'axios'

declare module 'axios' {
  export interface AxiosResponse<T = any> extends Promise<T> {}
}

ああニウピ

response => response.dataのようなことをするためにインターセプターを使用します。 したがって、 AxiosResponseラッパーを完全に削除する必要があります。

私は最終的に次のようになります：

import axios from 'axios'

declare module 'axios' {
  export interface AxiosInstance {
    request<T = any> (config: AxiosRequestConfig): Promise<T>;
    get<T = any>(url: string, config?: AxiosRequestConfig): Promise<T>;
    delete<T = any>(url: string, config?: AxiosRequestConfig): Promise<T>;
    head<T = any>(url: string, config?: AxiosRequestConfig): Promise<T>;
    post<T = any>(url: string, data?: any, config?: AxiosRequestConfig): Promise<T>;
    put<T = any>(url: string, data?: any, config?: AxiosRequestConfig): Promise<T>;
    patch<T = any>(url: string, data?: any, config?: AxiosRequestConfig): Promise<T>;
  }
}

誰かがそれを使用する方法を知らない場合：

1. タイプをどこかに書き込みます（例： src / types / axios / axios.d.ts） 。
2. tsconfig.jsonを更新します。例：

{
  "compilerOptions": {
    "typeRoots": [
        "./node_modules/@types",
        "./src/types/",
    ]
  }
}

これは私のために働きます：

Api.boards.createBoard = jest.fn((name:string) => {
      const mockBoardResult = {
        created_on: mockBoardData.date,
        name,
        threads: [],
        updated_on: mockBoardData.date,
        _id: mockBoardData._id
      };
      return Promise.resolve({data:mockBoardResult}) as Promise<AxiosResponse<any>>
    });

オーバーライドする別の方法

import * as axios from 'axios'

declare module 'axios' {
  interface AxiosInstance {
    (config: AxiosRequestConfig): Promise<any>
  }
}

インターセプターを使用する場合は、インターセプターをイジェクトでき​​るため、 AxiosResponseにプロパティを追加するべきではないと思います。

// @axios-exts/add-foo-to-resp
declare module 'axios' {
  interface AxiosResponse<T = any> {
    foo: string
  }
}
const addFooToResp = (res: AxiosResponse) => {
  res.foo = 'bar'
  return res
}
export default addFooToResp

// Your Project
import axios from 'axios'
import addFooToResp from '@axios-exts/add-foo-to-resp'

var id = axios.interceptors.response.use(addFooToResp)

axios.get('xx').then(res => {
  // have type defined
  // because we use `declare module 'axios'` ts can infer type
  console.log(res.foo)
})

// but if then eject?
axios.interceptors.response.eject(id)
axios.get('xx').then(res => {
  // also have type defined, it's maybe not reasonable
  console.log(res.foo)
})

なぜtypescriptを使うのですか？ 私たちのプロジェクトが安全に行われることを願っています。
いつかベースutilsからプロパティを削除する場合、それを参照するコードがコンパイル時にエラーを生成するようにします。

したがって、インターセプターを使用してAxiosResponseにプロパティを追加し、型推論を使用する必要があります。これは矛盾しています。インターセプターがイジェクトされたときに型推論を更新できるようにする方法がないためです。

私はaxiosがユーザーに伝えるべきだと思います：
インターセプターはAxiosResponseに影響を与えないものを処理する必要があります。 AxiosResponseプロパティを拡張して型推論を行う場合は、「プラグイン」を使用する必要があります。

// @axios-exts/add-foo-to-resp
declare module 'axios' {
  interface AxiosResponse<T = any> {
    foo: string
  }
}
const addFooToResp = (res: AxiosResponse) => {
  res.foo = 'bar'
  return res
}
export default (axios) => {
  axios.interceptors.response.use(addFooToResp)
}

// Your Project
import axios from 'axios'
import addFooToResp from '@axios-exts/add-foo-to-resp'

addFooToResp(axios)

100％の安全性ではありませんが、 axios.interceptors.response.useを使用するよりも安全です。

そして私はaxiosdesginプラグインシステムをお勧めします、今私たちはいつも次のように見えます

import axios from 'axios'
import wrapper from 'axios-cache-plugin'

let http = wrapper(axios, {
  maxCacheSize: 15
})
export default http

wrapperのように使用して、プラグインをaxiosに接続します。すべてのプラグインに共通のルールはなく、十分にエレガントではありません。 私は好きなはずだと思います

import axios from 'axios'
import axiosCache from 'axios-cache-plugin'

axios.use(axiosCache, {
  // some options
})
export axios

// axios-cache-plugin
export default (axios) => {}
// or
export default {
  install(axios){}
}
// like Vue.use for Vue.js

axios.request<T>(...args)スタイル定義を使用します。
配列内の最後のResponse-interceptorは、 (currentResponse: any) => Tのようなインターフェイスに暗黙的に準拠しています。

したがって、 dataが次のようなものである場合：

interface ServerResponse {
  data: ServerData
}

interface ServerData {
  foo: string
  bar: number
}

次に、あなたは言うことができます：

axios.request<ServerData>({
  url: 'https://example.com/path/to/data',
  transformResponse: (r: ServerResponse) => r.data
}).then((response) => {
  // `response` is of type `AxiosResponse<ServerData>`
  const { data } = response
  // `data` is of type ServerData, correctly inferred
})

plsはtsxを使用してAxiosリクエストにヘッダーと構成を追加する方法を教えてくれます

@MoZiadAlhafez

declare module 'axios' {
  interface AxiosRequestConfig {
    useCache: boolean
  }
}

しかし、これはお勧めしません

これは長い話ですが、＃1605で解決されたようです。 https://github.com/axios/axios/issues/1510#issuecomment-396894600を参照してください。

私が何かを誤解した場合は、ここを参照して新しい問題を開く方がよいでしょう。 ありがとう。