React Native アラートのマスター: API ガイド & ベストプラクティス

あなたがトリガーを押す Alert.alert() React NativeでテストするiPhoneとAndroid、完了感が得られる。すると、誰かがWebビルドを開いて何も表示されない。あるいは、AndroidはiOSで使用したプロンプトフローを無視する。あるいは、2つのアプリが同時にアラートを発射し、ユーザーはダイアログの山に閉じ込められる。

React NativeのアラートはAPIの形をしている。速い、ネイティブの確認フローに適している。ただし、狭く、プラットフォーム依存、そして生産環境で誤用しやすい。幸いなことに、ハッピーパスは簡単で、粗い部分は予測可能である。

Alert.alertを使用したシンプルなメッセージの表示
ユーザー入力を確認ボタンでハンドリングする
プラットフォームの特性と入力プロンプトの扱い方
カスタムモーダル代わりにアラートを使用する場合の判断
信頼性の高いReact Nativeアラートの生産パターン

Alert.alert を使用してシンプルなメッセージを表示する

基本的な通知 UI の場合、 React Native アラート はまだ最速のツールです。 import を呼び出し、 Alert、呼び出し、 Alert.alert()、プラットフォームはネイティブのダイアログをレンダリングします。依存関係の追加、カスタムモーダル状態、スタイリングの作業は必要ありません。

最小限のバージョンでは、タイトルとメッセージだけが必要です:

import React from 'react';
import { View, Button, Alert } from 'react-native';

export default function ProfileScreen() {
  const showSavedMessage = () => {
    Alert.alert('Profile updated', 'Your changes were saved successfully.');
  };

  return (
    <View style={{ padding: 24 }}>
      <Button title="Save profile" onPress={showSavedMessage} />
    </View>
  );
}

スマートフォンを使用する人の近景写真に、画面に表示されるシンプルな警告メッセージが写っています。

このパターンは、ユーザーが意味のある選択をしなくても機能します。例えば、「設定が保存されました」、「セッションが切れました」、「現在は機能が利用できません」などです。ダイアログは流れを妨げるので、ユーザーがすぐに必要な情報を伝えなければなりません。重要な情報だけを伝え、ユーザーに余計な情報を与えないようにしましょう。

基本的な呼び出しで得られるもの

単純な Alert.alert(title, message) nativeなUIを維持するため、便利です。オペレーティングシステムは視覚的なプレゼンテーション、ボタンの役割、標準的なインタラクションパターンを処理します。多くのチームにとって、これは正しい取引です。

実用的なルールがいくつかあります。

直接的なタイトルを使用する「アップロード失敗」は「注意」よりも明確です。
メッセージを短くするアラートは即時のコンテキストのために使用されます。長文の説明ではありません。
ブロッキング情報にのみアラートを予約するユーザーが中断なく続行できる場合、トーストはよく適しています。

アラートは小さく決断的なものでなければなりません。ユーザーが長文を読む必要がある場合、ダイアログは間違ったUIです。

チームが誤用する場所

最も一般的な誤用は、アラートを一般的なメッセージングシステムとして使用することです。成功アクションのすべてがブロッキングダイアログを表示すると、すぐにアプリが重く感じるようになります。nativeアラートは、ユーザーを止める理由があるときに最も強力です。

もう一つの誤用は、アラートをコンポーネントの内部に密接に結び付けることです。小さなボタンハンドラーは最初は問題ありませんが、フローの範囲が画面をまたいで、非同期アクションを含む場合、アラートの呼び出しは散在して、論理を簡単に理解することが難しくなります。そうした理由で、チームは標準化されたUXパターンを早期に標準化することがよくあります。 React Native アプリのスプラッシュ画面の動作.

React Native アプリでシンプルなアラートの良い使い方

シナリオ	Alert の効果的な使用
重要な設定変更後の保存確認	ユーザーが明確な承認が必要
セッションタイムアウトの警告	メッセージは急いでアクションを起こす必要があります
非対応機能の通知	アプリが停止して説明する必要があります

ユーザーが選択する必要がある場合、次のステップは buttons 配列です。その中で Alert.alert() メッセージBOXより多くのものになる。

確認ダイアログの入力ハンドリング

実際のアラートの使用は、情報を伝えることだけではない。決定を求めることだ。ドラフトを削除する、変更を破棄する、サインアウトする、失敗したリクエストを再試行する。そうでなければ、配列は役に立たない。 buttons 一般的な確認ダイアログはこちらです。

写真:男性が赤と緑のボタンを押すと、木のテーブル上のコントロールコンソール。

import React from 'react';
import { View, Button, Alert } from 'react-native';

