Axios: Verwendung von Axios mit TypeScript bei Verwendung von Response Interceptors (AxiosResponse-Problem)

Verwenden Sie die Stildefinition axios.request<T>(...args) .
Der letzte Response-Interceptor im Array entspricht implizit einer Schnittstelle wie (currentResponse: any) => T

Also, wenn Sie data haben, das so etwas wie:

interface ServerResponse {
  data: ServerData
}

interface ServerData {
  foo: string
  bar: number
}

Dann kannst du sagen:

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 eigentlich würde das nicht für globale Abfangjäger funktionieren, zB axios.interceptors.response.use

Ich denke, das tut es - die Abfangjäger sind derzeit sehr "entspannt" getippt (auch bekannt als any ), also können Sie einfach den Antwort-Abfangjäger anhängen und ihn (r: any): any => r.data haben (was im Grunde so ist, als ob Sie es tun würden jegliche Eingabe im nicht-strikten Modus weglassen).

Erst an dem Punkt, an dem Sie axios.request aufrufen, können Sie es generisch konfigurieren, was dann als Typ der Eigenschaft data durchgereicht wird.

(Eigentlich habe ich im obigen Code-Snippet einen Fehler gemacht, data ist eigentlich AxiosResponse<ServerData> , das ein Feld namens .data mit dem Typ ServerData hat - aktualisiert)

@zcei hallo, tut mir leid, aber das funktioniert wirklich nicht mit meinem Beispiel, ich habe eine Codesandbox erstellt, um dieses Problem hervorzuheben.

Schau es dir hier an

Mit dem gleichen Problem kann der Abfangjäger im Wesentlichen auf Folgendes reduziert werden:

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

Trotzdem ist der Rückgabetyp von

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

ist AxiosPromise<string> , was erwartet, dass die Daten umschlossen werden.

Dies ist Absicht. Sie sollen die Daten im Interceptor umwandeln , aber keine Antwortschlüssel heben .

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

Ich dachte, Sie hätten eine Serverantwort wie

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

und wollte die response.data.data Verschachtelung loswerden. Wenn Sie im Interceptor response.data zurückgeben, können Sie später über response.data.foo statt über response.data.data.foo darauf zugreifen.

Aber der Zugriff auf response.foo würde nicht funktionieren, da dies die "Root"-Antwortebene ist, die andere Dinge wie den Antwortcode und dergleichen verfolgt.

Entschuldigung, aber ich stimme Ihrer Prämisse nicht zu, zumindest nicht in Bezug auf die Funktionalität.
Ohne den Interceptor zum Auspacken der Dateneigenschaft zu verwenden, müsste ich tun

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

in _jedem_ Endpunkt, den ich definiere. Was ist der Sinn dieser ganzen Codewiederholung?

Immer wenn eine Anfrage erfolgreich ist, was ein then bedeutet, kümmere ich mich nicht wirklich um den Antwortcode usw. Ich kümmere mich nur um Antwortcodes, wenn etwas _nicht_ funktioniert hat, und dafür sind Fehlerbehandler da , sowohl auf dem Interceptor als auch auf bestimmten Endpunkten.

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

Immer wenn eine Anfrage erfolgreich ist, was ein Dann bedeutet, ist mir der Antwortcode egal

Nun, Sie interessieren sich vielleicht nicht für andere Informationen, aber allen, die einen HTTP-Client verwenden, einzuschränken, dass Sie sich nur um den Text kümmern, ist nicht wirklich eine Lösung.
Es gibt genügend legitime Anwendungsfälle für Statuscodes und Header, selbst bei erfolgreichen Anrufen. Wie z. B. Unterscheidungen 204 und 200 , Überprüfung von Headern für Ratenbegrenzungen, Extrahieren Link -Headern für zusätzliche Ressourcen (Paginierung) usw. pp.

Wenn es Ihnen egal ist, packen Sie Axios ein und werfen Sie alles weg:

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 => { ... });

Ich verstehe nicht, woher Sie die Vorstellung haben, dass jeder die Dinge so machen sollte, wie ich sie in einem Projekt mache. Ich versuche einfach, ein Problem zu lösen, wie Daten bei jeder Anfrage automatisch entpackt werden, und da dieses Problem hier vor mir lag, bin ich nicht der einzige mit diesem Problem.

