Master React Native Alert: API Panduan & Praktik Terbaik

Anda menekan tombol Alert.alert() di React Native, tes di iPhone dan Android, dan terasa sudah selesai. Lalu seseorang membuka build web dan tidak ada yang muncul. Atau Android mengabaikan alur konfirmasi yang Anda gunakan di iOS. Atau dua bagian aplikasi menampilkan notifikasi sekaligus dan pengguna terjebak dalam tumpukan dialog yang berantakan.

Itu adalah bentuk Alert React Native API. Ini bagus untuk alur konfirmasi native yang cepat. Namun, juga sempit, terikat platform, dan mudah digunakan secara tidak tepat dalam produksi. Berita baiknya adalah jalur bahagia sangat sederhana, dan sisi kasar dapat diprediksi jika Anda tahu di mana mereka berada.

Daftar Isi

• Menampilkan Pesan Sederhana dengan Alert.alert
  • Apa yang diberikan panggilan dasar
  • Di mana tim-tim salah gunakan
  • Kasus penggunaan yang baik untuk pesan sederhana
• Mengelola Masukan Pengguna dengan Tombol Konfirmasi
  • Memilih label tombol yang mengurangi kesalahan
  • Apa yang sebenarnya berarti gaya tombol
  • Polanya konfirmasi yang lebih aman
• Menavigasi Kekacauan Platform dan Prompt Masukan
  • iOS dan Android tidak cocok secara sempurna
  • Dukungan Web membutuhkan rencana sendiri
  • Polos Web Pattern Pengganti
• Kapan Menggunakan Modal Kustom Sebaliknya Alert
  • Alert asli membatasi Anda tidak bisa code di sekitar
  • Filter Keputusan Sederhana
  • Kandidat yang baik untuk perpustakaan modal kustom
• Polosan Produksi untuk Notifikasi React Native yang Terpercaya
  • Sentralisasi notifikasi bukan panggil mereka di mana-mana
  • Aksesibilitas adalah bagian dari implementasi
  • Tes trigger, bukan dialog platform
  • Basis produksi yang stabil

Menampilkan Pesan Sederhana dengan Alert.alert

Untuk notifikasi UI dasar Bahasa Indonesia masih alat tercepat di kotak. Anda import Alert, panggil Alert.alert(), dan platform menampilkan dialog native. Tidak ada dependensi tambahan, tidak ada modul modal khusus, tidak ada pekerjaan gaya.

Versi sederhana hanya memerlukan judul dan pesan:

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

Polanya berfungsi baik ketika pengguna tidak perlu membuat pilihan yang bermakna. Pikirkan “pengaturan disimpan”, “sesi habis”, atau “fitur tidak tersedia sekarang”. Dialog mengganggu alur, jadi harus membawa informasi yang pengguna butuh sekarang, bukan kebisingan status kecil.

Apa yang Anda dapatkan dari panggilan dasar

Pesan sederhana Alert.alert(title, message) bisa berguna karena tetap native. Sistem operasi mengelola presentasi visual, peran tombol, dan pola interaksi standar. Untuk banyak tim, itu persetujuan yang tepat.

Beberapa aturan praktis membantu menjaga itu berguna:

• Gunakan judul langsung.
• Pesan harus singkat. Informasi penting harus ditampilkan secara langsung, bukan penjelasan panjang.
• Gunakan notifikasi untuk informasi yang menghalangi pengguna. Jika pengguna dapat melanjutkan tanpa gangguan, notifikasi biasanya lebih baik.

Tampilkan informasi penting secara singkat dan tegas. Jika pengguna perlu membaca paragraf, dialog mungkin tidak UI yang tepat.

Mengapa tim sering salah menggunakan notifikasi

Menggunakan notifikasi sebagai sistem pesan umum adalah kesalahan paling umum. Jika setiap aksi sukses menampilkan dialog penghalang, aplikasi akan terasa berat dengan cepat. Notifikasi native paling kuat ketika menghentikan pengguna untuk alasan tertentu.

