楽観的UIとは何か、いつ使うか

楽観的UIとは、ミューテーションが成功すると仮定し、サーバーからの応答を待つ前にインターフェースを更新するUXパターンです。ユーザーは自分の操作結果をすぐに確認でき、実際のネットワークリクエストはバックグラウンドで実行されます。リクエストが成功すれば何も変わりません。失敗した場合は、UIを元の状態に戻します。

特にモバイルや低速な接続では、ネットワークリクエストによる遅延がアプリを遅く感じさせます。楽観的UIは、この遅延の印象をなくします。いいねボタンはタップした瞬間に切り替わり、項目は追加した瞬間にリストへ表示されます。ネットワークが遅くても、アプリは瞬時に反応しているように感じられます。

楽観的更新は、ミューテーションが成功する可能性が非常に高く、誤った場合の影響が小さいときに適しています。適した例として、いいねやブックマークの切り替え、買い物リストへの項目の追加、設定の更新、ドラッグ＆ドロップリストでの項目の並べ替えなどがあります。いずれも影響が小さく、一時的な不整合が許容される操作です。

楽観的UIは、重要度が高い操作や取り消せない操作には適していません。次の操作には使用しないでください。サーバーの確認前に支払いが成功したように表示する金融取引、レコードの完全な削除、サーバー側の検証が必要なレコードの作成（重複しないユーザー名や招待コードなど）、または誤った成功表示によってデータ破損が起こり得る操作です。

すべての楽観的更新には、ロールバックの計画が必要です。競合、認証エラー、検証失敗、ネットワークタイムアウトなどによってサーバーがミューテーションを拒否した場合、UIを以前の状態に戻さなければなりません。ロールバックを実装しないと、現実の状態を反映しない不整合なUIが残ってしまいます。

楽観的更新が失敗してロールバックされた場合、ユーザーは何が起きたのかを知る必要があります。ベストプラクティスは、問題の内容を説明し、再試行できるようにした控えめなエラートーストまたはインラインエラーメッセージを表示することです。ロールバックは滑らかに行い、ユーザーを混乱させる突然のUIのジャンプは避けます。

スケルトンローダーは、データの読み込みを待つ間にプレースホルダーを表示します。待ち時間をなくすのではなく、何も表示されない状態を感じにくくするものです。一方、楽観的UIは最終状態をすぐに表示することで、待っているという感覚そのものをなくします。スケルトンは初回のデータ取得に、楽観的更新はミューテーションに使用します。両者は異なる問題を解決します。

楽観的UIが機能するのは、ミューテーションの大半が成功するからです。ユーザーがいいねボタンを切り替えると、リクエストは99%以上の確率で成功します。成功するケースを前提に設計し、まれな失敗を適切に処理するほうが、毎回サーバーの確認を待たせるよりもユーザーにとって使いやすくなります。

Twitter、Gmail、Slackなどのアプリで楽観的UIを体験したユーザーは、瞬時に反応することを期待するようになります。操作のたびにローディングスピナーを表示するアプリは、比較すると遅く感じられます。この期待値を設定することは、現代のプロダクト設計の一部です。反応の速いUIは、もはやあれば望ましいという程度の機能ではありません。

場合によっては、ミューテーションの実行中であることを、控えめな不確実性の表示で伝えられます。グレーアウトした状態、項目自体に表示する小さなスピナー（UI全体をブロックしないもの）、または「保存中...」インジケーターを使うと、操作を妨げずに処理が保留中であることをユーザーに知らせられます。これは、完全に楽観的なUIと操作をブロックするローダーの中間的な方法です。

楽観的UIを導入すると、ロールバック用の以前の状態の管理、競合状態への対応、一時IDの調整、失敗の明確な伝達が必要になり、複雑さが増します。頻繁に発生する、リスクの低いミューテーションであれば、このトレードオフには見合う価値があります。一方、失敗時の影響が大きい複雑なミューテーションでは、追加される複雑さがUX上のメリットに見合わない場合があります。

すでにUIで楽観的に表示されたミューテーションをサーバーが拒否した場合、何が起きなければなりませんか？

楽観的UIはサーバーの確認前にインターフェースを更新し、アプリを瞬時に反応しているように感じさせます。影響が小さく成功率の高いミューテーション（いいね、リストへの追加、設定など）に使用します。金融操作、取り消せない削除、サーバー側で一意性の検証が必要な操作には使用しないでください。すべての楽観的更新にはロールバックの計画が必要です。エラートーストで失敗を伝え、再試行できるようにします。大幅に反応性の高いUXを得る代わりに、複雑さが増すというトレードオフがあります。