export default function DangerZone() {
  const confirmDelete = () => {
    Alert.alert(
      'Delete item',
      'This action cannot be undone.',
      [
        {
          text: 'Cancel',
          style: 'cancel',
        },
        {
          text: 'Delete',
          style: 'destructive',
          onPress: () => {
            console.log('Deleting item...');
          },
        },
      ]
    );
  };

  return (
    <View style={{ padding: 24 }}>
      <Button title="Delete item" onPress={confirmDelete} />
    </View>
  );
}

ユーザーに表示されるラベル。

text ボタンがタップされたときに実行される。
onPress iOSでは、特に意味を伝える。
style 誤差を減らすボタンラベルの選択

通常、「OK」と書いて進むことはできる。そうでなければ、ラベルは結果を説明する必要がある。特に破壊的なアクションの場合。

APIは、"OK"と書いて進むことができる。そうでなければ、ラベルは結果を説明する必要がある。特に破壊的なアクションの場合。

比較する2つのセット:

弱いラベルOK / キャンセル
より良いラベル: アイテムを削除 / アイテムを保持

2番目のバージョンは曖昧さを排除します。破壊的なフローでは重要であり、エラーまたは非同期オペレーション後に表示されるアラートではさらに重要です。ボタンテキストは、タップすると何が起こるかを答えるべきです。

ユーザーからテキストを収集するフローがある場合、明示的なフォーム入力と組み合わせることで、クリーンなパターンが得られます。たとえば、 React Native の TextInput の実装ダイアログをオーバーエクステンドするのではなく、

ボタンスタイルは実際に何を意味するか

The style フィールドは意味を持ち、装飾ではありません。意図を伝えるために使用してください。

スタイル	使用するタイミング	注記
`default`	通常のアクション	中立的な選択肢に適している
`cancel`	アプリを終了する	安全なキャンセルに重要
`destructive`	元に戻すことができないアクション	iOSでは強調表示される

Gluestackのノートから、プラットフォームの慣習がここで重要であることを技術的なベンチマークが示しています。iOSでは左側にキャンセルボタンを配置します。 キャンセル ボタン確認右側では、Androidはその逆を実行します。それらの慣習を破ると、ユーザーの混乱度の指標が急上昇します。 25% グローバル市場では、 45% 重要なパスアラートの生産アプリに欠けているのは、必須のキャンセルまたは出口パスです。これにより、不可逆のアクションとサポートのボリュームが増加します。その同じ分析では、カスタムアラート実装がアシスタントテクノロジーの読み取り順序で失敗することも指摘されています。以下の Gluestack アラートガイド.

実践的なルール: 破壊的なアラートには、明示的な出口があるようにすること。

破壊的なアクションの確認パターン

アクションが敏感な場合、コールバックを薄くしてください:

そのパターンは面白くないですが、それが良い理由です。アラートは予測可能でなければなりません。

Alert.alert(
  'Sign out',
  'You will need to log in again to continue.',
  [
    { text: 'Stay signed in', style: 'cancel' },
    {
      text: 'Sign out',
      style: 'destructive',
      onPress: async () => {
        try {
          await signOut();
        } catch (error) {
          Alert.alert('Sign out failed', 'Please try again.');
        }
      },
    },
  ]
);

プラットフォームの特徴と入力プロンプトのナビゲーション

確認の安全なパターン

A production bug looks like this. The same Alert.alert() call works on iOS, works on Android, then fails to function once the team ships a web build. The API looks uniform in code, but the platforms are not.

React Native のアラートダイアログの iOS と Android のプラットフォーム間の差異を比較するグラフ

iOS と Android は完全に一致しません

ボタンの順序が最初にチームが足りないところに当たるのは、ボタンラベルがプラットフォーム間で明確でなければならないためです。 React Native はアラートをオペレーティングシステムに委任するため、ユーザーはネイティブの慣習を、React Native の抽象化ではなく見ることになります。それは通常、正しい取引ですが、ボタンラベルがプラットフォーム間で明確でなければならないことを意味します。

iOSサポートは大きく異なります。 Alert.prompt プラットフォームのチェックを早く行うのではなく、API が一致していることを前提にしない方がいい。

API は一致しているように見せながら、早い段階でプラットフォームをチェックする方が良い。

import { Alert, Platform } from 'react-native';

export function requestPassword() {
  if (Platform.OS === 'ios') {
    Alert.prompt(
      'Enter password',
      'Please confirm your password.',
      [
        { text: 'Cancel', style: 'cancel' },
        {
          text: 'Continue',
          onPress: (value) => {
            console.log('Password entered:', value);
          },
        },
      ],
      'secure-text'
    );
    return;
  }

  Alert.alert(
    'Confirmation required',
    'Please continue to the next screen to confirm this action.',
    [{ text: 'OK' }]
  );
}

Web のサポートには独自の計画が必要です。

React Native の公式のアラート __CAPGO_KEEP_0__ ドキュメントでは、iOS と Android のサポートがリストされています。

