API通信待ちのインタラクションの実装レベルを段階別で整理する

SPA時代のAPIのハンドリングは、もはや一般教養みたいなレベルになりつつある。

なんだけど、loadingはこのぐらいできてればいいよね、というのがプロダクトの中で認識されておらず、結果としてエンジニア個々人の誇りによって作られたすごいloadingと、動けばいいや、とりあえず動くからリリースしよう、という惰性の塊みたいなloadingがないまぜになったプロダクトが散見される。そりゃそうだよね、事業価値としてインタラクションのレベルを定義するの難しいもん。そもそもどういうレベルづけすればいいかもわからんし。

てなわけで、API通信に伴うインタラクションに段階をつけてみた。想定挙動としては、API通信を伴う処理をクリックなどをきっかけにトリガーした場合を考えている。これはユーザーが取りうるアクションごとにレベルを確認するといいと思う。

レベル1. ページごと読み込み直す

言わずもがな、API通信などをトリガーするたびに全部やり直しにする挙動。まともには動作する。体験はめちゃくちゃ微妙。もはやSPAではない。でも昔ながらのやり方で、確実。

レベル2. 画面全体にloading表示をする

一応SPAではある。API通信をともなう処理をするたびに操作が完全に停止されるので、体験は結構微妙。loadingの表示が綺麗なら我慢できる。

レベル3. イベントに関連するすべてのオブジェクトが読み込み直され、それぞれにloading表示が発生する

惜しいプロダクトによくある。操作したオブジェクト以外もなぜかloadingし直しになったりするが、依存関係的に親オブジェクトをfetchしなおしたら楽、とかで発生することがある。ユーザー的には「そこ操作してないけど？」って思われるので、レベル2の方が体験としてはマシかも知れない。

レベル4. 影響されるオブジェクトのみがloading表示になる

まともなSPAプロダクトの想定挙動。ボタン押したらボタンだけloading表示になったり、コメント投稿したらそこだけloadingが出たりする。

レベル5. loadingを出さずに画面描画する。通信に失敗した場合のみエラー表示

loadingの話なんだけど、実はloadingを出さないのが良い実装だと思う。というのも、loadingを出すということは待たせているということだからだ。slackなんかを使っているとわかると思うけど、enterした瞬間にAPIの結果を待たずに画面描画される。

このパターンは失敗時のハンドリングを間違えるとユーザーに勘違いを与えるので難易度が高い。APIが戻す結果を予測して先回りしてデータを出したりするので、データ不整合が発生しやすいという開発者的にはキツいデメリットもある。大事なのは失敗時にエラー表示されるか、失敗しても気にならないような処理であること。

レベル6. loadingを出さずに画面描画する。通信に失敗した場合リトライなど取れるアクションを提示

これはベスト。文句なし。

以下、番外編。やらない方がマシシリーズ

レベル 0. API通信してるのにloading出さずに操作不能にする

実装サボると発生する。通信が早いときはまあいいが、遅いとユーザーをものすごく困らせる挙動をしまくるので本当に避けたい。

レベル -1. 通信失敗時にloading出たままになる

ありがち。

レベル -1亜種. loading終わっても実はまだAPI通信してて操作不能

loadingのフラグ管理と、実際のAPIコールのシナリオがズレてると発生する。これもわりとありがち。

レベル -2. 重要な処理で、APIの結果を待たずに処理しているのに、通信失敗時のエラー表示等が一切ない

ユーザーが勘違いしてクレームの原因になるのでやめましょう。