React Native でアラートをトリガーする Alert.alert() React Native では、iPhone と Android でテストし、完了と感じる。すると、誰かがウェブビルドを開き、表示されない。あるいは、Android は iOS で使用したプロンプト フローを無視する。あるいは、2 つのアプリのパーツが同時にアラートを発火し、ユーザーはダイアログの乱雑なスタックに閉じ込められる。
それは、React Native アラートの API の形です。速い、ネイティブの確認フローに素晴らしいです。狭い、プラットフォームに依存し、生産環境で誤用しやすいこともあります。幸いなことに、ハッピーパスは簡単で、粗い部分は予測可能です。
目次
- Alert.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 | なぜアラートが機能するか |
|---|---|
| 重要な設定変更後、確認を保存する | ユーザーは明確な承認が必要 |
| セッションタイムアウトの警告 | メッセージは緊急で、行動を促す |
| 非対応の機能の通知 | アプリは停止し、説明する必要がある |
ユーザーに選択肢を提示する必要がある場合、次のステップは 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そのボタンがタップされたときに実行される関数です。styleiOSでは特に、意味を伝える役割を果たします。
誤差を最小限に抑えるボタンラベルの選択
OKと進むことができるAPIは、通常では十分ではありません。ラベルは、破壊的なアクションの結果を説明する必要があります。
これら2つのセットを比較してみましょう。
- 弱いラベル: OK / Cancel
- より良いラベル: 削除アイテム / 保持アイテム
2 番目のバージョンは曖昧さを排除します。破壊的なフローでは重要であり、エラーまたは非同期オペレーション後に表示されるアラートではさらに重要です。ボタン テキストは、タップすると何が起こるかを答えるべきです。
ユーザーからテキストを収集するフローがある場合、明示的なフォーム入力と組み合わせることで、クリーンなパターンが得られます。 React Native の TextInput の実装 ダイアログをオーバーエクステンドするのではなく、ダイアログの代わりにフォーム入力を使用することをお勧めします。
ボタンスタイルの実際の意味
The style フィールドは意味を持ち、装飾ではありません。意図を伝えるために使用してください。
| スタイル | 使用するタイミング | 注記 |
|---|---|---|
default |
通常のアクション | 中立的な選択肢の場合に適しています |
cancel |
iOS ではバックボタンを使用します | 安全な解決策のために重要 |
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で動作し、チームがウェブビルドをリリースした後、機能しなくなった。APIはcodeで統一的に見えているが、プラットフォームは異なる。
iOSとAndroidは完全に一致しません。
ボタンの順序は、チームが混乱する最初の場所です。 React Nativeはアラートをオペレーティングシステムに委任するため、ユーザーはネイティブの慣習を、React Nativeの抽象化ではなく見ることになります。 それは通常、正しい取引ですが、ボタンラベルはプラットフォームをまたいで明確でなければなりません。
プロンプトのサポートは、より大きな不一致です。 iOSは軽量のテキスト入力用に Alert.prompt をサポートしています。 Androidはサポートしていません。 アラート内でパスワードを入力する、アイテムを再命名する、または短いメモをキャプチャするフローが依存している場合、そのフローはiOSのみで実行されます、除いて、別のパスを作成することによって。
プラットフォームチェックを早く行うのではなく、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’s official Alert API documentation lists support for iOS and Android in the のドキュメントでは、iOSとAndroidのサポートをとしてリストしています。 ただし、React Native WebまたはExpo Webでもアプリが実行される場合、アラートをunwrapしたままにすると、Webビルドのインタラクションパスで完全に失敗します (React Native Webのアラートサポートに関する議論).
それは、特にエッジケースではありません。 ほとんどのチームは、最初にモバイルQAが通過し、後でブラウザのカバレッジが来るまで、遅くまでそれを発見します。
ネイティブのアラートは、ラッパーを追加しない限り、モバイル専用として扱う。
ラッパーは、特にプラットフォーム間のハイブリッド実行環境のトレードオフを比較するチームにとって、さらに役立ちます。 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と戦うのをやめましょう。カスタムモーダルを使用しましょう。
Native alert limits you can’t code around
あなたは Alert.alert() あなたは
あなたのデザインシステムに似せようとしますが、できません。
- React Nativeは、ハンドリングをオペレーティングシステムに任せるため、ネイティブの外観とネイティブの制約を継承します。 それは、確認の迅速化を望む場合に良いでしょうが、製品が以下のいずれかを要求する場合に悪いでしょう。
- ブランドの確認ダイアログ ロゴ、ヘルプテキスト、カスタム階層とともに
- モーダル内に複数フィールドのフォーム チェックボックスの確認とともに破壊的なフロー
- チェックボックスの確認とともに破壊的なフロー 星やイラスト、カスタムボタンとともに
要件が現れると、ネイティブのアラートは死角になる。
シンプルな決定フィルター
使用する React Native アラート ダイアログが
| ネイティブのアラートを使用する | カスタムモーダルを使用する |
|---|---|
| 短いメッセージ | リッチまたは構造化されたコンテンツ |
| 1 つから 3 つの基本的なアクション | フォームフィールドまたは埋め込まれたコンポーネント |
| プラットフォームネイティブの見た目は受け入れられる | 視覚的の一貫性はプラットフォームをまたいで重要 |
| 最速の実装が必要 | レイアウトとアニメーション制御が必要 |
モバイルとウェブのビルドが同じ動作を必要とする場合、カスタムモーダルも役立ちます。プラットフォームごとにずっと特別なケースを設定するのではなく、1つのダイアログコンポーネントを中心に据え、相互作用モデルを一貫させます。
Alertが「もう一つのプロパティ」を持つと願う時点で、モーダルが必要になります。
カスタムモーダルライブラリの適切な候補
組み込みの Modal コンポーネントは機能しますが、多くのチームは react-native-modal のラッパーを選択します。表示、バックドロップの動作、そしてアニメーションに関する実用的制御を追加するからです。
特に、行動シート、下部ドロワー、または組み込まれた確認パネルに似たフローが必要な場合に便利です。メニューに近いデザインの場合、関連するUIパターンとして のアクションシート しばしば、Alert を形に合わせようとするよりも、より良い認識モデルを提供します。
ここで 1 つの警告があります。すべてのアラートをカスタム モーダルに置き換えるのではなく、システムの chrome を嫌う設計チームのためにだけなさい。Native アラートは速度、親しみやすさ、実装リスクの低さで勝つ。モーダルを使用するのは、インタラクションがそれを必要とする場合のみである。
React Native の信頼できるアラートの生産パターン
削除要求が失敗し、リトライハンドラーが発火し、セッションが期限切れになったときにチェックが実行される。明確なアラート戦略がなければ、ユーザーは重なり合うダイアログ、フォーカスが失われる、または web では実装されていないため無効のアラートに当たることがあります。通常、bug はアーキテクチャから来て、__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.
信頼できるアラートの生産パターン
開発者は、ダイアログの抽象化パターンに関する議論で、同じ失敗モードを繰り返し指摘しています: 不適切に構造化されたアプリは、ユーザーを捕らえるか、ユーザーが実行する必要があるアクションを隠すダイアログが重なり合い、場合によっては約 30-40% ダイアログの抽象化と重なり合いに関する実装の議論は、この記事で前に述べたので、ここではそのリンクを繰り返さないでください。実際の解決策は簡単です。__CAPGO_KEEP_0__ を一度に wrap して、グローバルにリクエストをキューイングし、レンダラーが正確に 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 なデフォルトを提供します。Web でのカスタムFallback、より豊かなコンテンツ、または Android のプロンプト置き換えを導入すると、システムダイアログが無料で処理していた動作を所有することになります。
Gluestack の React Native アラートのオプションの比較では、カスタム モーダル実装が、title → message → buttons の予想される読み取り順序を破ることがよくあり、
Gluestack のアクセシビリティハンドリングのベンチマークで報告されたその領域で失敗が報告されています。
その特定の問題は重要です。スクリーンリーダー ユーザーは、ダイアログを理解して行動する前に予測可能な構造に依存しています。 titlemessage 60% buttons
カスタムアラートUIのために、このチェックリストを短く強制する:
- ダイアログを開いたときにフォーカスをダイアログ内に移動する ダイアログが開いたときのフォーカスをトリガーに戻す
- ダイアログを閉じたときにフォーカスをトリガーに戻す 読み取り順序を維持する
- :タイトル、メッセージ、そしてアクションの順序を維持する明確なキャンセルパスを提供する
- ,特に破壊的なフローではアクションを正確にラベルする
- .結果が重要な場合、「削除」は「OK」よりも良いでしょう。アラートフローのアクセシビリティのバグは通常のQAで見落としやすいが、キーボードユーザーとスクリーンリーダーユーザーは最初に見つけることができる。
__CAPGO_KEEP_0__
プラットフォームのダイアログではなく、トリガーをテストしてください。
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)
);
});これにより、テストがビジネスロジックに集中し、テスト環境外のダイアログの動作によるハングが防止されます。また、ウェブとAndroidのプロンプト制限がカスタムフォールバックを強制するようになったら、ラッパーAPIを使用するようチームに推進します。
クライアントサイドのモニタリングも役立ちます。Sentryを使用してReact Nativeアプリのインタラクションの失敗を追跡しているチームは、明示的なエラー処理と十分なコンテキストでログを記録したアラートトリガー__CAPGO_KEEP_0__のパスをラップしたときに、アラート関連の問題を多くキャッチすることがよくあります。 プロトタイプステージを超えたアプリでは、以下の小規模なルールを使用してください。 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.
ヘルパー
で、ウェブのフォールバックロジックを一つの場所に置きます。
- __CAPGO_KEEP_0__はCapacitorです。
Alert.alert__CAPGO_KEEP_0__はCapacitorです。 __CAPGO_KEEP_0__はCapacitorです。 - グローバルでダイアログ要求をキューイングします したがって、時刻は1つだけ表示されます。
- Androidのプロンプトサポートを欠如とみなします 代わりに、遅い分岐を避けてモーダルフォールバックを計画します。
- 破壊的または不可逆の操作の場合にはキャンセルアクションを必要とします。 テストでアラートをモックし、ラベル、コールバック、並べ替えを確認します。
- カスタムモーダルを必要としない限り、使用しないでください 例えば、Webの平行性、プロンプト入力、またはより豊かなコンテンツです。
- これにより、ネイティブアラートが速く動作する場所では、ネイティブアラートが速く動作し、プラットフォームの差異が後で現れるときにコードベースを壁に当てるのを避けます。Capgoの
コンテキスト:Capgoのマーケティングウェブサイト。役割:短いUIラベルまたはナビゲーションアイテム。見られる場所:ページblog/[slug].astro。メッセージキー`written_by` (Written By)。