React Nativeの公式Alert API ドキュメントでは、iOSとAndroidのサポートがリストされています。 __CAPGO_KEEP_0__React Native Web または Expo Web で実行するアプリでも、警告をunwrapしたままにすると、Web ビルドのインタラクションパス全体で完全な失敗になります (React Native Web の警告サポートに関する議論).

それは、モバイル QA が最初に通過し、ブラウザカバレッジが後で行われるため、チームがそれを遅く発見することが多い、特定のエッジケースではありません。

ネイティブアラートをモバイル専用に扱うようにしてください。除外するには、ラッパーを追加する必要があります。

ラッパーは、プラットフォーム間のハイブリッドランタイムのトレードオフを比較するチームにも役立ちます。これは、特に React Native と __CAPGO_KEEP_0__ のアーキテクチャの比較の場合に特にそうです。 React Native vs. Capacitor architecture comparison.

多くのアプリでは、最初の実行可能な修正は、プラットフォームのスプリットを囲む小さな抽象化です:

このパターンは、即時のサポートのギャップを解決しますが、限界があります。

import { Alert, Platform } from 'react-native';

type ConfirmOptions = {
  title: string;
  message?: string;
  onConfirm?: () => void;
  onCancel?: () => void;
};

export function confirmDialog({
  title,
  message,
  onConfirm,
  onCancel,
}: ConfirmOptions) {
  if (Platform.OS === 'web') {
    const result = window.confirm(message ? `${title}\n\n${message}` : title);
    if (result) onConfirm?.();
    else onCancel?.();
    return;
  }

  Alert.alert(title, message, [
    { text: 'Cancel', style: 'cancel', onPress: onCancel },
    { text: 'OK', onPress: onConfirm },
  ]);
}

このパターンは即時サポートのギャップを解決しますが、限界があります。 window.confirm カスタムモーダルを使用する際の警告ダイアログの使用時期

ネイティブのアラートダイアログは強いのは、制限があるからです。それが同じ制限だから、すぐにそのツールではなくなります。

必要な場合はブランド、レイアウトの制御、アイコン、フォームフィールド、カスタムスペーシング、アニメーションのタイミング、またはクロスプラットフォームの視覚的一貫性, API を使用するのをやめましょう。カスタムモーダルを使用してください。

白い表面に置かれた複雑な金属時計機構と一緒に、金のパッドロックが並んでいます。

ネイティブアラートには制限があります。code することはできません。

見た目が変えられない Alert.alert() ネイティブアラートは、React Native がオペレーティングシステムにレンダリングを任せるため、ネイティブの外観とネイティブの制約を継承します。

これは、速い確認を求める場合に良いでしょう。ただし、製品が以下のいずれかを要求する場合、問題が生じます。

ブランドの確認ダイアログ ロゴ、ヘルプテキスト、カスタム階層を含む
モーダル内に複数フィールドのフォーム モーダル内に複数フィールドのフォーム
A destructive flow with richer functionality チェックボックスによる承認
評価のリクエストまたはレビュー 星、イラスト、カスタムボタンのある評価のリクエスト

それらの要件が表示されると、ネイティブのアラートは死角になる。

簡単な決定フィルタ

使用する React Native アラート ダイアログが次の場合に使用する

ネイティブのAlertを使用する	カスタムモーダルを使用する
短いメッセージ	複雑なコンテンツ
1 から 3 つの基本的なアクション	フォームフィールドまたは埋め込まれたコンポーネント
プラットフォーム固有の見た目は許可される	プラットフォーム間で視覚的一貫性が重要
最速の実装が必要	レイアウトとアニメーション制御が必要

カスタムモーダルは、モバイルとウェブのビルドが同じ動作を必要とする場合に役立ちます。プラットフォームごとにずっと特別なケースを設定するのではなく、1 つのダイアログコンポーネントを中心に据え、相互作用モデルを一貫性を持って維持できます。

Alert に “もう 1 つのプロパティ” が必要だと願う時点で、モーダルが必要になります。

組み込みの Modal コンポーネントは機能しますが、多くのチームはラッパーとして react-native-modal visibility、背景、動画の実用的な制御を追加するため、

特に、行動シート、下部ドロワー、または組み込まれた確認パネルに似たフローでは、 IonicアクションシートシステムのChromeを嫌う設計チームがAlertを形作るのではなく、

信頼性の高いReact Nativeアラートの生産パターン

削除要求が失敗し、リトライハンドラーが発火し、セッションが期限切れのチェックが同時に実行されます。

明確なアラート戦略がなければ、 Alert.alert is not implemented there. Those bugs usually come from architecture, not from the API call itself.

アーキテクチャからではなく、

