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

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

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

単純なメッセージの表示

基本的な通知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>
  );
}

スマートフォンを使用する人の近景。画面に簡単なアラートメッセージが表示されている。

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

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

A plain Alert.alert(title, message) は、基本的な呼び出しで得られるもの

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

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

アラートは小さく、決定的なものにすべきです。ユーザーが長い文章を読む必要がある場合、ダイアログは間違ったUIです。

チームが間違った使い方をする場所

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

もう一つの間違いは、アラートをコンポーネントの内部に密接に結びつけることです。小さなボタンハンドラーは最初は問題ありませんが、フローの範囲が複数の画面と非同期アクションにわたるようになると、アラートの呼び出しが散在していることが推論が難しくなります。そのため、チームは標準化されたUXパターンを早期に標準化する傾向があります。同様に、React Native アプリのスプラッシュスクリーン動作を標準化するのと同じです。単純なアラートの良い使い方.

シナリオ

なぜアラートが効果的か	重要な設定変更後の保存確認
ユーザーが明確な承認が必要	セッションタイムアウトの警告
メッセージは急いでおり、行動を促すものです	アラートは小さく、決定的なものにすべきです。ユーザーが長い文章を読む必要がある場合、ダイアログは間違ったUIです。
非対応機能の注意	アプリが停止して説明する必要があります

ユーザーに選択肢を提示する必要がある場合は、次のステップは 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>
  );
}

各ボタンはオブジェクトです。実際には、3つのプロパティを最もよく使用します:

text はユーザーに表示されるラベルです
onPress タップされたときに実行される。
style iOS では特に、意味を伝える。

誤差を減らすためのボタンラベルの選択

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

比較してみましょう:

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

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

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

どのボタンスタイルが実際に意味するか

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

スタイル	使用するとき	注記
`default`	通常のアクション	中立的な選択肢に適しています
`cancel`	退避または退出	安全な解放のために重要
`destructive`	不可逆のアクション	iOSでは視覚的に強調されます。

iOSはアラートの位置を端末の下部に設定します。 cancel on the right, while Android reverses that. Violating those conventions causes user confusion metrics to spike by confirm 右側に表示される場合、iOSでは反対側に表示されることがあります。Androidではその逆になります。それらの慣習を破ると、ユーザーの混乱率が急上昇します。 25% Gluestack Alert guide 45% Practical rule: every destructive alert should include an explicit way out..

For a more visual walkthrough of button configuration and interaction flow, this short demo is worth a look. iOSでは視覚的に強調されます。

ボタン設定とインタラクションフローの視覚的なウォークスルーについては、この短いデモを見てみる価値があります。

安全な確認パターン

重要なアクションの場合、コールバックを細く保つ

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.');
        }
      },
    },
  ]
);

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

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

プロダクションの一般的なバグは次のようになります。同じ Alert.alert() コールバックはiOSで機能し、Androidで機能し、チームがWebビルドをリリースした後には機能しなくなります。APIはcodeで統一されますが、プラットフォームは一致しません。

React Native開発におけるiOSとAndroidのアラートダイアログのプラットフォーム固有の差異を強調する比較表

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

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

プロンプトのサポートは大きな不一致です。iOSは Alert.prompt 軽量なテキスト入力用の

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' }]
  );
}

Androidのフォールバックは、より不便です。しかし、生産環境では、リダイレクトを実行する専用の画面または制御モーダルは、テスト、ローカライズ、アクセシビリティの観点から、非対応動作を構築した仮想的なポップアップよりも簡単です。

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

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

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

ネイティブのAlertは、モバイル専用のものとして扱うべきです。除外するには、ラッパーを追加する必要があります。

そのラッパーは、プラットフォーム間のハイブリッドランタイムのトレードオフを比較するチームにとって、特に React NativeとCapacitorのアーキテクチャ比較.

シンプルなWebポリフィルパターン

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

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の制御はほとんど与えられない。

ネイティブのアラートダイアログは強いのは、制限があるからである。同じ制限が、すぐにそのツールが正しいものではない理由でもある。

あなたが必要とするものブランド、レイアウトの制御、アイコン、フォームフィールド、カスタムスペーシング、アニメーションのタイミング、クロスプラットフォームの視覚的一貫性, それを API するのをやめろ。

金のロックが白い表面に置かれた複雑な金属時計のギアメカニズムの横に座っている。

ネイティブのアラートは制限がある。 code することはできない。

あなたができないこと Alert.alert() あなたのデザインシステムに似せることはできない。デザインはそのようにしている。React Nativeはレンダリングをオペレーティングシステムに渡すので、ネイティブの外観とネイティブの制約を継承する。

それは、速い確認が必要な場合に良いが、製品がこれらのいずれかを要求する場合に悪い。

ブランドの確認ダイアログ ロゴ、ヘルプテキスト、カスタム階層とともに
モーダル内に複数フィールドのフォーム モーダル内
より豊かな破壊フロー チェックボックスによる承認
評価のリクエストまたはレビュー 星、イラスト、カスタムボタンとともに

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

簡単な決定フィルタ

使用 React Native アラート ダイアログの場合:

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

カスタムモーダルは、モバイルとウェブのビルドが同じ動作を必要とする場合に役立ちます。プラットフォームごとに特別なケースを永遠に管理するのではなく、1つのダイアログコンポーネントを中心に統一し、インタラクションモデルを一貫させます。

