【Vue.js,React】SPA(シングルページアプリケーション)を作る際の3つの注意点(API通信編)

フロントエンドエンジニアとして、Vue.jsやReactを使って、たくさんのSPA(シングルページアプリケーション)を作ってきました。

SPAはAPI通信をして、json形式でデータを受け取り、webブラウザでロジックを構築していく制作方法で、

  • APIとの通信の回数
  • APIとの通信のタイミング
  • APIから取得したデータの持ち方

の設計が非常に複雑です。

そして、この設計の部分を簡潔にわかりやすく構成できるかどうかで、SPAのプロダクトのクオリティが大きく変わってきます。

本日は、わたしがいくつもSPAを作ってきて、体験的に導き出したBestなAPIとの連携の仕方を紹介します。

リロード時(初期表示時)に通信するAPIは2回(理想は1回)にする

SPA制作でやっかいなリロード(初期表示)。

  • 全体で使用するデータ(共通項目)
  • 表示しようとしているページで使用するデータ(個別項目)

を同時にAPIから取得して、表示しなくてはなりません。

例えば、上記のような書籍一覧を表示する本屋さんのWebサイトをSPAで作ろうとした場合、初期ロード時に

  • ヘッダーの中で使われる情報(書籍のジャンル一覧等)
  • サイドバーで使われる情報(最新のお知らせ等)
  • 書籍一覧部分で使われる情報(そのページで表示するべき書籍の一覧・各書籍の詳細情報等)
  • ログインが必要なサイトならば、ユーザー情報(その情報を元に購入済みかどうかを判定できる)

など、複数の情報をAPI越しに取得しなければなりません。

すべての情報を個別のAPIを叩いて取得し、一度のロードで5個も6個もAPI通信をすると

  • どれか1つの通信が失敗したときのハンドリングがめんどくさい
  • 依存情報の扱いが複雑(例:書籍一覧取得APIを使って、書籍一覧のIDだけ取得、そのIDを使って各書籍詳細を取得するAPIを叩く等)
  • ローディングアイコンの表示・非表示のタイミングが判定しづらい

など、SPAがゆえのデメリットが顕著に現れてしまいます。

そのため、

  • ヘッダーやユーザー情報、サイドバーなどの全ページで必要な初期ロード共通API
  • 各ページの情報をすべて盛り込んだ、ページローディング時専用のAPI

の2つだけを初回ロード時(リロード時)に呼び出すと効率よくSPA制作が進められ、バグも減り、リファクタリングもやりやすくなります。

子コンポーネントでAPI通信をしない

先ほどと同じ書籍一覧のサイトで、【書籍情報】を一覧で表示したい場合、

  • 各ページで表示するべき書籍一覧のIDだけ取得するAPI
  • IDから書籍詳細情報を取得するAPI

の2つを組み合わせて、親コンポーネントでID一覧をループで回し、子コンポーネントに書籍IDを渡す。そして、子コンポーネント(上記の図で言うと、赤い【書籍情報】を描写するコンポーネント)内で、親からpropsで渡されたIDを元に書籍詳細情報取得APIを叩いて表示するべき詳細情報を取得する。

という実装をしてしまいがちです。

この実装方法だと、

  • 書籍の数だけAPI通信が増える
  • 親コンポーネントで起こった状態変化を子コンポーネントに渡しづらい

という状況が起こります。

この状況を回避するために、「各ページで表示するべき書籍一覧を取得するAPIのレスポンスの中に、描写したい書籍詳細情報も含む」ことをオススメします。

こうすることで、1つのAPIを叩くだけで、表示するべき全ての情報を取得でき、通信回数を抑えられるだけでなく、子コンポーネントに状態を持たせる必要がなくなり、バグが少ない良いSPAを作る手助けにもなります。

エラーハンドリングとローディング処理を初期の段階からきちんとしておく

SPAの場合、API通信が失敗したときに、画面の一部がおかしな表示になることが多々あります。例えば、書籍一覧の部分だけ、ずっとローディングアイコンがぐるぐる回っていて先に進めない等。

そういった状態になったときに、エンジニアやITリテラシーが高い人ならば、「ああ、リロードしよう」となりますが、あまりITリテラシーが高くないユーザーの場合、「このサイト壊れている!もう使わない」とユーザー離れを引き起こす可能性があります。

そうならないためにも、すべての通信のエラーハンドリングをSPA制作初期の段階からきちんとしておくべきです。

  • 共通で使用するデータを取得する通信がコケた場合、リロードを促す文言を表示する
  • 一部の描写に使用するデータを取得する通信が失敗した場合、再度、通信を行い、それでもダメな場合は、エラー文言を表示する

など、ローディングからのエラーハンドリングまでの一連の流れを、SPA構築初期段階からしっかりと設計しておくと、高品質で使いやすいSPAが出来上がります。

※あとから、エラーハンドリング処理を入れると、その修正がバグを生む可能性もある。また、一度作った部分の修正はエンジニアのモチベーションを下げがち。

すべてはバックエンドエンジニアとの協力が大事

  1. リロード時に通信するAPIは2つまで
  2. 子コンポーネントでAPI通信しない
  3. エラーハンドリングとローディング処理

この3つに注意して、API通信とデータ保持を行えば、シンプルでリファクタリングがしやすく、バグの少ないSPA(シングルページアプリケーション)を構築することができます。

そして、もうお気づきの方もいるかもしれませんが、この状態を作り上げるためには、

  • SPAを作るフロントエンドエンジニア
  • APIを作るバックエンドエンジニア

両者の協力が不可欠です。

大企業での分業体制や、リモートワークでの連絡不足等が原因で、両者の連携がうまくいかずに、こういった状態を作り上げられないことはよく起こる失敗です。

エンジニアリングではなく、コミュニケーションで解決できる課題ですので、億劫にならずにお互いの歩み寄りが良いプロダクトを生むのではないでしょうか!?笑

ABOUTこの記事をかいた人

新卒ノマドエンジニアとして独立し、半年で月収100万円を達成する。フリーランスのエンジニアとして活動しながら、事務所を売却(バイアウト)したり、Youtuber(最高月間視聴回数109万回、チャンネル登録者1万人)をしたり、Openrecの公式配信者としてゲーム生実況をしたり、ベンチャー企業のCOOをしたり、パラレルキャリアを歩んでいる。 2019年にミニマムライフコストを不労所得で稼げるようになったため、いまは好きなことだけ仕事にしています。