Kamu mungkin telah menghadapi dinding yang sama seperti tim React Native lainnya menghadapi dengan NativeBase Picker. Pilih dropdown terrender, terlihat baik, iOS berperilaku, dan kemudian Android mengabaikan logika kamu. onValueChange Logika. Tidak ada crash. Tidak ada peringatan. Hanya sebuah picker yang tampak berfungsi sementara logika bisnis Anda tidak pernah dijalankan.
Kesalahan itu adalah mengapa NativeBase Picker masih mengejutkan pengembang berpengalaman. Pengaturan sederhana, pengaturan tampilan dapat diatur, tetapi keandalan produksi bergantung pada pemahaman satu kegagalan Android yang paling banyak panduan mengabaikan atau tidak pernah menyebutkannya.
Tabel Konten
- Pengenalan dengan NativeBase Picker
- Pengaturan Nilai dan Pengaturan Pilihan
- Memperbaiki Bug Android onValueChange
- Mengatur gaya dan tema komponen Picker Anda
- Skenario Lanjutan dan Praktik Terbaik
- Kesimpulan
Mulai dengan NativeBase Picker
A komponen picker biasanya adalah salah satu komponen yang Anda tambahkan pada akhir sprint. Pilih negara, status, jenis janji, atau pilihan pengiriman. Ini terkesan kecil sampai perilaku platform mulai mempengaruhi antarmuka pengguna Anda.
Berita baiknya adalah bahwa Pilih NativeBase Pilih NativeBase adalah mudah untuk menampilkan di layar. Ini dibangun untuk menampilkan pilih native di iOS dan Android dan menggantikan pilih React Native yang sudah deprecated di setup NativeBase yang lebih lama, sehingga banyak kode lama masih bergantung pada itu.
Instal komponen di setup React Native normal
Jika proyek Anda sudah menggunakan NativeBase, tugas utama adalah mengimport primitif yang tepat dan menghindari logika wrapper yang tidak perlu pada hari pertama. Mulai dengan pilih picker yang paling sederhana yang mungkin.
Jika Anda bekerja di atas stack mobile dan hybrid, juga membantu untuk memahami bagaimana React code diemas dalam lingkungan yang lebih luas seperti Alur kerja aplikasi mobile React dengan Capacitor. Pilih code tetap familiar, tapi harapan pengembangan berubah.
Contoh dasar seperti ini:
import React, { useState } from 'react';
import { Container, Content, Form, Item, Picker, Icon } from 'native-base';
export default function BasicPickerScreen() {
const [selectedValue, setSelectedValue] = useState('key0');
return (
<Container>
<Content padder>
<Form>
<Item picker>
<Picker
mode="dropdown"
iosIcon={<Icon name="arrow-down" />}
selectedValue={selectedValue}
onValueChange={(value) => setSelectedValue(value)}
>
<Picker.Item label="Choose one" value="key0" />
<Picker.Item label="JavaScript" value="js" />
<Picker.Item label="TypeScript" value="ts" />
<Picker.Item label="React Native" value="rn" />
</Picker>
</Item>
</Form>
</Content>
</Container>
);
}Tampilkan pilih pertama tanpa abstraksi tambahan
Pertama-tama, ini harus menjawab dua pertanyaan:
- Apakah render dengan benar: Anda ingin memastikan bahwa bidang tersebut muncul di dalam tata letak Anda, menghormati jarak, dan membuka di kedua platform.
- Apakah jalur import Anda benar: Proyek NativeBase sering gagal karena alasan yang sederhana seperti menggabungkan API komponen lama dan baru.
- Apakah nilai yang dipilih dikendalikan: Bahkan dalam prototipe sementara, gunakan
selectedValuedari state. Pilih code yang tidak terkendali menjadi lebih sulit untuk di-debug kemudian.
Aturan praktis: Jangan mulai dengan menerjemahkan data server, aturan tempat, hook analitik, dan validasi ke dalam pilih yang sama. Buat komponen tersebut terlihat dan terkendali terlebih dahulu.
Berdasarkan aturan dasar tersebut, Anda akan tahu bahwa masalah bukanlah arsitektur bentuk formulir Anda, melainkan pilih.
Mengikat State dan Mengelola Seleksi
Setelah picker terrender, tugas berikutnya adalah membuatnya berguna. Di React Native, itu berarti menganggapnya seperti input yang dikontrol dan menjaga nilai yang dipilih di dalam state komponen.
Jalan standar adalah lurus. Anda menyimpan nilai saat ini dengan useStatemengirimkannya ke selectedValuedan memperbarui state di dalam onValueChangeMetode ini sama seperti yang Anda gunakan untuk field-form lain seperti pola React Native TextInput, even though the UI control is different.
Pilih nilai yang dikontrol dari awal
Berikut adalah versi yang bersih yang saya gunakan sebelum menambahkan validasi atau efek sampingan:
import React, { useState } from 'react';
import { Text } from 'react-native';
import { Form, Item, Picker } from 'native-base';
export default function RolePicker() {
const [role, setRole] = useState('');
return (
<>
<Form>
<Item picker>
<Picker
mode="dropdown"
selectedValue={role}
onValueChange={(value) => setRole(value)}
>
<Picker.Item label="Select a role" value="" />
<Picker.Item label="Admin" value="admin" />
<Picker.Item label="Editor" value="editor" />
<Picker.Item label="Viewer" value="viewer" />
</Picker>
</Item>
</Form>
<Text>Selected role: {role || 'none'}</Text>
</>
);
}Nilai code ini memberikan Anda sumber kebenaran yang dapat diprediksi. UI menggambarkan roledan setiap fungsi downstream membaca dari state yang sama.
Jaga logika pemilihan kecil dan dapat diuji
Masalah biasanya muncul ketika pengembang melebihi kapasitas onValueChangeMereka mengambil data, mengubah beberapa bagian state, memicu navigasi, dan merekam analitik dalam satu fungsi inline. Ketika perilaku picker gagal, debugging menjadi menyakitkan.
Pola yang lebih baik adalah memisahkan penyimpanan nilai dari efek sampingan:
import React, { useEffect, useState } from 'react';
import { Text } from 'react-native';
import { Form, Item, Picker } from 'native-base';
export default function DepartmentPicker() {
const [department, setDepartment] = useState('');
const [message, setMessage] = useState('No department selected');
useEffect(() => {
if (!department) {
setMessage('No department selected');
return;
}
setMessage(`Department selected: ${department}`);
}, [department]);
return (
<>
<Form>
<Item picker>
<Picker
selectedValue={department}
onValueChange={setDepartment}
>
<Picker.Item label="Select department" value="" />
<Picker.Item label="Sales" value="sales" />
<Picker.Item label="Support" value="support" />
<Picker.Item label="Operations" value="operations" />
</Picker>
</Item>
</Form>
<Text>{message}</Text>
</>
);
}Struktur ini melakukan dua hal yang berguna.
- Membuat picker bertanggung jawab hanya untuk memperbarui status pilihan.
- It moves app behavior into native components.
useEffectdi mana Anda dapat menguji dan memikirkan tentangnya secara mandiri.
Jika komponen form tidak dapat secara andal memberitahu aplikasi Anda apa nilai yang dipilih, maka setiap efek sampingan yang terkait dengan itu menjadi curiga.
Pada Android, titik tersebut menjadi sangat penting karena aliran acara NativeBase Picker tidak selalu berjalan seperti yang diharapkan.
Mengatasi Masalah Android pada Bug onValueChange
This is the part most articles skip. The NativeBase Picker can look healthy on Android while failing at the exact moment you need it to do work.
Dokumentasi komunitas sekitar implementasi pemilih lama menjelaskan pemisahan lintas-platform yang nyata. Android tidak memicu fungsi-fungsi khusus yang terpasang pada onValueChange, sementara iOS melakukannya, dan kegagalan tersebut dijelaskan sebagai 100% kesenjangan fungsi yang berfungsi pada Android dengan tingkat kesuksesan 0% untuk memicu fungsi pada perangkat Android meskipun implementasi code yang sama di dalam laporan-laporan yang terdokumentasikan. Dokumentasi yang sama mengarahkan pengembang ke arah kerja sama atau migrasi, dan mencatat bahwa komponen NativeBase 3.0 Select komponen mencapai 98% kesuksesan memicu fungsi di kedua platform dalam lingkungan pengujian dibandingkan, seperti yang dijelaskan dalam NativeBase picker dokumentasi dan konteks migrasi.
Apa yang sebenarnya rusak pada Android
Alasan praktisnya adalah detail implementasi. Pada Android, NativeBase Picker bergantung pada spinner native, dan lapisan tersebut tidak menyebarkan pendengar acara ke pembungkus seperti yang banyak pengembang harapkan. Pada iOS, perilaku modal terkait dengan sistem acara dengan benar.
Alasan itu, bug ini terkesan menipu. Anda melihat UI. Anda bisa membuka opsi. Anda bahkan bisa memilih item yang terlihat. Namun fungsi bisnis Anda tidak pernah berjalan.
Polanya yang gagal biasanya terlihat seperti ini:
<Picker
selectedValue={status}
onValueChange={(value) => {
setStatus(value);
saveStatusToApi(value);
trackSelection(value);
updateDependentFields(value);
}}
>Pada iOS, perilaku ini mungkin berfungsi seperti yang diharapkan. Pada Android, picker dapat menampilkan hasil sementara fungsi-fungsi tersebut tidak pernah berjalan.
Solusi alternatif yang dapat digunakan di produksi
Solusi yang paling dapat diandalkan adalah arsitektural, bukan kosmetik. Fokuskan interaksi picker pada menyimpan nilai yang dipilih, kemudian reaksi terhadap perubahan status di luar handler picker.
import React, { useEffect, useState } from 'react';
import { Form, Item, Picker } from 'native-base';
export default function StatusPicker() {
const [status, setStatus] = useState('');
const [didMount, setDidMount] = useState(false);
useEffect(() => {
if (!didMount) {
setDidMount(true);
return;
}
if (!status) return;
runStatusSideEffects(status);
}, [status, didMount]);
const runStatusSideEffects = (value) => {
console.log('Selected status:', value);
// call validation, API sync, or dependent form updates here
};
return (
<Form>
<Item picker>
<Picker
selectedValue={status}
onValueChange={setStatus}
>
<Picker.Item label="Select status" value="" />
<Picker.Item label="Pending" value="pending" />
<Picker.Item label="Approved" value="approved" />
<Picker.Item label="Rejected" value="rejected" />
</Picker>
</Item>
</Form>
);
}Mengapa ini membantu:
- Status tetap sentral: Logika komponen Anda mengawasi
status, bukan payload event picker saja. - Efek sampingan menjadi eksplisit: API memanggil, pembaruan field yang terkait, dan tracking tidak lagi hidup di dalam callback UI yang rapuh.
- code lebih mudah diganti nanti: If Anda beralih dari NativeBase Picker, logika bisnis sebagian besar tetap tidak terganggu.
For proyek Android-heavy, saya juga merekomendasikan melakukan pengujian pada perangkat nyata awal, terutama jika aplikasi Anda sudah memiliki kompleksitas pengemasan native seperti Android setup untuk aplikasi Capacitor.
Migrasi ke Select adalah keputusan yang lebih bersih.
If picker berada di dalam alur kerja kritis seperti checkout, onboarding, atau penginputan data yang diatur, memperbaiki sekitar perilaku lama mungkin tidak sepadan. Pada titik itu, beralih ke NativeBase 3.0 Select Pilihan jangka panjang biasanya lebih aman.
Bug bukan hanya mengganggu. Ini mengubah tempat di mana Anda bisa menempatkan logika bisnis dengan aman.
Jika Anda mempertahankan picker lama, lihatlah sebagai shell UI dengan tanggung jawab minimal. Dengan mindset ini, Anda bisa mencegah banyak regresi Android yang diam.
Mengatur gaya dan tema komponen picker Anda
Komponen picker yang berfungsi masih terlihat tidak selesai jika tidak sesuai dengan tampilan aplikasi lainnya. NativeBase memberikan Anda cukup hook untuk membuat kontrol terlihat sengaja, tetapi hasil yang paling bersih biasanya datang dari mengatur gaya penampung sebelum mengatur picker sendiri.
Gaya penampung sebelum mengatur picker
Pemilih itu sendiri sebagian besar dikendalikan oleh rendering asli. Pembungkus memberi Anda kontrol yang lebih besar atas jarak, penanganan batas, dan ritme tata letak.
Polanya yang praktis:
import React, { useState } from 'react';
import { StyleSheet } from 'react-native';
import { Form, Item, Picker, Icon } from 'native-base';
export default function StyledPicker() {
const [country, setCountry] = useState('');
return (
<Form>
<Item style={styles.pickerWrapper} picker>
<Picker
mode="dropdown"
iosIcon={<Icon name="arrow-down" style={styles.icon} />}
textStyle={styles.pickerText}
selectedValue={country}
onValueChange={setCountry}
>
<Picker.Item label="Select country" value="" />
<Picker.Item label="Germany" value="de" />
<Picker.Item label="Japan" value="jp" />
<Picker.Item label="Brazil" value="br" />
</Picker>
</Item>
</Form>
);
}
const styles = StyleSheet.create({
pickerWrapper: {
borderWidth: 1,
borderColor: '#D1D5DB',
borderRadius: 10,
marginTop: 12,
paddingLeft: 8,
backgroundColor: '#FFFFFF',
},
pickerText: {
color: '#111827',
fontSize: 16,
},
icon: {
color: '#111827',
fontSize: 18,
},
});Metode itu biasanya memberi Anda sebagian besar jalan tanpa mengover-engineering pengaturan tema.
Gunakan presentasi yang sadar platform
iOS dan Android jarang memerlukan gaya yang identik. Mereka memerlukan niat yang konsisten. Token visual yang sama masih memerlukan padding yang berbeda, penempatan ikon, atau mode pemilih.
Penyesuaian yang berguna termasuk:
- Pada iOS: Berikan ruang pada bidang tersebut dan perhatikan bagaimana presentasi modal terkait dengan label sekitarnya.
- Pada Android: Periksa clipping teks dan ketinggian spinner default pada beberapa perangkat.
- Untuk Kedua: Tetapkan teks tempat yang terlihat berbeda dari pilihan nyata.
A perbandingan singkat membantu:
| Kerawanan | IOS | Android |
|---|---|---|
| Perilaku terbuka | Rasa Modal | Rasa Spinner |
| Harapan ikon | Seringkali lebih dekoratif | Seringkali lebih fungsional |
| Masalah jarak | Tata letak tempat pengganti dapat terasa longgar | Tekst dapat terasa sempit |
Jika antarmuka UI Anda termasuk gradasi, kartu bertingkat, atau permukaan kontras tinggi, alihkan pembungkus pemilih dengan perawatan yang sama seperti yang digunakan di tempat lain di antarmuka, seperti pola yang digunakan dalam Kerja UI Linear Gradient React Native.
Catatan desain: Pengguna menilai picker kurang dari dropdown itu sendiri dan lebih dari bagaimana field tertutup berada di dalam formulir.
Oleh karena itu, jari-jari batas, jarak label, dan warna placeholder lebih penting daripada kustomisasi pemilih yang eksotis.
Skenario Lanjutan dan Praktik Terbaik
Banyak bug pemilih muncul setelah komponen meninggalkan fase prototipe. Masalah dimulai ketika pilihan datang dari server, aturan validasi berbeda antara platform, dan placeholder tidak dapat berperilaku seperti nilai yang valid.
Skenario kasus sampingan yang sering muncul sangat mengganggu di iOS. Pengembang sering perlu memuat nilai pemilih dari server sambil mencegah entry placeholder dari dapat dipilih, namun bahan resmi sering tidak menangani jalur tersebut secara langsung. Diskusi komunitas menyoroti bahwa nilai placeholder dapat tetap dapat dipilih di iOSyang menyebabkan perilaku tidak konsisten di aplikasi nyata, seperti yang disebutkan dalam artikel ini Diskusi komunitas React Native tentang nilai pilih server dan pengaturan tempat pengganti.
Muat opsi pilih dari data server dengan aman.
Kesalahan yang paling sering saya lihat adalah menganggap data yang diambil langsung siap digunakan sebagai pilihan. Simpan layer transformasi kecil antara respons API dan komponen.
import React, { useEffect, useState } from 'react';
import { Form, Item, Picker } from 'native-base';
export default function DynamicCategoryPicker() {
const [categories, setCategories] = useState([]);
const [selectedCategory, setSelectedCategory] = useState('');
useEffect(() => {
const loadCategories = async () => {
const response = await fetch('https://example.com/api/categories');
const data = await response.json();
const formatted = data.map((item) => ({
label: item.name,
value: String(item.id),
}));
setCategories(formatted);
};
loadCategories();
}, []);
return (
<Form>
<Item picker>
<Picker
selectedValue={selectedCategory}
onValueChange={setSelectedCategory}
>
<Picker.Item label="Select category" value="" />
{categories.map((item) => (
<Picker.Item
key={item.value}
label={item.label}
value={item.value}
/>
))}
</Picker>
</Item>
</Form>
);
}Membuat langkah formatasi tersebut memberikan kontrak yang stabil. Pemilih Anda tidak perlu mengetahui bentuk internal API.
Hindari pilihan tempat kosong pada iOS.
Aturan yang paling aman adalah sederhana. Jangan anggap tempat kosong sebagai pilihan yang sebenarnya, bahkan jika perpustakaan UI membuatnya mudah untuk menampilkan.
Polanya yang praktis:
- Pilih gunakan nilai sentinela kosong: Tetapkan nilai tempat kosong sebagai
''atau nilai aplikasi yang tidak valid lainnya. - Validasi sebelum mengirim: Tolak nilai kosong dalam validasi formulir, bukan hanya di UI.
- Mengaktifkan aksi downstream: Tunggu sampai ada nilai yang tidak kosong sebelum mengaktifkan tombol submit.
Untuk aliran yang lebih ketat, tampilkan teks bantuan ketika tempat masih dipilih:
const isValidSelection = selectedCategory !== '';Lalu, bukalah aksi tombol atau API Anda dari kondisi tersebut bukanlah mengandalkan tampilan picker.
Keamanan aksesibilitas dan kebiasaan produksi
Pilih-pilih seringkali melewati tinjauan aksesibilitas karena terlihat asli. Mereka masih memerlukan label yang jelas dan keadaan yang dapat diprediksi.
Beberapa kebiasaan membayar cepat:
- Tambahkan label aksesibilitas: Jadikan bidang tersebut dapat dipahami oleh pembaca layar.
- Tetapkan label yang eksplisit: “Negara” lebih baik daripada “Pilih”.
- Uji restorasi keadaan: Rebuka formulir dan konfirmasi item yang dipilih sebelumnya masih muncul dengan benar.
- Tulislah unit test seputar logika yang dipicu oleh seleksi: Logika di luar UI paling berpengaruh, dan membantu Anda melindungi transisi keadaan. membantu Anda melindungi transisi keadaan tersebut.
Pilih pilihan jarang kritis secara bisnis sendiri. Perubahan status di baliknya biasanya adalah.
Tangani NativeBase Picker sebagai permukaan input. Letakkan aturan yang sebenarnya di dalam keadaan, validasi, dan aliran pengiriman.
Kesimpulan
The NativeBase Picker is still useful when you understand where it breaks. Setup is straightforward, styling is workable, and server-driven option lists are manageable. A critical trap is Android event handling. If you keep business logic out of fragile picker callbacks and move it into state-driven effects, the component becomes much more predictable.
Untuk kode lama, kerja sementara itu sering cukup. Untuk aliran kritis, migrasi ke Select Pilih biasanya lebih baik. Baik itu pun, kunci tetap sama. Jangan percaya picker hanya karena sudah menampilkan.
Jika tim Anda mengembangkan aplikasi Capacitor atau Electron dan ingin memasukkan perbaikan JavaScript, CSS, teks, konfigurasi, dan aset tanpa harus menunggu ulasan toko. Capgo layak untuk dilihat. Ini memberikan Anda pembaruan hidup yang ditandatangani, kontrol peluncuran, perlindungan rollback, dan visibilitas rilis sehingga Anda dapat pulih lebih cepat ketika bug UI seperti regresi picker melarikan diri ke produksi.