Alertが「もう一つのプロパティ」を持つよう願うその瞬間、確かにモーダルが必要だ。

組み込まれた Modal コンポーネントは機能するが、多くのチームは react-native-modal のようなラッパーを選択する。

表示、バックドロップの挙動、動作のアニメーションに関する実用的制御を追加するためである。アクションシート、下部ドロワー、組み込まれた確認パネルなどのフローが似ている場合、特に。デザインがメニューに近い場合、

のようなUIパターンが、Alertを形作ることに集中するのではなく、より適切なメンタルモデルを提供する可能性がある。

React Native アラートの信頼性向上戦略

信頼できるReact Native Alertの生産パターン Alert.alert 実装されていない部分があるため、そこから発生するバグは通常はアーキテクチャの問題であり、API呼び出し自体によるものではない。

アラートを中心化する

Direct Alert.alert(...) 画面をまたいだ呼び出しは、大規模なコードベースでは持たない。1つのコンポーネントがAPIエラーを処理し、別のコンポーネントがナビゲーション確認を求め、3つ目のコンポーネントが認証期限切れを警告する場合、近くに発生したイベントには、1つの場所で順序付け、重複排除、プラットフォームのフォールバックロジックが必要です。

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

実装の多くについては、実践で議論されている実装の約% 30-40% 実装の議論についてのアラート抽象化とダイアログスタッキング実装の議論についてのアラート抽象化とダイアログスタッキングはこの記事で前述したので、ここではリンクを繰り返さないようにしてください。実際の解決策は簡単です。APIを1回だけwrapし、要求をグローバルにキュー化し、レンダラーが正確に1つの表示アラートを責任を持つようにします。

ここにコンパクトな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;
};

UI層は最初のキュー項目にサブスクライブし、正確に1つのダイアログをレンダリングします。ユーザーがそれを閉じると、サービスはそのアイテムを削除し、次のアイテムを表示します。

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

iOSとAndroidでは、ネイティブのアラートはデフォルトの設定が十分です。ウェブ上でカスタムのフォールバックを導入したり、より豊かなコンテンツを表示したり、Androidのプロンプトの置き換えを実行したりすると、システムのダイアログが無料で行っていた動作を所有することになります。

GluestackのReact Nativeアラートのオプションの比較では、カスタムモーダル実装は、期待どおりの読み取り順序を破ることがよくあります。 タイトル → メッセージ → ボタンこの問題は、 60% アクセシビリティの処理をテストしたGluestackのReact Nativeアラートとモーダルアクセシビリティの比較で報告された失敗の例です。

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

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

アラートフローのアクセシビリティの問題は、通常のQAで見落としやすい。キーボードユーザーとスクリーンリーダーユーザーは最初に発見します。

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

ユニットテストは、期待したアラートを要求したかどうかを確認するために、code が期待どおりにアラートを要求したかどうかを確認する必要があります。native dialog runtime に依存してはなりません。

よくあるJestのパターンは次のようになります:

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を推進することにもなります。

クライアントサイドのモニタリングも役に立ちます。既存のチームは、インタラクションのエラーをトラッキングしています。 Sentryを使用するReact Nativeアプリのチームは、明示的なエラー処理と十分なコンテキストでログが記録されたアラートトリガーする__CAPGO_KEEP_0__パスを含むアラート関連の問題を多くキャッチします。 Sentryを使用するReact Nativeアプリのチームは、明示的なエラー処理と十分なコンテキストでログが記録されたアラートトリガーするcodeパスを含むアラート関連の問題を多くキャッチします。

Aプロダクションベースライン

プロトタイプステージを超えたアプリでは、規則の小さなセットを使用します。

Wrap Alert.alert ヘルパーに Wrap web fallback logic
web fallback logic ヘルパーに
一つの場所に ダイアログ要求をグローバルにキュー
一つの時だけ Androidのプロンプトサポートを欠如
モーダルフォールバックを計画するのではなく、遅く分岐するのではなく。 とラベル、コールバック、並べ替えを確認します。
必要な場合にのみカスタムモーダルを使用してください。例えば、ウェブの平等性、入力の促進、より豊かなコンテンツなどです。

ネイティブのアラートが速く動作するようにし、プラットフォームの差異が後で現れるときにコードベースを画策するのを避けます。

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

目次

単純なメッセージの表示

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

チームが間違った使い方をする場所

シナリオ

ユーザー入力を確認する

誤差を減らすためのボタンラベルの選択

どのボタンスタイルが実際に意味するか

安全な確認パターン

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

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

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

シンプルなWebポリフィルパターン

ネイティブのアラートは制限がある。 code することはできない。

簡単な決定フィルタ

React Native アラートの信頼性向上戦略

アラートを中心化する

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

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

Aプロダクションベースライン

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

目次

単純なメッセージの表示

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

チームが間違った使い方をする場所

シナリオ

ユーザー入力を確認する

誤差を減らすためのボタンラベルの選択

どのボタンスタイルが実際に意味するか

安全な確認パターン

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

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

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

シンプルなWebポリフィルパターン

カスタムモーダルを使用する際の注意点

ネイティブのアラートは制限がある。 code することはできない。

簡単な決定フィルタ

カスタムモーダルライブラリとして適切な候補

React Native アラートの信頼性向上戦略

アラートを中心化する

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

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

Aプロダクションベースライン

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