Abfangjäger _scheinen_ den richtigen Ort dafür zu finden, sowohl nach ihrem Namen als auch nach ihrer Beschreibung in der Readme (mit jeder Antwort etwas tun). Der Umgang 204 vs. 200 usw. und die anschließende Weitergabe der Daten wäre in einem Interceptor ebenfalls sinnvoll, da Sie dies dann an einem zentralen Ort tun können.

Meiner Meinung nach wäre die intuitive Lösung, alles, was Sie wollen, vom Interceptor zurückzugeben, ohne dass die Bibliothek einen einzigen Weg erzwingt.

Wenn Sie einige Felder in Daten transformieren möchten:

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

Wenn Sie die Daten von Axios einfach auspacken möchten:

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

Dies würde dem Entwickler die Wahl überlassen, was zu tun ist, was meiner Meinung nach besser ist als ein sehr eigensinniger Abfangjäger. Es steht Ihnen natürlich frei, anderer Meinung zu sein.

Sie haben über "den Punkt in all dieser Codewiederholung" nachgedacht, also habe ich nur versucht zu erklären, warum die Informationen notwendig sind.

Ich kann nicht wirklich einen Weg finden, wie Sie die Typsicherheit in den Abfangjägern und der Antwort beibehalten möchten, wenn jeder Abfangjäger die gesamte Antwort ohne eine gemeinsame Struktur verschlüsseln könnte. :/
Der Antworttyp für eine Anfrage müsste any werden, denke ich, und die Mühe in die Hände der Entwickler legen, um sicherzustellen, dass sie das Richtige tun.

Das klingt für mich zumindest durch das entspannte Tippen fehleranfälliger, als auf eine Eigenschaft zuzugreifen.

Wenn Sie eine PR entwickeln können, die es Abfangjägern ermöglicht, die Root-Antwort zu überschreiben, während die Typsicherheit für "die 80% Anwendungsfälle" beibehalten wird, wäre ich mehr als glücklich!

Die Sache ist, dass beide oben genannten Beispiele, die ich gemacht habe, bereits so funktionieren, wie ich es beschrieben habe, funktional, es sind nur die Typen, die falsch sind. Wenn etwas anderes als die (geänderte) Antwort im Interceptor falsch zurückgegeben wird, wäre es meiner Meinung nach gut, die erwarteten Typen dort zu aktualisieren.

Zunächst ist es interessant zu wissen, dass Sie dasselbe tun @Etheryte !

In unserer App ist r => r.data der letzte Response-Interceptor in der Kette, und wir verwenden andere, die sich auf Statuscodes verlassen, um Aktualisierungstoken usw. zu handhaben, aber auf globaler Ebene, da wir dies nicht speziell behandeln müssen Anrufe.

Ich verstehe, dass es möglicherweise nicht möglich ist, diesen Anwendungsfall mit TS zu berücksichtigen. @zcei ist jedoch unbestreitbar, dass dies eine legitime Möglichkeit ist, Axios zu verwenden, da es einen offiziellen Teil der Axios-API (Abfangjäger) verwendet :).

Doh! Ich habe mir die ganze Zeit den falschen Code angeschaut 🤦‍♂️ und war im Abschnitt transformResponse , nicht der Abfangjäger - es tut mir so leid!

Wie würden Sie die Eingaben aktualisieren, um zu berücksichtigen, dass der Interceptor den Rückgabetyp ändert?

Vielleicht so etwas?

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

Du würdest es so nennen:

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

Habe das gerade vor Ort ausprobiert und scheint zu tun, wonach Sie suchen.
Vielleicht kann ich abends eine PR zusammen bekommen, um das für alle Methoden zu aktualisieren.

@zcei Das sieht gut aus! Die Standardeinstellung auf AxiosResponse ist natürlich in 99 % der Fälle sinnvoll 👍

Gut zu hören! Nochmals Entschuldigung für meine Verwirrung 😓

@zcei kein Problem! Aus Interesse, wie ist der Release-Zyklus für Axios?