Kesalahan lain adalah mengkaitkan notifikasi terlalu erat dengan komponen internal. Sebuah handler tombol kecil mungkin cukup pada awalnya, tetapi ketika aliran penggunaan meluas ke beberapa layar dan aksi asinkron, panggilan notifikasi yang terpisah di seluruh aplikasi menjadi sulit untuk dipahami. Penggunaan yang baik untuk notifikasi sederhana.

Skenario untuk penggunaan notifikasi sederhana adalah

Jika Anda memerlukan pengguna untuk memilih antara beberapa jalur, langkah berikutnya adalah buttons array. Di sana Alert.alert() menjadi lebih dari sebuah kotak pesan sederhana.

Mengelola Input Pengguna dengan Tombol Konfirmasi

Sebagian besar penggunaan alert nyata bukanlah informatif. Itu tentang keputusan. Hapus draft, diskusikan perubahan, keluar, ulangi permintaan yang gagal. Di sana buttons array sangat penting.

Berikut adalah dialog konfirmasi yang umum:

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

Setiap tombol adalah objek. Dalam prakteknya, Anda akan menggunakan tiga properti paling sering:

• text adalah label yang ditampilkan kepada pengguna.
• onPress berjalan ketika tombol tersebut ditekan.
• style berkomunikasi makna, terutama pada iOS.

Mengilih label tombol yang mengurangi kesalahan

The API memungkinkan Anda menulis 'OK' dan melanjutkan. Itu biasanya tidak cukup. Label harus menjelaskan hasil, terutama untuk aksi destructive.

Bandingkan dua set ini:

• Label lemah: OK / Batal
• Label yang lebih baik: Hapus item / Simpan item

Versi kedua menghilangkan ketidakjelasan. Hal ini sangat penting dalam aliran yang menghancurkan, dan hal ini bahkan lebih penting ketika peringatan muncul setelah kesalahan atau operasi async. Tekst button harus menjawab, “Apa yang terjadi jika saya mengetuk ini?”

Jika aliran Anda mengumpulkan teks dari pengguna di tempat lain, pola teman yang bersih adalah memasangkan peringatan dengan input formulir eksplisit seperti input yang khusus Implementasi TextInput React Native Sebaliknya, jangan mencoba untuk memperluas dialog.

Apa yang sebenarnya berarti gaya tombol

Field style Field ini bersifat semantik, bukan dekoratif. Gunakan untuk menyampaikan tujuan.

Benchmark teknis dari Gluestack menunjukkan bahwa konvensi platform sangat penting di sini. iOS menempatkan tombol batal pada sisi kiri dan konfirmasi pada sisi kanan, sementara Android mengubahnya. Melanggar konvensi tersebut menyebabkan indeks kebingungan pengguna meningkat dengan 25% di pasar global, dan 45% Produk aplikasi yang berjalan di produksi sering kali kekurangan jalur pembatalan atau keluar yang wajib, sehingga meningkatkan aksi yang tidak dapat dibatalkan dan volume dukungan. Analisis yang sama juga menyebutkan bahwa implementasi peringatan kustom sering gagal dalam membaca urutan untuk teknologi bantu. Lihatlah Petunjuk Peringatan Gluestack.

Aturan Praktis: setiap peringatan yang merusak harus mencakup cara keluar yang eksplisit.

Untuk walkthrough visual yang lebih baik tentang konfigurasi tombol dan alur interaksi, demo singkat ini patut dilihat.

Polanya yang lebih aman

Ketika aksi yang sensitif, jaga callback tipis:

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

Polanya itu membosankan, dan itu mengapa polanya baik. Peringatan harus tetap prediktif.

Navigasi Keanehan Platform dan Prompt Input

Bug produksi yang umum terlihat seperti ini. Sama seperti Alert.alert() panggilan bekerja di iOS, bekerja di Android, kemudian gagal berfungsi setelah tim mengirimkan build web. API terlihat seragam di code, tetapi platform tidak sama.

