web-dev-qa-db-ja.com

角度：HttpとフェッチAPI

AngularがAJAXリクエストを作成する方法を理解していますが、作成するだけでサブスクライブおよびサブスクライブする必要がないため、組み込みのFetch APIを使用することを好みます1つのシンプルなリクエスト。angularアプリで使用してみましたが、エラーが発生せず、ページがリロードされず（SPAのまま）、すべて正常に機能しました。すべてのための時間と場所。

この：

window.fetch('/api/get_post_by_id/1').then(r => r.json()).then(j => { console.log(j); });

これよりも簡単です：

const obs = this.http.get('/api');
obs.subscribe(() => { ... });
obs.unsubscribe();

基本的に私の質問は、Angularアプリを開発するときにFetch APIを使用するのは間違っていますか？

ありがとう！

javascriptangulartypescripthttp
8
ryanwaite28

開発中に遭遇する他のツールと同様に、各ツールには長所と短所があり、ツールが使用されている理由を考えるのは良いことです。

HttpClientを見ると、元々XMLHttpRequestだった混乱を単純化しました。 _$.ajax_が最初にやったのと同じように、HttpClientは「角度のある解決策」でした。それは、すべてが他のオブザーバブルと組み合わせることができる）利点とデメリット（多くの肥大化をもたらす）を持つオブザーバブルであるというイデオロギーに従いました。

HttpClientの利点

  • 2つのオブザーバブルの簡単なミキシングとマッチングが可能です（たとえば、複数回返される1つのオブザーバブルと、1回返されるAPIリクエストがあり、2つを一緒に圧縮したい場合は簡単です）。もちろん、PromiseをObservableに変えるには、fromからrxjsをインポートするだけです。
  • 抽象化の追加を忘れた場合-すべてのリクエストがapiServiceレイヤーを通過する場合でも、インターセプターを使用して同様の結果を魔法のように実現できます。
  • 新しいAngular=開発者の学習曲線が長くなり、仕事がより特別になります。
  • HttpClientは、リクエストの自動再試行などの魔法を実行します。

fetchの利点

重要：フェッチ関連のコードはすべて、非常に単純な抽象化を作成することを前提としています（例：これらの例ではapiService）。これは、HttpClient- landでインターセプターをセットアップするのと同じです。

  • これは新しい業界標準です。一度知ったら、どこでも使用できます（ほとんどの場合、1回Angular and React die-ある時点で-fetchまだ最も可能性が高いです）。
  • RequestおよびResponseオブジェクトは通常のコードで使用しているものと同じであるため、Service Workerとの作業が簡単になります。

  • 通常、HTTPリクエストは1回だけ返されます（もちろん、チャンクごとにファイルをロードすることもありますが、これはルールの非常にまれな例外です）。 fetchは、例外（複数の戻り値）ではなく、標準（単一の戻り値）に基づいて構築されているため、ストリーム型ではなくPromiseを返します。これがもたらす利点は、asyncやawaitなどの関連するすべての新しい言語機能とうまく機能することです。比較：

    _try {
    const posts = await this.apiService.get('/posts');
    // work with posts
} catch (error) {
    // handle error
}
console.log('this happens after the request completes');
_

    と

    _this.http.get('/posts')
    .subscribe(posts => {
        // work with posts
    })
    .catch(error => {
        // work with error
    });
console.log('this happens before the request completes');
_

    （もちろん、完了できる各ObservableをtoPromiseすることもできます（または.pipe(take(1))を追加しますが、それは率直に言って余分なコードの束です（これは今でも頻繁に使用しています））

  • 新しい人のオンボーディングを簡素化します。次のようなリクエストが表示されたら

    _this.apiService.get('/posts');
_

    任意のフレームワークの開発者が来て、_.get_を右クリックし、ドメインや追加される認証ヘッダーなどが明確に定義される関数定義をチェックアウトできます。

    一方、開発者が見たとき

    _this.http.get('/posts')
_

    彼は、Angular特定の魔法に気づかない限り、リクエストが変更される可能性があるかどうか、どこで変更される可能性があるかを簡単に発見する方法はありません。これがAngular急な学習曲線を持つと考えられます。

  • 同じリクエストがサーバー上で4回トリガーされる可能性があるリクエストの自動再試行など、知らない魔法が存在するリスクはありません。

完全なネクタイ

  • 任意のメソッドから戻り値を入力することができるため、型がどのように異なるかを心から見ていません。 <Model>this.apiService.get('/posts')は完全に機能します。

結論

個人的には、抽象レイヤーでfetchを使用することを強くお勧めします。これにより、コードを読みやすくなります（asyncとawaitを見たことのない後輩でも読むことができます）。また、apiServiceは複数回返す必要があります。完全に制御できるため、完全に自由に返すことができます。そして一般的に、代替案が大きな利点を提供する場合にのみ、標準（fetch）を使用するnotのみを行うべきです。長所と短所の点で完璧に結びついていたとしても、おそらく「フレームワーク固有の」ソリューションに行く価値はありません。

HttpClientは、APIリクエストの抽象化レイヤーを設定する必要のない初期プロジェクトのセットアップ中に数分の時間を節約する以上の具体的な利点を提供していないようです。

4
David Mulder
_this.http.get('/api').subscribe(j => console.log(j)); 
_

あなたはそれをあまりにも複雑にしました、上記はあなたが必要とするすべてであり、それはあなたが_window.fetch_のために持っているコードに似ています。ジェネリックバージョンを使用すると、予想されるインターフェイスに入力され、さらに簡単になります。

_this.http.get<IModel>('/api').subscribe(j => console.log(j));
_

unsubscribeは不要です。結果を事前に変換する場合は、pipe + mapのみが必要です。 json()の呼び出しは、（によって技術的に拡張された（古い）HttpModuleに必要でした）HttpClientバージョン4.3以降

PromiseよりもObservableを好む場合は、いつでもtoPromise()を呼び出すことができます。

_this.http.get('/api').toPromise().then(j => console.log(j)); 
_

HttpClient も参照してください

Angularアプリを開発するときにFetch APIを使用するのは間違っていますか？

それは間違っていませんが、それをしない理由があります。 HttpClientを挿入し、さまざまなシナリオ、URL、Http動詞などの包括的な単体テストを作成できます。コード全体で_window.fetch_を使用した場合、同じことを行うのは非常に難しくなります。 HttpClientは、結果に型システムを使用できるという点でも豊富です。オブザーバブルはPromiseよりも機能が豊富であり、複数のマイクロサービスを処理するときの呼び出しの順序付けや、追加のユーザー入力が受信された場合の呼び出しのキャンセルなど、より複雑なシナリオで役立ちます。

したがって、HttpClientを使用する理由は複数ありますが、小さな学習曲線であること以外に、単一の理由を考えることはできません。

7
Igor