React Native でアラートをトリガーする Alert.alert() React Native では、iPhone と Android でテストし、完了と感じる。すると、誰かが Web ビルドを開き、表示されない。あるいは、Android は iOS で使用したプロンプト フローを無視する。あるいは、2 つのアプリのパーツが同時にアラートを発火し、ユーザーがダイアログの乱雑なスタックに閉じ込められる。
That’s the shape of the React Native Alert API. It’s great for fast, native confirmation flows. It’s also narrow, platform-bound, and easy to misuse in production. The good news is that the happy path is simple, and the rough edges are predictable once you know where they are.
目次
- 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) は便利です。 それはネイティブなままです。 オペレーティングシステムは視覚的なプレゼンテーション、ボタンの役割、標準のインタラクションパターンを処理します。 多くのチームにとって、それが正しい取引です。
いくつかの実用的ルールが、有用なままにするのに役立ちます:
- タイトルは直接的なものを使用すること. “アップロード失敗”は、「通知」よりも明確です。
- メッセージを短く保つ. アラートは即時のコンテキストに適していますが、長文の説明ではありません。
- アラートはブロッキング情報にのみ使用する. ユーザーが中断なく続行できる場合、トーストはよく適しています。
アラートは小さく決断的なものに保つ。ユーザーが長文を読む必要がある場合、ダイアログは間違ったUIである可能性があります。
チームが誤用する場所
最も一般的な誤用は、アラートを一般的なメッセージングシステムとして使用することです。成功アクションのすべてがブロッキングダイアログを表示する場合、アプリはすぐに重くなります。ネイティブアラートは、ユーザーを止める理由がある場合に最も強力です。
もう一つの誤用は、アラートをコンポーネントの内部に密接に結び付けることです。小さなボタンハンドラーは最初は問題ありませんが、フローの範囲が複数の画面と非同期アクションにわたる場合、アラートの呼び出しが散在することで、推論が困難になります。そのため、チームは標準化されたUXパターンを早期に標準化する傾向があります。同様に、React Native アプリのスプラッシュスクリーン動作を標準化する 単純なアラートの良い使用例.
シナリオ
| Scenario | Alertの機能 |
|---|---|
| 重要な設定変更後の確認保存 | ユーザーは明確な承認が必要 |
| セッションタイムアウト警告 | メッセージは緊急でアクション指向 |
| 非対応機能の通知 | アプリは停止し説明する必要があります |
ユーザーに選択肢を提示する必要がある場合、次のステップは buttons 配列です。 その時 Alert.alert() は単なるメッセージBOXより
ユーザーからの入力を確認するためのボタン
実際のAlertの使用はほとんど情報提供ではなく、決定です。 ドラフトを削除、変更を破棄、サインアウト、失敗したリクエストを再試行する。 その時 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そのボタンがタップされたときに実行される関数です。styleiOSでは、特に意味を伝えるために使用されます。
誤差を減らすためのボタンラベルの選択
The API lets you write “OK” and move on. That’s usually not enough. The label should describe the outcome, especially for destructive actions.
これら2つのセットを比較してみましょう。
- 弱いラベル: OK / Cancel
- より良いラベル: 削除 / 保持
2 番目のバージョンは曖昧さを排除します。破壊的なフローでは重要であり、エラーまたは非同期オペレーション後に表示されるアラートではさらに重要です。ボタン テキストは、タップすると何が起こるかを答えるべきです。
ユーザーからテキストを収集するフローがある場合、明示的なフォーム入力と組み合わせる clean companion パターンは、専用の React Native TextInput の実装 ダイアログをオーバーエクステンドするのではなく、試みるのではなく
どのボタン スタイルが実際に意味するか
The style フィールドは意味を伝えるために使用するべきです。装飾ではありません。
| スタイル | 使用するとき | ノート |
|---|---|---|
default |
通常のアクション | 中立的な選択肢の場合に適しています |
cancel |
iOS または Android から退出する | 安全な解決策のために重要 |
destructive |
取り消しできないアクション | iOS では強調表示されます |
Gluestack のノートから技術的なベンチマークによると、プラットフォームの慣習がここで重要です。iOS では左側にキャンセルボタン、右側に確認ボタンを配置し、Android ではその逆になります。慣習を破ると、ユーザーの混乱率が世界市場で急上昇します。 キャンセル 左側に配置 右側に配置 100% 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.');
}
},
},
]
);このパターンは面白くないですが、それが良い理由です。アラートは予測可能でなければなりません。
プラットフォームの特徴と入力プロンプトのナビゲーション
生産アプリの一般的なバグは次のようになります。同様の Alert.alert() コールはiOSで機能し、Androidで機能し、チームがWebビルドをリリースした後、機能しなくなります。APIはcodeで統一されますが、プラットフォームはありません。
iOSとAndroidは完全に一致しません。
ボタンの順序は、チームが最初に足を引っ掛ける場所です。React Nativeはアラートをオペレーティングシステムに委任するため、ユーザーはネイティブの慣習を、React Nativeの抽象化ではなく見ることになります。そのことは通常正しい取引ですが、ボタンラベルの不明確さを跨ぐ必要があることを意味します。
プロンプトのサポートは、より大きな不一致です。iOSは軽量のテキスト入力用に Alert.prompt をサポートしています。
Androidはサポートしていません。フローがアラート内でパスワードを入力する、アイテムを再命名する、または短いメモをキャプチャする必要がある場合、そのフローはiOS専用のものになります、除いて、別のパスを作成することによって。
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' }]
);
}プラットフォームのチェックを早く行うのではなく、APIが一致していることを仮定するのではなく。
Androidのフォールバックは、より不便です。でも、まだ安全な選択肢です。生産環境では、リダイレクトを使用して、専用の画面または制御モーダルにアクセスするのではなく、サポートされていない動作を中心に作られた偽のプロンプトよりも、テスト、ローカライズ、そしてアクセシビリティが容易になります。
React Native’s official Alert API documentation lists support for iOS and Android in the React Nativeの公式なAlert__CAPGO_KEEP_0__ドキュメントは、iOSとAndroidのサポートをにリストしています。React Native Alertのリファレンス。).
. ただし、React Native WebまたはExpo Webでもアプリが実行される場合、アラートをwrapしないと、Webビルドのそのインタラクションパスで完全に失敗します（アラートのサポートに関するReact Native Webの問題の議論）。 これは、特に、モバイルQAが最初に通過するため、チームがそれを遅く発見することが多い、特に多いエッジケースではありません。
ネイティブのアラートは、ラッパーを追加しない限り、モバイル専用として扱います。
ラッパーは、特にプラットフォーム間のハイブリッド実行時間のトレードオフを比較するチームにとって、さらに役立ちます。 React Native vs. Capacitor architecture comparison.
シンプルな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 ほとんどの制御権を与えず、フォーカス動作、分析ハック、またはモバイルとWeb間で一貫した動作を必要とするフローの場合、簡単な確認に適した安全ネットとして機能しますが、最終的な答えではありません。
カスタム モーダルを使用する際のアラートの使用時期
ネイティブのアラート ダイアログは強いのは、制限があるからです。同じ制限が、すぐにネイティブのアラートは適切なツールではない理由でもあります。
必要なものが ブランド、レイアウトの制御、アイコン、フォーム フィールド、カスタム スペーシング、アニメーションのタイミング、またはクロス プラットフォームの視覚的一貫性、API に対して戦うのをやめましょう。カスタム モーダルを使用してください。
Native alert limits you can’t code around
あなたは Alert.alert() あなたは
あなたのデザインシステムのようになりたいと思っても
- それは意図的にそうです。 React Native は、ハンドリングをオペレーティングシステムに委託しているため、ネイティブの外観とネイティブの制約を継承します。 それは、確認の迅速化を望む場合に良いことですが、製品が次のいずれかの要件を求める場合に悪いことです。
- ブランドの確認ダイアログ ロゴ、ヘルプテキスト、カスタム階層とともに
- モーダル内に複数フィールドのフォーム 破壊的なフロー
- チェックボックスの確認とともに 星やイラスト、カスタムボタンとともに
その要件が出現すると、ネイティブのアラートは死角になる。
シンプルな決定フィルタ
使用する React Native アラート ダイアログが:
| ネイティブのアラートを使用する | カスタムモーダルを使用する |
|---|---|
| 短いメッセージ | リッチまたは構造化されたコンテンツ |
| 基本的なアクション1つから3つ | フォームフィールドまたは埋め込まれたコンポーネント |
| プラットフォームネイティブの見た目は受け入れられる | 視覚的の一貫性はプラットフォームをまたいで重要 |
| 最速の実装が必要な場合 | レイアウトとアニメーション制御が必要 |
モバイルとウェブのビルドが同じ動作を必要とする場合、カスタムモーダルも役に立つ。プラットフォームごとにずっと特別なケースを設定するのではなく、1つのダイアログコンポーネントを中心に据え、相互作用モデルを一貫させたい。
Alertが「もう一つのプロパティ」を持つことを願う瞬間が来たら、モーダルが必要だ。
カスタムモーダルライブラリの候補
組み込みの Modal コンポーネントは機能するが、多くのチームは react-native-modal のラッパーを選択する。表示、バックドロップの動作、そしてアニメーションに関する実用的制御を追加するからだ。
特に、行動シート、下部ドロワー、または組み込まれた確認パネルに似たフローが多い場合、有用だ。メニューに近いデザインの場合、 のIonicアクションシートのような関連するUIパターンも考慮する必要がある React Native のアラートは、システムの UI を変えるのではなく、システムの UI を理解することのほうが簡単です。
注意点は 1 つあります。アラートをすべてカスタム モーダルに置き換えるのではなく、システムの UI がより快適に見えるからといって、カスタム モーダルに置き換えてはいけません。システムの UI は速度、親しみやすさ、実装のリスクが低いからです。モーダルを使用するのは、ユーザーがシステムの UI を操作する必要がある場合、またはデザイン チームがシステムの UI を嫌っている場合のみです。
React Native の信頼性の高いアラートの生産パターン
削除要求が失敗し、リトライ ハンドラーが発火し、セッションが期限切れになっているかどうかのチェックが同時に実行されます。明確なアラート戦略がなければ、ユーザーは重なり合ったダイアログ、フォーカスが失われた、または Web では実装されていないため無効のダイアログに遭遇する可能性があります。通常、問題はアーキテクチャから来ており、__CAPGO_KEEP_0__ 呼び出し自体から来ているのではありません。 Alert.alert is not implemented there. Those bugs usually come from architecture, not from the API call itself.
直接
画面をまたがって散在している呼び出しは、大規模なコードベースでは持たない。1 つのコンポーネントが __CAPGO_KEEP_0__ 失敗を処理し、別のコンポーネントがナビゲーション確認を求め、3 番目のコンポーネントが認証期限切れを警告する場合、近くに発生するイベントには、1 つの場所で順序付け、重複排除、プラットフォームのフォールバックロジックが必要です。 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.
アラートの順序付け、重複排除、プラットフォームのフォールバックロジックは、1 つの場所で実行する必要があります。
開発者は、ダイアログの抽象化パターンに関する議論で、同じ失敗モードを繰り返し指摘しています: 不適切に構造化されたアプリは、ユーザーを捕らえるか、ユーザーが実行する必要があるアクションを隠すことが多く、場合によっては約 30-40% ダイアログのスタック化に関する実装の議論は、この記事で前に述べたことがあるため、ここではそのリンクを繰り返さないようにしてください。実際の解決策は簡単です。__CAPGO_KEEP_0__ を一度にラップし、グローバルにリクエストをキューイングし、レンダラーが正確に 1 つの可視的なアラートを責任を持つようにします。ここに、コンパクトな Zustand-style 形式があります: 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.
アクセシビリティは実装の一部です
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;
};ネイティブ アラートは iOS と Android でデcent なデフォルトを提供します。ウェブ上でカスタムのフォールバックを導入したり、より豊かなコンテンツを提供したり、Android のプロンプトの置き換えを実装したりすると、システム ダイアログが無料で提供していた動作を所有することになります。
Gluestack の React Native アラートのオプションの比較では、カスタム モーダル実装が、title → message → buttons の予想される読み取り順序を破ることが多いと報告されています。
その特定の問題は重要です。スクリーン リーダー ユーザーは、ダイアログを理解するために予測可能な構造を依存しています。
アクセシビリティのハンドリングに関する Gluestack のベンチマーク (Gluestack の React Native アラート vs モーダル アクセシビリティの比較) では、その領域で失敗が報告されています。 titlemessage 60% buttons
カスタムアラートUIのために、このチェックリストを短く強制すること:
- ダイアログが開いたときにフォーカスをダイアログ内に移動する ダイアログが開いたとき
- ダイアログを閉じた後、トリガーにフォーカスを戻す 読み取り順序を維持する
- : タイトル、メッセージ、そしてアクションの順序明確なキャンセルパスを提供する
- 特に破壊的なフローでは、特にアクションのラベルを正確に指定する
- . 結果が重要な場合、「削除」は「OK」よりも良いでしょう。アラートフローのアクセシビリティのバグは、通常のQAで見落としやすいが、キーボードユーザーとスクリーンリーダーユーザーは最初に見つけることができます。
アラートフローのアクセシビリティのバグは、通常のQAで見落としやすいが、キーボードユーザーとスクリーンリーダーユーザーは最初に見つけることができます。
プラットフォームのダイアログではなく、トリガーをテストしてください。
Unit tests should verify that your code requested the alert you expected. They should not depend on the 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)
);
});That keeps tests focused on business logic and prevents hangs caused by dialog behavior outside the test environment. It also pushes teams toward a wrapper API, which is useful once web and Android prompt limitations force a custom fallback.
クライアントサイドモニタリングも役立ちます。Sentryを使用してReact Nativeアプリのインタラクションエラーを追跡しているチームは、アラートをトリガーするパスを明示的にエラー処理とログに記録することで、アラート関連の問題を多く検出することができます。 プロトタイプステージを過ぎたアプリでは、基準を設定する usually catch more alert-related issues when alert-triggering code paths are wrapped in explicit error handling and logged with enough context to reproduce the flow.
ラッパー
ヘルパー
- ウェブフォールバックロジックを一つの場所に置くようにします。
Alert.alert__CAPGO_KEEP_0__ __CAPGO_KEEP_0__ - グローバルでダイアログ要求をキューイングします したがって、時刻は1つのアラートのみが表示されます。
- Androidのプロンプトサポートを欠如とみなします 代わりに、遅い分岐を避けてモーダルフォールバックを計画します。
- 破壊的または不可逆の操作の場合にキャンセルアクションを必要とします。 テストでアラートをモックします
- ラベル、コールバック、並べ替えを確認します。 カスタムモーダルを必要とします
- 、例えばウェブの平行性、プロンプト入力、またはより豊かなコンテンツ。これにより、ネイティブアラートが速く動作する場所では、ネイティブアラートが速く動作し、プラットフォームの差異が後で現れる場合にコードベースを壁に当てるのを避けます。
Capgoの