iOS dan Android tidak sepenuhnya sesuai

Urutan tombol adalah tempat tim pertama kali terjebak. React Native mengirimkan peringatan ke sistem operasi, sehingga pengguna melihat konvensi native, bukan abstraksi React Native. Itu biasanya adalah pilihan yang tepat, tetapi itu berarti label tombol harus tetap tidak ambigu di antara platform.

Dukungan prompt adalah kesesuaian yang lebih besar. iOS mendukung Alert.prompt untuk entri teks ringan. Android tidak. Jika suatu alur bergantung pada memasukkan kata sandi, mengubah nama item, atau menangkap catatan singkat di dalam peringatan itu sendiri, maka alur itu hanya tersedia di iOS kecuali Anda membangun jalur terpisah.

Gunakan periksa platform awal daripada berpura-pura bahwa API-nya sesuai.

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

Alternatif Android kurang nyaman. Namun, itu masih pilihan yang lebih aman. Di produksi, redirect ke layar dedikasi atau modal yang dikendalikan lebih mudah untuk diuji, lebih mudah untuk disesuaikan, dan lebih mudah untuk membuat aksesibel daripada peringatan palsu yang dibangun di sekitar perilaku yang tidak didukung.

Dukungan web membutuhkan rencana sendiri

Dokumentasi resmi Alert React Native API menyebutkan dukungan untuk iOS dan Android di Referensi Alert React Native. Jika aplikasi Anda juga berjalan di React Native Web atau Expo Web, meninggalkan peringatan tidak diwrap membuat gagal lengkap untuk jalur interaksi di build web (Diskusi masalah dukungan alert di React Native Web).

Itu bukan kasus pinggir. Tim sering menemukannya terlambat karena QA mobile melewati pertama, sementara penutupan browser datang kemudian.

Tunjukkan peringatan asli sebagai hanya mobile-kecuali Anda menambahkan wrapper.

Wrapper tersebut juga membantu jika tim Anda sedang membandingkan komparasi arsitektur runtime hybrid di antara platform, terutama dalam React Native vs. Capacitor arsitektur perbandingan.

Polifill web sederhana

Untuk banyak aplikasi, solusi kerja yang paling sederhana adalah abstraksi kecil di sekitar pemisahan platform:

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

Polifill ini menyelesaikan celah dukungan yang segera, tetapi memiliki batasan. window.confirm memberikan Anda hampir tidak ada kontrol atas gaya, perilaku fokus, atau hook analitis. Ini adalah jaringan keselamatan yang wajar untuk konfirmasi sederhana, bukan jawaban akhir untuk alur yang memerlukan tinjauan aksesibilitas, antrian peringatan, atau perilaku konsisten di antara mobile dan web.

Kapan Menggunakan Modal Kustom Daripada Peringatan

Peringatan dialog asli kuat karena mereka terbatas. Batasan yang sama adalah mengapa mereka tidak lagi menjadi alat yang tepat dengan cepat.

Jika Anda memerlukan branding, kontrol tata letak, ikon, bidang formulir, jarak kustom, waktu animasi, atau konsistensi visual lintas-platform, berhenti melawan API. Gunakan modal kustom.

Pemberitahuan asli membatasi Anda tidak bisa code

Anda tidak bisa membuat Alert.alert() terlihat seperti sistem desain Anda. Itu adalah desain. React Native menyerahkan rendering ke sistem operasi, sehingga Anda mewarisi penampilan asli dan keterbatasan asli.

Itu baik ketika Anda ingin konfirmasi cepat. Itu buruk ketika produk meminta salah satu dari ini:

• Pemberitahuan konfirmasi yang ditandai dengan logo, teks bantuan, dan hierarki kustom Form multi-kolom
• di dalam modal Aliran penghapusan yang lebih kaya
• dengan pengakuan centang Prompt penilaian atau permintaan ulasan
• Form multi-kolom dengan bintang, ilustrasi, dan tombol kustom