Es gibt keine - ich habe noch einige ausstehende Dinge für die v1 Alpha (#1333) und in der Zwischenzeit machen @nickuraltsev / @emilyemorehouse Releases, wann immer es nötig ist.
Seit v0.18 gab es einige Traktion (einschließlich meines Favoriten: Scoping-Optionen für Instanzen), also denke ich, dass sie eine Veröffentlichung kürzen könnten. Für mehr würde ich Sie einfach freundlicherweise zu Gitter einladen, damit wir die Themen auf den Punkt bringen 🙂

Ich habe gehofft, eine 0.19-Version herauszubringen, aber als ich das letzte Mal nachgesehen habe, hat Master CI nicht bestanden. Ich hätte definitiv gerne einen solideren/regelmäßigeren Veröffentlichungsplan, sobald wir 1.0 landen.

treffe auf das gleiche Problem. Gibt es Lösungen?

@qidaneix Sie könnten versuchen, npm install axios/axios#master zu installieren, bis es eine Veröffentlichung gibt. #1605 hätte es beheben sollen. Wäre schön, ein Feedback zu bekommen, ob das wirklich bei realen Anwendungsfällen hilft und nicht nur bei Tests 🙂

@zcei werde ich morgen ausprobieren

@zcei Darf ich fragen, wann es veröffentlicht wird?

+1 wann 1.0.0 veröffentlicht wird?

Dies wird mit Sicherheit eine Version vor 1.0 sein. @Khaledgarbaya wurdest du auch von Matt zu NPM hinzugefügt? Ansonsten müssen wir nett zu den verbleibenden Betreuern sein, die es veröffentlichen 😉

Hallo zusammen. Ich verwalte derzeit die NPM-Versionen. Ich würde gerne eine weitere Version vor 1.0.0 herausgeben, aber die Travis-Tests schlagen fehl und ich hatte noch keine Gelegenheit, sie zu beheben. Sobald sie behoben sind, bin ich mehr als glücklich, das sofort herauszubringen 😬

@zcei Ich wurde nicht zum npm-Repo hinzugefügt, ich kann nur Änderungen zusammenführen

Gibt es ein Update zu diesem Problem, wird es in naher Zukunft eine Veröffentlichung geben, wie im zweiten Monat?

+1

❤️ wenn das jetzt veröffentlicht werden könnte

Wir sind uns dessen bewusst, aber derzeit blockiert. 🙁 Weitere Informationen erhalten Sie hier: https://github.com/axios/axios/issues/1657#issuecomment -410766031

Veröffentlicht als Teil von 0.19.0-beta.1.

Dies kann mit npm install [email protected] oder npm install axios@next installiert werden

Vielleicht so etwas?

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

Du würdest es so nennen:

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

Habe das gerade vor Ort ausprobiert und scheint zu tun, wonach Sie suchen.
Vielleicht kann ich abends eine PR zusammen bekommen, um das für alle Methoden zu aktualisieren.

Benutzer (T, der erste generische Parameter) scheint nicht verwendet zu werden, wenn ich benutzerdefinierte Rückgabetypen verwenden möchte, sehe ich seltsam aus 😕

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

Die Verwendung von void ist möglicherweise klarer.

@emilyemorehouse Um nicht undankbar zu klingen, aber 0.19-beta ist jetzt seit drei Monaten offen, gibt es eine ETA für eine GA-Veröffentlichung? Unser Projekt hat ein Problem, das eine dieser Korrekturen erfordert. Ich habe das im Gitter-Kanal gefragt, aber anscheinend antworten die Betreuer dort nicht ...

Vielleicht wäre eine bessere Formulierung, welche Probleme vor einer Veröffentlichung gelöst werden müssen, und gibt es einen Ort, an dem sie nachverfolgt werden können? Da das Interesse groß zu sein scheint, könnte es helfen, die Arbeit zu verteilen und ein klares Verständnis der erforderlichen Arbeit zu haben, um die Dinge zu beschleunigen.

Es gibt bereits einen Projektmeilenstein für 0.19, aber die aufgelisteten Tickets haben sich seit mehreren Monaten nicht geändert.

const func1: any = () => { return axios.request(...) }

Ich überschreibe AxiosResponse in meinem axios.d.ts :

import axios from 'axios'

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

Stoßen Sie dieses Problem an. Es funktioniert ... okay, wenn ich gerade die AxiosInstance-Definition in lokale Typisierungen kopiert habe, aber die implementierte Lösung ist meiner Meinung nach sehr ausführlich, es sei denn, ich mache etwas falsch (kein Typescript-Experte). Da ich eine separate Axios-Instanz verwende, die mit axios.create erstellt wurde und diesen Interceptor verwende:

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

wobei response.data immer diese Form hat:

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

es scheint, als müsste ich AxiosClient.post so verwenden:

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

um richtige Typen in .then zu haben. Mache ich hier etwas falsch oder sollte es wirklich so ausführlich sein? Wenn nicht, wäre es viel besser, wenn ich beim Erstellen der Instanz einfach das erwartete Antwortschema übergeben könnte, aber ich kann es nicht zum Laufen bringen:

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

Es funktioniert gut mit axios.create() ohne generischen Typ oder nur axios , aber wenn ich meine Schnittstelle so übergebe:

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

und dann so verwenden: AxiosClient.post<string>('/endpoint').then(value => value.data) , value.data hat type... T. Außerdem funktioniert die obige Version nur, wenn ich diese Typisierungen tatsächlich in node_modules ersetze, sonst wird es total durcheinander und ich mit einer totalen Katastrophe enden. Könnte mir jemand dabei helfen?

Bearbeiten: Okay, ich denke, es wird nicht funktionieren, weil es nicht möglich ist, Generika auf diese Weise zu verwenden (also ist R<T> , wenn R ein generischer Typ ist, keine korrekte Syntax, aber ich denke, WebStorm hat es aus irgendeinem Grund nicht hervorgehoben Es für mich); https://github.com/Microsoft/TypeScript/issues/1213 Ich nehme an, dies würde es lösen, aber keine Ahnung, ob es jemals implementiert wird.

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

verwenden:

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

@zcei Ist das schon gelöst? Ich kann Folgendes nicht zum Laufen bringen:

// 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?

Da ich das gleiche Problem habe, installiere ich Version 0.19beta, auch ts kann den richtigen Typ nicht analysieren

Ich überschreibe AxiosResponse in meinem axios.d.ts :

import axios from 'axios'

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

oh Nipi

Ich benutze Interceptor, um so etwas zu tun: response => response.data . Also muss ich den Wrapper AxiosResponse komplett entfernen.

Endlich komme ich zu folgendem Ergebnis:

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

Falls jemand nicht weiß, wie man es benutzt:

1. Schreiben Sie die Typen irgendwo hin, zB src/types/axios/axios.d.ts .
2. Aktualisieren Sie Ihre tsconfig.json , z

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

Das funktioniert bei mir:

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

eine andere Möglichkeit zu überschreiben

import * as axios from 'axios'

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

Ich denke, wir sollten AxiosResponse vielleicht keine Eigenschaft hinzufügen, wenn wir Abfangjäger verwenden, da Abfangjäger ausgeworfen werden können.

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

Warum verwenden wir Typoskript? weil wir hoffen, dass unser Projekt sicher ist.
Wenn wir eines Tages eine Eigenschaft aus Basis-Utils entfernen, möchten wir, dass der Code, der darauf verweist, zur Kompilierzeit einen Fehler erzeugt.

Wir wollen also, dass use interceptor AxiosResponse eine Eigenschaft hinzufügt und einen Typrückschluss hat, das ist widersprüchlich, weil es keine Möglichkeit gibt sicherzustellen, dass der Typrückschluss aktualisiert werden kann, wenn der Interceptor ausgeworfen wird

Ich denke, Axios sollte dem Benutzer sagen:
Der Interceptor sollte etwas handhaben, das keine Auswirkung auf AxiosResponse hat. Wenn Sie die Eigenschaft AxiosResponse erweitern und Typrückschluss haben möchten, sollten Sie 'plugin' mögen.

// @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)

Es ist keine 100%ige Sicherheit, aber es ist mehr Sicherheit als nur axios.interceptors.response.use zu verwenden

und ich empfehle axios desgin ein plugin system, jetzt sehen wir immer so aus

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

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

Verwenden Sie wie wrapper , um ein Plugin mit Axios zu verbinden, jedes Plugin hat keine gemeinsame Regel, es ist nicht elegant genug. ich denke sollte gefallen

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

Verwenden Sie die Stildefinition axios.request<T>(...args) .
Der letzte Response-Interceptor im Array entspricht implizit einer Schnittstelle wie (currentResponse: any) => T

Also, wenn Sie data haben, das so etwas wie:

interface ServerResponse {
  data: ServerData
}

interface ServerData {
  foo: string
  bar: number
}

Dann kannst du sagen:

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

Bitte können Sie mir sagen, wie ich Header und Konfiguration in der Axios-Anforderung mit tsx hinzufügen kann

@MoZiadAlhafez

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

Aber das ist nicht empfehlenswert

Das ist eine lange Geschichte, scheint aber in #1605 gelöst worden zu sein. Siehe https://github.com/axios/axios/issues/1510#issuecomment -396894600.

Wenn ich etwas falsch verstanden habe, eröffne besser ein neues Thema mit Verweisen auf hier. Danke.