Direct Alert.alert(...) calls scattered across screens do not hold up in a larger codebase. One component handles an API failure, another asks for navigation confirmation, and a third warns about auth expiry. If those events happen close together, you need ordering, deduplication, and platform fallback logic in one place.

グローバルなアラートサービスはその解決策です。 Redux、 Zustand、または React Context を使用します。ストアの選択は契約よりも重要ではありません。アラートリクエストはキューに入り、同時に 1 つのダイアログがアクティブになり、Web は同じインターフェイスの背後でモーダルベースのフォールバックに切り替えることができます。

開発者はアラート抽象化パターンについて議論している間に、同じ失敗モードを繰り返し指摘しています: 不適切に構造化されたアプリは、ユーザーを捕らえるか、ユーザーが実行する必要があるアクションを隠すために、ダイアログを重ね合わせてしまい、場合によっては約 30-40% 実装に関する議論は、実践で議論されている実装のうちの約実装に関するアラート抽象化とダイアログスタッキングに関する議論 was noted earlier in the article, so do not repeat that link here). The practical fix is simple. Wrap the API once, queue requests globally, and make the renderer responsible for exactly one visible alert.

ここでは、コンパクトなZustandスタイルの形状があります。

type AlertRequest = {
  title: string;
  message?: string;
  buttons?: { text: string; onPress?: () => void; style?: 'default' | 'cancel' | 'destructive' }[];
};

type AlertStore = {
  queue: AlertRequest[];
  push: (alert: AlertRequest) => void;
  shift: () => void;
};

アクセシビリティは実装の一部です。

Gluestack の React Native アラートオプションの比較は、カスタムモーダル実装が

タイトル → メッセージ → ボタン の予想される読み取り順序を破ることが多いことを報告しています。失敗は, でのエラーが報告されました。 60% アクセシビリティの扱いに関するそのベンチマーク (GluestackのReact Native Alert vs Modalアクセシビリティの比較) でその地域に存在する問題です。特定の問題は、ユーザーがダイアログを理解してそれに反応するために予測可能な構造に依存するスクリーンリーダーのユーザーにとって重要です。

カスタムアラートUIの場合、このチェックリストを短く強制することをお勧めします:

ダイアログにフォーカスを移動する ダイアログが開いたとき。
トリガーからフォーカスを戻す ダイアログを閉じた後。
読み取り順序を維持する: タイトル、メッセージ、そしてアクション。
明確なキャンセルパスを提供する, 特に破壊的なフローでは。
アクションを正確にラベルする. 結果が重要な場合、「削除」は「OK」よりも良いでしょう。

アクセシビリティのバグは、通常のQAで簡単に見落とされる。キーボードユーザーとスクリーンリーダーユーザーが最初に発見する。

プラットフォームのダイアログではなく、トリガーをテストする。

code が期待したアラートを要求したことを確認するためのユニットテストは、ネイティブダイアログの実行時間に依存しないようにする。

ユニットテストのパターンは次のようになります。

import { Alert } from 'react-native';

jest.spyOn(Alert, 'alert').mockImplementation(() => {});

it('asks for confirmation before deleting', () => {
  triggerDeleteFlow();

  expect(Alert.alert).toHaveBeenCalledWith(
    'Delete item',
    'This action cannot be undone.',
    expect.any(Array)
  );
});

これは、テスト環境外のダイアログの動作によって引き起こされるハングを防ぎ、ビジネスロジックに焦点を当てるのに役立ちます。また、ウェブとAndroidのプロンプト制限がカスタムフォールバックを強制するようになったら、ラッパーAPIが役立ちます。

クライアントサイドのモニタリングも役に立ちます。既存のチームは、インタラクションのエラーをトラッキングしています。プロトタイプステージを超えたアプリでは、次の小さなルールを使用します。通常、エラートリガーcodeパスを明示的なエラーハンドリングと再現可能なフローを記録するログとラップすることで、より多くのアラート関連の問題をキャッチできます。

ヘルパー関数で囲む

アラート関連の問題を多くキャッチする

アプリの基準を維持する Alert.alert アプリの基準を維持する ウェブのフォールバックロジックは1つの場所にあります。
ダイアログリクエストをグローバルにキューします。 1つのアラートのみが表示されます。
Androidのプロンプトサポートを欠如とみなします。 モーダルフォールバックの代わりに遅く分岐するのではなく、モーダルフォールバックを計画します。
キャンセルアクションを必要とします。 破壊的または不可逆の操作の場合。
テストでアラートをモックします。 ラベル、コールバック、並び順を確認します。
カスタムモーダルを必要とします。ウェブの平行性、プロンプト入力、またはより豊かなコンテンツの場合。

これにより、ネイティブのアラートが速く機能する場所で、プラットフォームの差異が後で現れるときにコードベースを角に追い込まないようにします。

React Native アラートのマスター: API ガイド &amp; ベスト プラクティス

目次