Saat persyaratan tersebut muncul, peringatan asli menjadi akhir yang mati.

Filter keputusan sederhana

Gunakan Peringatan React Native ketika dialog adalah:

Modal kustom juga membantu ketika build mobile dan web Anda memerlukan perilaku yang sama. Sebaliknya dari kasus khusus setiap platform selamanya, Anda dapat mengentralisasi satu komponen dialog dan menjaga model interaksi yang konsisten.

Saat Anda mulai berharap Alert memiliki “satu lagi properti,” Anda mungkin membutuhkan modal.

Kandidat yang baik untuk library modal kustom

Komponen bawaan “bekerja, tapi banyak tim memilih wrapper seperti” karena menambahkan kontrol praktis di sekitar visibilitas, perilaku latar belakang, dan animasi. Modal Hal itu sangat berguna untuk alur yang menyerupai sheet aksi, drawer bawah, atau panel konfirmasi yang terdiri. react-native-modal Jika desain Anda lebih dekat dengan menu daripada peringatan native yang ketat, pola UI terkait seperti sheet aksi Ionic

Komponen bawaan bekerja, tapi banyak tim memilih wrapper seperti karena menambahkan kontrol praktis di sekitar visibilitas, perilaku latar belakang, dan animasi. Hal itu sangat berguna untuk alur yang menyerupai sheet aksi, drawer bawah, atau panel konfirmasi yang terdiri. seringnya menyediakan model mental yang lebih baik daripada mencoba memanipulasi Alert menjadi bentuk yang diinginkan.

Peringatan satu hal yang perlu diingat di sini. Jangan mengganti setiap peringatan dengan modal kustom hanya karena tampilannya lebih menarik. Peringatan asli masih menang dalam hal kecepatan, familiaritas, dan risiko implementasi yang rendah. Gunakan modal karena interaksi memerlukan, bukan karena tim desain tidak menyukai chrome sistem.

Polanya Produksi untuk Notifikasi React Native yang Terpercaya

Permintaan hapus gagal, handler ulang gagal, dan pengecekan sesi-expired berjalan pada saat yang sama. Tanpa strategi peringatan yang jelas, pengguna dapat terkena dialog yang berlapis, fokus yang hilang, atau tidak berfungsi pada web karena Alert.alert belum diimplementasikan di sana. Bug biasanya berasal dari arsitektur, bukan dari API itu sendiri.

Sentralkan peringatan daripada memanggilnya di mana-mana.

Direktif Alert.alert(...) Panggilan yang terpisah di berbagai layar tidak dapat bertahan dalam kodebase yang lebih besar. Komponen satu menangani gagal API, komponen lain meminta konfirmasi navigasi, dan komponen ketiga memberi peringatan tentang kadaluarsa autentikasi. Jika kejadian-kejadian itu terjadi bersamaan, Anda memerlukan logika pengaturan urutan, deduplikasi, dan fallback platform di satu tempat.

Jasa peringatan global menyelesaikan masalah itu. Gunakan Redux, Zustand, atau React Context. Pilihan penyimpanan tidaklah penting daripada kontrak. Permintaan peringatan masuk dalam antrian, satu dialog aktif pada satu waktu, dan web dapat menukar ke fallback berbasis modal di balik interface yang sama.

Para pengembang yang membahas pola abstraksi peringatan, telah menunjukkan mode gagal yang sama secara berulang-ulang: aplikasi yang tidak terstruktur dengan baik sering kali mengalami dialog yang berlapis yang menangkap pengguna atau menyembunyikan aksi yang mereka butuhkan, kadang-kadang mempengaruhi sekitar 30-40% implementasi yang dibahas dalam praktek (diskusi implementasi tentang abstraksi peringatan dan dialog berlapis sudah dibahas sebelumnya dalam artikel ini, jadi jangan ulangi tautan itu di sini). Solusi yang praktis adalah sederhana. Tutup API sekali, antrikan permintaan secara global, dan buat renderer bertanggung jawab atas satu peringatan yang terlihat.

