Vous avez probablement rencontré le même mur que de nombreux équipes de React Native avec le NativeBase Picker. Le menu déroulant s'affiche, il ressemble bien, iOS se comporte, et puis Android ignore votre logique. Pas de crash. Pas de warning. Juste un sélecteur qui semble fonctionnel tandis que votre logique commerciale ne s'exécute jamais. onValueChange Content Marketer
Ce fossé est la raison pour laquelle le NativeBase Picker surprend encore les développeurs expérimentés. La configuration est simple, la mise en forme est gérable, mais la fiabilité en production dépend de la compréhension d'une erreur Android spécifique que la plupart des guides ignorent ou n'évoquent jamais.
Table des matières
- Commencer avec le NativeBase Picker
- Liaison d'état et gestion des sélections
- Résoudre le bug Android de la fonctionnalité onValueChange
- Personnalisation de style et de thème de votre composant de sélection
- Scénarios avancés et meilleures pratiques
- Conclusion
Prise en main avec le sélectionneur NativeBase
Un sélectionneur est généralement l'un de ces composants que vous ajoutez tard dans un sprint. Sélecteur de pays, champ de statut, type d'appointment, option de livraison. Il semble petit jusqu'à ce que le comportement de la plateforme commence à se infiltrer dans votre interface.
La bonne nouvelle est que le Sélectionneur NativeBase est facile à obtenir sur l'écran. Il a été conçu pour afficher un sélecteur natif sur iOS et Android et pour remplacer le sélecteur React Native obsolète dans les anciens ensembles NativeBase, ce qui est la raison pour laquelle de nombreux codebases de legacy dépendent encore de lui.
Installez le composant dans un setup React Native normal
Si votre projet utilise déjà NativeBase, la principale tâche est d'importer les primitives appropriées et d'éviter la logique de wrapper inutile dès le début. Commencez par le sélecteur de base le plus simple possible.
Si vous travaillez sur des stacks mobiles et hybrides, cela vous aide également à comprendre comment React code est emballé dans des environnements plus larges comme Les flux de travail d'applications mobiles React avec Capacitor. Le sélecteur code reste familier, mais les attentes de déploiement changent.
Un exemple de base ressemble à ceci:
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>
);
}Affichez un premier sélecteur sans abstraction supplémentaire
Cette première passe devrait répondre seulement à deux questions:
- Est-ce qu'il s'affiche correctement: Vous voulez vérifier que le champ apparait dans votre disposition, respecte les espaces et s'ouvre sur les deux plateformes.
- Est-ce que votre chemin d'importation est correct : Les projets NativeBase échouent souvent pour des raisons banales telles que la combinaison d'API de composants anciens et nouveaux.
- Est la valeur sélectionnée contrôlée : Même dans un prototype jetable, utilisez
selectedValueà partir de l'état. Le sélecteur non contrôlé code devient plus difficile à déboguer ultérieurement.
Règle pratique : N'entrez pas directement dans le sélecteur les données de serveur, les règles de remplissage, les hooks d'analytique et la validation. Faites d'abord le composant visible et contrôlé.
Cette base minimale compte. Lorsque Android commence à se comporter de manière anormale plus tard, vous saurez que le problème n'est pas votre architecture de formulaire entière. C'est le sélecteur.
Liaison de l'état et gestion des sélections
Une fois le sélecteur affiché, la prochaine étape est de le rendre utile. Dans React Native, cela signifie traiter le sélecteur comme un champ de saisie contrôlé et conserver la valeur sélectionnée dans l'état du composant.
La voie standard est simple. Vous stockez la valeur actuelle avec useStateet la passez dans selectedValue, et mettez à jour cet état à l'intérieur onValueChangeCe n'est pas la même approche que pour les autres champs de formulaire comme les modèles de TextInput de React Nativemême si le contrôle de l'interface utilisateur est différent.
Utilisez une valeur contrôlée dès le début
Voici la version propre que j'utiliserais avant d'ajouter des validations ou des effets secondaires :
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>
</>
);
}Cela vous donne un code source de vérité prévisible. L'interface utilisateur reflète roleet chaque fonction downstream lit dans le même état.
Conservez la logique de sélection petite et testable
Les problèmes commencent généralement lorsque les développeurs surchargent onValueChangeIls récupèrent des données, mutent plusieurs tranches d'état, déclenchent la navigation et enregistrent des analytics en une seule fonction inline. Lorsque le comportement du sélecteur faille, le débogage devient douloureux.
Un modèle plus approprié est de séparer la mise en mémoire tampon des effets secondaires :
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>
</>
);
}Cette structure réalise deux choses utiles :
- Elle rend le sélecteur responsable uniquement de l'actualisation de l'état de sélection.
- Elle déplace le comportement de l'application dans
useEffectoù vous pouvez tester et raisonner à son sujet de manière independante.
Si un composant de formulaire ne peut pas vous dire avec certitude quel est la valeur sélectionnée, tous les effets secondaires attachés à lui deviennent suspects.
Ce point devient critique sur Android, où le flux d'événements prévu du sélecteur NativeBase ne tient pas toujours.
Dépannage du Bug de l'événement de changement de valeur sur Android
C'est là que la plupart des articles passent à côté. Le sélecteur NativeBase peut paraître en bonne santé sur Android tout en échouant exactement au moment où il doit faire du travail.
La documentation communautaire autour de l'ancienne mise en œuvre du sélecteur décrit une véritable scission cross-plateforme. Android ne déclenche pas les fonctions personnalisées attachées à onValueChangealors que iOS le faitet ce dysfonctionnement est décrit comme un 100% de disparité fonctionnelle sur Android avec un taux de réussite de 0% pour le déclenchement des fonctions sur les appareils Android malgré une mise en œuvre identique code Dans les rapports documentés. La même documentation indique aux développeurs des solutions de contournement ou de migration, et note que le composant NativeBase 3.0 Select atteint 98% de succès dans le déclenchement des fonctions sur les deux plateformes dans les environnements testés en comparaison, comme décrit dans la documentation et le contexte de migration de NativeBase picker.
Qu'est-ce qui brise réellement sur Android
La raison pratique est détaillée dans les détails d'implémentation. Sur Android, le NativeBase Picker repose sur le spinner natif, et ce niveau ne propage pas les écouteurs d'événements vers le wrapper comme le font de nombreux développeurs. Sur iOS, le comportement basé sur le modèle se lie correctement au système d'événements.
C'est pourquoi ce bug ressemble à un piège. Vous voyez l'interface utilisateur. Vous pouvez ouvrir les options. Vous pouvez même sélectionner un élément visible. Mais votre fonction métier ne s'exécute jamais.
Un modèle de défaillance typique ressemble à ceci :
<Picker
selectedValue={status}
onValueChange={(value) => {
setStatus(value);
saveStatusToApi(value);
trackSelection(value);
updateDependentFields(value);
}}
>Sur iOS, cela peut se comporter exactement comme prévu. Sur Android, le sélecteur peut s'afficher tout en ne déclenchant jamais ces fonctions.
Aide de substitution qui tient la route en production
La solution de remplacement la plus fiable est architecturale, pas cosmétique. Gardez l'interaction du sélecteur centrée sur la mise en mémoire d'une valeur sélectionnée, puis réagissez aux changements d'état en dehors du gestionnaire de sélecteur.
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>
);
}Pourquoi cela aide :
- L'état reste central : Votre logique de composant surveille
status, et non la charge de l'événement du sélecteur seule. - Les effets secondaires deviennent explicites : Les appels à API, les mises à jour des champs dépendants et le suivi ne vivent plus à l'intérieur d'un appel de callback UI fragile.
- Le code est plus facile à remplacer ultérieurement : Si vous migrez vers un sélecteur différent, la plupart de la logique commerciale survit inchangée.
Pour les projets axés sur Android, je recommande également de tester sur un appareil réel tôt, surtout si votre application a déjà une complexité de packaging native comme la mise en place d'Android pour les applications Capacitor.
When la migration vers Select est la décision plus propre
Si le sélecteur se trouve dans un flux critique tel que le paiement, l'inscription ou l'entrée de données réglementées, il peut ne pas être utile de contourner le comportement ancien. À ce stade, passer à NativeBase 3.0 Select est généralement la décision à long terme la plus sûre.
Le bug n'est pas juste un inconvénient. Il change l'emplacement où vous pouvez placer la logique commerciale de manière sûre.
Si vous maintenez l'ancien sélecteur, traitez-le comme un shell d'interface utilisateur avec une responsabilité minimale. Cette mentalité empêche de nombreux régressions silencieux Android.
Stylage et Thématique de votre composant de sélecteur
Un sélecteur fonctionnel ressemble encore à un projet inachevé s'il ne correspond pas au reste de l'application. NativeBase vous donne suffisamment de crochets pour faire que le contrôl’ait l'air délibéré, mais les résultats les plus propres proviennent généralement du stylage du conteneur autour du sélecteur plutôt que de lutter contre le contrôle natif directement.
Stylisez le conteneur avant de styliser le sélecteur
Le sélecteur lui-même est en partie contraint par la mise en page native. Le conteneur vous donne un contrôle bien plus grand sur l'espace, le traitement des bordures et le rythme de mise en page.
Un modèle pratique :
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,
},
});Cette approche vous obtient généralement la plupart de vos objectifs sans sur-engineérer les surcharges de thème.
Utilisez une présentation conforme à la plateforme
Les systèmes iOS et Android ont rarement besoin d'une mise en forme identique. Ils ont besoin d'une intention cohérente. Le même jeton visuel peut toujours nécessiter des espacements, des emplacements d'icônes ou des modes de sélection différents.
Les ajustements utiles incluent :
- Sur iOS : Donnez au champ de la place et prenez en compte la présentation modale par rapport aux étiquettes environnantes.
- Sur Android : Vérifiez la mise en page de texte et la hauteur de défaut du spinner sur plusieurs appareils.
- Pour les deux : Conservez le texte de remplissage visuellement distinct des sélections réelles.
Une courte comparaison est utile :
| Préoccupation | iOS | Android |
|---|---|---|
| Comportement d'ouverture | Aspect modal | Aspect de chargement |
| Attentes d'icône | Souvent plus décoratif | Souvent plus fonctionnel |
| Problèmes de mise en page | La disposition du champ de remplissage peut paraître floue | Le texte peut paraître serré |
Si votre interface comprend des dégradés, des cartes superposées ou des surfaces à contraste élevé, alignez le conteneur du sélecteur avec le même traitement que vous utilisez ailleurs dans l'interface, tout comme les modèles utilisés dans le travail de dégradé linéaire de React Native React Native linear gradient UI work.
Note de conception : Les utilisateurs jugent un sélecteur moins par le menu déroulant lui-même et plus par la façon dont le champ fermé s'insère dans le formulaire.
C'est pourquoi le rayon de rondeur des bords, l'écartement des étiquettes et la couleur de la place de texte comptent plus que les personnalisations exotiques du sélecteur.
Scénarios avancés et meilleures pratiques
La plupart des bugs de sélecteur se manifestent après la phase de prototype. Le problème commence lorsque les options proviennent d'un serveur, les règles de validation diffèrent par plateforme, et la place de texte ne peut pas agir comme une valeur valide.
Un cas d'extrémité récurrent est particulièrement ennuyeux sur iOS. Les développeurs ont souvent besoin de charger les valeurs du sélecteur à partir d'un serveur tout en empêchant la place de texte d'être sélectionnable, mais les matériaux officiels n'abordent souvent pas directement ce chemin. La discussion de la communauté souligne quela valeur de la place de texte peut rester sélectionnable sur iOS ce qui entraîne un comportement incohérent dans les applications réelles, comme le note cette.
Un diagramme illustrant le processus de flux de données à quatre étapes pour utiliser un sélecteur dynamique dans NativeBase.
Charger les options du sélecteur à partir de données de serveur de manière sécurisée : L’erreur que je vois le plus souvent est de traiter les données récupérées comme immédiatement prêtes pour le sélecteur. Gardez une petite couche de transformation entre votre réponse API et le composant.
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>
);
}Ce pas de formatage vous donne un contrat stable. Votre sélecteur n'a pas besoin de connaître la forme interne du API.
Prévenir la sélection de l'option par défaut sur iOS
La règle la plus sûre est simple. N'abord pas l'option par défaut comme une option réelle, même si la bibliothèque de l'interface utilisateur la rend facile à rendre.
Un modèle pratique :
- Utilisez une valeur sentinel vide : Considérez la valeur de l'option par défaut comme
''ou une autre valeur d'application invalide. - Valider avant soumission : Rejetez la valeur vide dans la validation de formulaire, et non seulement dans l'interface utilisateur.
- Désactivez les actions ultérieures : N'activez pas le bouton de soumission avant qu'une valeur non par défaut n'existe.
Pour des flux plus stricts, affichez du texte d'aide lorsque l'option par défaut reste sélectionnée :
const isValidSelection = selectedCategory !== '';Alors, masquez les boutons d'action ou les appels de API en fonction de cette condition plutôt que de vous fier à la présentation du sélecteur.
Les habitudes d'accessibilité et de production
Les sélecteurs glissent souvent dans les revues d'accessibilité car ils ressemblent à des éléments natifs. Ils ont encore besoin de marques claires et d'état prévisible.
Un ou deux habitudes rapportent rapidement des gains :
- Ajoutez des étiquettes d'accessibilité : Faites en sorte que le champ soit compréhensible pour les lecteurs d'écran.
- Conservez les étiquettes explicites : 'Pays' est préférable à 'Sélectionner'.
- Testez la restauration de l'état : Réouvre un formulaire et confirme que l'élément sélectionné précédemment apparaît correctement.
- Écrivez des tests unitaires autour de la logique déterminée par la sélection : La logique en dehors de l'interface utilisateur compte le plus, et test de l'unité du comportement React aidez-vous à protéger ces transitions d'état.
Un sélecteur est rarement critique pour les affaires par lui-même. Les changements d'état qui se trouvent derrière lui sont généralement plus importants.
C'est l'esprit qui maintient les formulaires dynamiques stables. Traitez le sélecteur NativeBase comme une surface d'entrée. Mettez les règles réelles dans votre flux d'état, de validation et de soumission.
Conclusion
Le sélecteur NativeBase est toujours utile lorsque vous comprenez où il se brise. La mise en place est simple, la mise en forme est gérable et les listes d'options dérivées du serveur sont gérables. Un piège critique est la gestion des événements Android. Si vous maintenez la logique métier hors des appels de rappel du sélecteur fragile et la déplacez dans les effets dérivés de l'état, le composant devient beaucoup plus prévisible.
Pour les anciens codebases, ce workaround est souvent suffisant. Pour les flux critiques, la migration vers Select est généralement la meilleure option. Dans les deux cas, la clé est la même. N'ayez pas confiance dans le sélecteur juste parce qu'il s'affiche.
Si votre équipe développe des applications Capacitor ou Electron et souhaite pousser des correctifs JavaScript, CSS, copie, configuration et d'actifs sans attendre la revue de la boutique Capgo est une option à considérer.