Berikut adalah bentuk yang padat dalam gaya 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;
};

Layer UI berlangganan item antrian pertama dan menampilkan dialog yang tepat. Ketika pengguna menutupnya, layanan menghapus item tersebut dan menampilkan yang berikutnya.

Aksesibilitas adalah bagian dari implementasi

Peringatan native memberikan Anda default yang memadai pada iOS dan Android. Saat Anda memperkenalkan pengganti fallback yang kustom untuk web, konten yang lebih kaya, atau pengganti prompt Android, Anda mengambil alih perilaku yang sistem dialog tangani secara gratis.

Perbandingan Gluestack dari pilihan peringatan React Native mencatat bahwa implementasi modal kustom sering kali menghancurkan urutan membaca yang diharapkan dari judul → pesan → tombol, dengan kegagalan yang dilaporkan sekitar 60% dalam area tersebut dalam benchmark penanganan aksesibilitas mereka (Perbandingan Aksesibilitas Peningkatan React Native Alert vs Modal Gluestack). Masalah tersebut penting karena pengguna pembaca layar bergantung pada struktur yang dapat diprediksi untuk memahami dialog sebelum bertindak pada itu.

Untuk UI peringatan kustom, jaga daftar checklist singkat dan ditegakkan:

• Pindahkan fokus ke dialog ketika itu dibuka.
• Kembalikan fokus ke trigger setelah ditutup.
• Jaga urutan membaca utuh: judul, pesan, kemudian aksi.
• Berikan jalur batal yang jelas, terutama untuk aliran destructive.
• Tandai aksi dengan tepat. ‘Hapus’ lebih baik daripada ‘OK’ ketika konsekuensi penting.

Bug aksesibilitas dalam aliran peringatan mudah dilupakan selama QA normal. Pengguna papan tik dan pengguna pembaca layar menemukannya terlebih dahulu.

Uji trigger, bukan platform dialog

Unit tests harus memastikan bahwa code Anda meminta peringatan yang Anda harapkan. Mereka tidak boleh bergantung pada runtime dialog native.

Polanya Jest yang umum seperti ini:

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

Hal ini menjaga tes tetap fokus pada logika bisnis dan mencegah hambatan yang disebabkan oleh perilaku dialog di luar lingkungan tes. Ini juga mendorong tim ke sebuah wrapper API, yang berguna ketika prompt web dan Android memaksa fallback kustom.

Pengawasan sisi klien membantu hal ini juga. Tim yang sudah mengikuti gagal interaksi dengan Sentry di aplikasi React Native biasanya menangkap lebih banyak masalah terkait peringatan ketika jalur code yang memicu peringatan diapit dengan penanganan kesalahan eksplisit dan dicatat dengan cukup konteks untuk mengulangi alur.

Batasan produksi yang stabil

Untuk aplikasi yang sudah melewati tahap prototipe, gunakan set kecil aturan:

1. Bungkus Alert.alert dalam sebuah bantuan sehingga logika fallback web hidup di satu tempat.
2. Mengatur permintaan dialog secara global sehingga hanya satu peringatan yang terlihat pada satu waktu.
3. Tangani dukungan prompt Android sebagai hilang dan rencanakan fallback modal daripada cabang terlambat.
4. Tentukan aksi pembatalan untuk operasi yang merusak atau tidak dapat dikembalikan.
5. Simulasikan peringatan dalam tes dan asertikan label, panggilan balik, dan urutan.
6. Gunakan modal khusus hanya ketika diperlukanseperti kesetaraan web, input prompt, atau konten yang lebih kaya.

Hal ini menjaga peringatan native tetap cepat di mana mereka berfungsi dengan baik dan menghindari menggambar kodebase ke sudut ketika perbedaan platform muncul kemudian.