Expo Image Picker: Guide complet pour 2026

Vous êtes probablement arrivé au point où l'interface utilisateur est prête, l'écran de profil a un bouton « Télécharger une photo » et maintenant la partie facile n'est plus facile. La sélection réelle d'images touche aux permissions natives, aux interfaces contrôlées par l'OS, aux formes de retour différentes que beaucoup de développeurs attendent et à quelques détails de build qui ne se montrent que lorsque vous expédiez un build réel.

C'est là que le sélectionneur d'images Expo entre en jeu. Il s'agit de la bibliothèque officielle Expo pour ouvrir l'interface système pour choisir des images et des vidéos à partir de la bibliothèque du dispositif ou prendre une photo avec la caméra, comme décrit dans le Répertoire de packages Expo. En pratique, cela signifie que vous obtenez un pont fiable vers les entrées de médias natives, mais pas une expérience de médias personnalisée qui se comporte de la même manière sur tous les appareils.

Cette guide est écrit pour la première mise en œuvre, et non pour la démo. Il se concentre sur les décisions qui comptent en production : configuration de flux de travail gérée ou nue, gestion des autorisations qui ne vous surprendront pas plus tard, analyse de résultats sûre, et un modèle d'envoi pratique après que l'utilisateur ait sélectionné un fichier. Si vous travaillez dans un environnement natif personnalisé, cela vous aide également à comprendre comment cela diffère d'un flux de travail de client de développement Expo.

Table des matières

• Démarrage avec l'outil de sélection d'image Expo
• Installation et configuration essentielle
  • Configuration de flux de travail gérée
  • Détails de la configuration de flux de travail React Native nue
• Accès à la caméra et à la bibliothèque de médias
  • Un composant minimal mais sûr
  • Flux de bibliothèque et de caméra
  • Ce que vous pouvez attendre de l'interface utilisateur du système
• Gérer les Résultats et les Options du Sélecteur
  • Lire correctement l'objet de résultat
  • Options qui modifient le comportement en aval
  • URI versus base64
  • Un modèle de résultat plus sûr pour les applications réelles
• Modèles Avancés et Différences de Plateforme
  • Un modèle d'upload pratique
  • Où les différences de plateforme ont vraiment de l'importance
  • Différences entre les workflows gérés et non gérés
• Dépannage des Problèmes Courants
  • Vérifications rapides pour les échecs courants
  • Un petit checklist de production

Démarrage avec Expo Image Picker

Un gestionnaire de produit demande des photos de profil. Une semaine plus tard, la même fonctionnalité nécessite également l'upload de factures, la capture de la caméra pour les rapports d'incident et les réessais lorsque les utilisateurs refusent la permission la première fois. L'entrée d'image s'élargit rapidement car elle touche aux permissions natives, à l'interface utilisateur propriétaire de l'OS, à la gestion de fichiers temporaires et aux flux d'upload backend.

expo-image-picker est le module Expo SDK pour ce travail. Il ouvre le sélecteur de plateforme ou l'interface utilisateur de la caméra et retourne les médias sélectionnés sous une forme que votre React Native code peut gérer. Le API JavaScript est petit. Le principal défi réside dans la mise en place native, la gestion des permissions et la gestion des résultats corrects sur les projets gérés et bare.

Le principal compromis est clair. Vous laissez iOS et Android présenter leur propre interface utilisateur de médias au lieu de construire un sélecteur personnalisé. Cela donne généralement de meilleurs résultats : les utilisateurs comprennent déjà les écrans système, les invites de permission se comportent comme l'OS l'attend et votre équipe évite de maintenir une mise en page de galerie en JavaScript.

Traitez cela comme une intégration native avec une interface React.

Cette mentalité aide car les modes d'erreur sont rarement dans le bouton qui appelle le sélecteur. Ils viennent généralement d'une des trois places :

• Configuration native : configuration de plugin manquante, chaînes de permission incorrectes ou un build obsolète après avoir changé la configuration
• Comportement en temps de exécution : les utilisateurs peuvent refuser l'accès, accorder un accès limité à la bibliothèque sur iOS ou annuler la flux sans sélectionner quoi que ce soit
• Analyse des résultats : le module actuel API retourne un assets array, donc les exemples plus anciens qui lisent result.uri directement échouent

La sélection de flux de travail change également le chemin de configuration. Dans une application Expo gérée, la plupart du travail natif vit dans la configuration de l'application et nécessite un rebuild lorsque cette configuration change. Dans une application bare, vous obtenez toujours le module Expo API, mais vous devez vérifier les paramètres de projet iOS et Android sous-jacents plus directement. Si votre équipe utilise un client personnalisé au lieu d'Expo Go, ce guide s'accorde bien avec l'explication de Capgo sur comment un client de développement Expo modifie la mise en œuvre de la test de module natif.

Cela fait une différence pour le reste du guide car le chemin heureux n'est qu'une moitié de l'histoire. Une mise en œuvre de sélection est solide lorsque cela fonctionne dans les deux flux de travail, gère les particularités de permissions spécifiques aux plateformes sans surprendre l'utilisateur et transmet un fichier utilisable à votre couche d'upload au lieu d'arrêter à une prévisualisation locale.

Installation et Configuration Essentielle

L'installation nécessite une seule commande. Le paramétrage natif correct détermine si la sélection fonctionne sur un appareil réel, dans un client de développement personnalisé et dans votre build de production.

expo-image-picker fournit un API React-facing sur les sélecteurs de plateforme pour les photos, les vidéos et la capture de la caméra. L'appel JavaScript est simple. La configuration n'est pas, car l'accès aux photos et la capture de la caméra sont contrôlés par iOS et Android, et non par React Native.

Commencez par l'installateur version-aware d'Expo :

npx expo install expo-image-picker

Utilisez expo install au lieu de npm install ou yarn add. Expo correspond à la version du package à votre SDK, ce qui évite un type courant de problèmes de compatibilité native. Si vous comparez comment les modules Expo s'intègrent dans votre processus de mise en production, cela Vue d'ensemble des outils Expo est une référence utile.

Configuration de flux géré

Dans le flux géré, déclarez le plugin dans la configuration de l'application afin que Expo puisse appliquer les modifications natives en temps de build.

Exemple avec app.json:

{
  "expo": {
    "plugins": ["expo-image-picker"]
  }
}

C'est le minimum de configuration. Dans la pratique, les équipes ajoutent généralement du texte de permission ainsi que, en particulier sur iOS, la prompt du système devrait expliquer pourquoi l'application a besoin d'accès. Gardez le langage spécifique à l'action de l'utilisateur. « Télécharger une photo de profil » est mieux que « Besoin d'accès aux médias. »

Un détail opérationnel cause beaucoup de temps gaspillé. Les modifications pluginsdes chaînes de permission ou d'autres configurations natives nécessitent une nouvelle build. Le rechargement du JavaScript ne s'applique pas à ces modifications. Dans Expo Go, vous êtes également limité par ce que le client inclut déjà. Dans une build de développement ou de production, le projet native reflète votre configuration uniquement après une nouvelle build.

Détails de configuration de React Native sans enveloppe

Dans une application sans enveloppe, le package API est le même, mais vous devez vérifier plus de projet native vous-même. Les descriptions d'utilisation iOS sont la première chose à vérifier. Si votre flux peut ouvrir la bibliothèque, lancer la caméra ou enregistrer une vidéo avec audio, votre application a besoin des chaînes de permission correspondantes dans Info.plist avant de reconstruire.

Un checklist pratique pour les projets sans métadonnées ressemble à ceci :

1. Installer expo-image-picker avec npx expo install expo-image-picker.
2. Ajoutez la configuration du plugin si votre projet utilise des plugins de configuration Expo.
3. Confirmez que les descriptions d'utilisation iOS correspondent aux fonctionnalités que vous exposez.
4. Reconstruirez les applications iOS et Android après toute modification de la configuration native.

Le texte de permission manquant ressemble souvent à un bug de temps d'exécution car l'interface utilisateur code est correcte et le gestionnaire de bouton fonctionne. L'erreur se situe plus bas dans la pile. Je vérifie généralement Info.plistla configuration de l'application, et si la dernière mise à jour inclut les dernières modifications natives avant de toucher le composant code.

Un ou deux habitudes rendent la mise en place plus prévisible :

• Écrivez le texte de permission pour l'action réelle : les utilisateurs doivent comprendre pourquoi ils voient la prompt.
• Configureur de la caméra et de la bibliothèque séparément : L'un peut fonctionner tandis que l'autre continue de ne pas marcher.
• Reconstruire après les modifications natives : Le rechargement chaud et la mise à jour rapide ne mettent pas à jour les permissions natives.
• Tester sur appareil : Le comportement du simulateur peut cacher les problèmes de permission et de caméra.

Si le sélecteur de média fonctionne pendant le développement mais se brise dans TestFlight ou la version de magasin Play, considérez cela comme un problème de configuration en premier lieu. La plupart du temps, c'est le cas.

Accès à la Caméra et à la Bibliothèque de Médias

L'utilisateur appuie sur « Charger photo », s'attend à ce que la caméra ou la bibliothèque s'ouvre, et votre application a une seule tâche à ce moment-là. Ouvrez l'interface utilisateur système appropriée, gérez le refus ou l'annulation sans casser l'écran, et renvoyez une référence de fichier local utilisable pour la prévisualisation ou l'envoi.

Cela semble simple jusqu'à ce que vous testiez les deux versions gérées et nues sur iOS et Android. Le JavaScript API reste compact, mais le comportement de l'exécution dépend toujours des invitations de l'OS, de l'équipement matériel du dispositif et de la façon dont vos permissions natives ont été configurées précédemment.

Un composant minimal mais sûr

The fluxe principal est cohérent dans les projets de workflow Expo géré et non géré. Demandez la permission pertinente, lancez le sélecteur, vérifiez si l'utilisateur a annulé, puis lisez le premier élément du dossier. result.assets.

Un composant de base ressemble à ceci :

import { useState } from 'react';
import { View, Button, Image, Alert } from 'react-native';
import * as ImagePicker from 'expo-image-picker';

export default function PhotoInput() {
  const [imageUri, setImageUri] = useState<string | null>(null);

  const pickFromLibrary = async () => {
    const permission = await ImagePicker.requestMediaLibraryPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow photo library access.');
      return;
    }

    const result = await ImagePicker.launchImageLibraryAsync({
      mediaTypes: ['images'],
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  const takePhoto = async () => {
    const permission = await ImagePicker.requestCameraPermissionsAsync();

    if (!permission.granted) {
      Alert.alert('Permission required', 'Please allow camera access.');
      return;
    }

    const result = await ImagePicker.launchCameraAsync({
      allowsEditing: true,
      quality: 1,
    });

    if (result.canceled) return;

    const asset = result.assets?.[0];
    if (!asset?.uri) return;

    setImageUri(asset.uri);
  };

  return (
    <View>
      <Button title="Choose from library" onPress={pickFromLibrary} />
      <Button title="Take photo" onPress={takePhoto} />
      {imageUri ? (
        <Image
          source={{ uri: imageUri }}
          style={{ width: 200, height: 200 }}
        />
      ) : null}
    </View>
  );
}

Trois détails sont importants ici.

• Demandez les permissions de bibliothèque et de caméra séparément. Elles échouent indépendamment.
• Traitez l'annulation comme une action utilisateur normale, pas comme un état d'erreur.
• Lire de assets[0], car le sélecteur renvoie un tableau d'éléments plutôt qu'un élément de niveau supérieur uri.

Flux de bibliothèque et de caméra

Commencez par le flux de bibliothèque si vous voulez la voie la plus rapide vers une fonctionnalité fonctionnelle. Il est plus facile à tester, il fonctionne dans plus de configurations de simulateur, et il évite les cas d'edge de matériel de caméra. Ajoutez la prise en charge de la caméra une fois que le chemin de traitement des résultats est stable.

Le chemin de la caméra a plus de façons de fail en développement. Le support du simulateur iOS est limité. Les émulateurs Android peuvent ne pas exposer le comportement de la caméra qui correspond à un appareil réel. Dans les projets non gérés, ces lacunes peuvent vous faire regarder le composant code même si la vraie question est la configuration native ou l'environnement de test.

Un modèle de conception de l'interface utilisateur propre est de demander à l'utilisateur la source avant d'appeler le sélecteur API:

const showPickerOptions = () => {
  Alert.alert('Upload image', 'Choose a source', [
    { text: 'Camera', onPress: takePhoto },
    { text: 'Photo Library', onPress: pickFromLibrary },
    { text: 'Cancel', style: 'cancel' },
  ]);
};

Cette séparation maintient chaque fonction focalisée. Cela rend également plus facile d'ajouter des analyses, des drapeaux de fonctionnalité ou des règles spécifiques au serveur ultérieurement. Par exemple, certaines équipes autorisent les téléchargements de bibliothèque pour les images de profil mais exigent des captures de caméra fraîches pour la vérification d'identité.

If votre application plus large prend également en charge des modèles d'accès de fichiers en dehors d'Expo ou si vous comparez des conventions entre les stacks natives, ceci Capacitor bibliothèque de photos de référence est un contexte utile.

Un démonstration courte est utile lorsque vous montrez ce flux à vos collègues ou à la QA :

Ce que vous pouvez attendre de l'interface utilisateur du système

expo-image-picker ouvre le sélecteur de plateforme ou l'interface utilisateur de la caméra. Votre application ne contrôle pas chaque écran dans ce flux. Cette distinction est importante car « cela fonctionne sur mon appareil » signifie souvent « l'OS a autorisé le chemin que j'ai testé. »

Sur iOS, les utilisateurs peuvent accorder un accès limité à la bibliothèque au lieu d'un accès complet. Sur Android, le comportement du sélecteur peut varier en fonction de la version du système d'exploitation et de la peau du fabricant. Dans les projets de workflow gérés, Expo gère plus de la mise en œuvre native pour vous. Dans les projets de workflow bare, vous devez confirmer que votre application compilée inclut les modifications de permissions natives que vous avez apportées. Le site d'appel JavaScript peut être identique dans les deux cas tandis que le résultat de temps de exécution diffère.

Je teste généralement ces cas avant d'appeler la fonctionnalité terminée :

• première demande de permission
• dénie de permission
• annulation de l'utilisateur
• sélection de bibliothèque réussie
• prise de vue réussie sur un appareil physique
• prévisualisation immédiate de l'URI locale retournée

Ces cas correspondent directement au comportement de production réel. Ils mettent également en place l'étape suivante de manière propre si vous devez envoyer le fichier à un serveur, une chaîne de traitement de moderation ou un point de terminaison de publication comme l' Instagram media publishing API.

Gestion des résultats et des options du sélecteur

Le résultat du sélecteur est la partie qui nécessite généralement une logique de production réelle. L'interface utilisateur du système retourne un objet structuré, et non juste un chemin de fichier, et de petites erreurs ici entraînent des prévisualisations brisées, des téléchargements vides ou des plantages après que l'utilisateur annule.

Lecture de l'objet de résultat correctement

La forme de résultat qui compte dans les applications Expo actuelles est result.assets[0].uriet non un niveau supérieur result.uriCe détail affecte à la fois les projets de workflow gérés et les projets bare car le JavaScript API est le même même si la mise en place native diffère en dessous.

Utilisez un modèle de garde d'abord :

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 1,
});

if (result.canceled) {
  return;
}

const asset = result.assets?.[0];
if (!asset) {
  return;
}

const { uri } = asset;
setImageUri(uri);

Cela gère les deux cas de figure d'erreur que je vois le plus souvent. Un sélecteur annulé ne vous donne pas d'actif à lire, et code qui suppose result.assets[0] existe toujours et échouera à l'exécution.

Une fois que vous avez l'URI, la mise en page d'une prévisualisation est simple :

<Image source={{ uri: imageUri }} style={{ width: 240, height: 240 }} />

Si vous prévoyez d'uploader plus tard, gardez tout l'objet, et non seulement l'URI. En pratique, asset et sont souvent utiles pour la validation, le journalisation ou la construction d'une demande multipart plus propre. fileName, mimeType, width, heightLes options qui changent le comportement en aval fileSize Quelques options de sélection affectent plus que la page de sélection. Elles déterminent la taille du fichier, le comportement d'édition et ce que votre serveur doit accepter.

Option

Type

Certains compromis sont faciles à manquer :

• allowsEditing est utile lorsque l'emplacement de l'image a une forme ou une taille fixe. Il est moins utile si votre serveur gère son propre pipeline de coupe et que vous souhaitez le fichier original.
• quality affecte le temps d'envoi, la pression de la mémoire et l'espace de stockage du serveur. quality: 1 n'est pas automatiquement le choix le plus approprié.
• mediaTypes devrait correspondre aux règles du serveur. Si le serveur rejette les vidéos, n'autorisez pas le sélecteur à les retourner.
• base64 augmente la taille du payload en mémoire. Évitez-le à moins que le service de réception ne le requière.

Ce dernier point est important sur les appareils à faible mémoire. Une URI de fichier local est généralement la meilleure remise pour la prévisualisation et l'envoi en plusieurs parties. Le base64 a des utilisations valides, mais il est coûteux par rapport à la transmission d'une référence de fichier.

URI versus base64

Pour la plupart des applications, la règle est simple :

• Utilisez URI pour les prévisualisations.
• Utilisez URI pour les téléchargements de fichiers.
• Utilisez base64 seulement lorsque le système de réception demande explicitement du contenu codé.

Ce modèle garde le sélecteur code petit et plus facile à tester. Il s'aligne également sur la façon dont de nombreux flux de médias backend sont construits, y compris les services qui publient finalement sur des plateformes externes telles que le processus de publication de médias Instagram API.

Si votre équipe met en œuvre des mises à jour OTA fréquentes ou déplace des actifs image lourds à travers la livraison d'applications, les décisions de taille de fichiers ici se répercutent dans le reste de la chaîne d'approvisionnement. Cette guide sur l'optimisation des images pour les mises à jour d'applications est un compagnon utile à la configuration du sélecteur.

Un modèle de résultat plus sûr pour les applications réelles

Pour le démo code, stocker uniquement imageUri est suffisant. En production, stockez un objet normalisé afin que la prochaine étape, la prévisualisation, la validation, l'envoi ou la réessai, n'a pas besoin de réinterpréter la réponse de sélection brute à chaque fois.

const result = await ImagePicker.launchImageLibraryAsync({
  mediaTypes: ['images'],
  allowsEditing: true,
  quality: 0.8,
});

if (result.canceled || !result.assets?.length) {
  return;
}

const asset = result.assets[0];

setSelectedImage({
  uri: asset.uri,
  fileName: asset.fileName ?? 'upload.jpg',
  mimeType: asset.mimeType ?? 'image/jpeg',
  width: asset.width,
  height: asset.height,
  fileSize: asset.fileSize ?? null,
});

Cela vous donne une forme prévisible à l'intérieur de l'application. Cela rend également les projets gérés et bare plus faciles à maintenir en alignement car l'application code reste stable tout en travaillant sur les différences natives ailleurs.

Une vérification finale vous aide. N'activez pas les champs de résultats supplémentaires juste au cas où. Demandez les données dont vous avez besoin, et maintenez le sélecteur concentré sur la sélection plutôt que de le transformer en une étape de traitement de fichiers général.

Modèles avancés et différences de plateforme

Un élément de sélection de l'image se simplifie généralement le moment où l'image sélectionnée doit survivre aux réessais, aux en-têtes d'authentification, aux différences de permissions natives et à un point de terminaison d'envoi réel. expo-image-picker gère bien la sélection. Le reste de la fonctionnalité est à votre application.

Un modèle de téléchargement pratique

Pour les API qui attendent un téléchargement de fichier FormData est toujours la valeur de sécurité par défaut. Il fonctionne sur les backends Rails, Node, Laravel, Django et Go courants, et il maintient le sélecteur séparé des préoccupations de transport.

async function uploadImage(imageUri: string) {
  const formData = new FormData();

  formData.append('file', {
    uri: imageUri,
    name: 'upload.jpg',
    type: 'image/jpeg',
  } as any);

  const response = await fetch('https://your-api.example.com/uploads', {
    method: 'POST',
    body: formData,
    headers: {
      Accept: 'application/json',
    },
  });

  if (!response.ok) {
    throw new Error('Upload failed');
  }

  return response.json();
}

Cela code suffit à prouver que le chemin fonctionne, mais les applications de production ont généralement besoin d'une couche supplémentaire. Dérivez name And, lorsque possible, attachez l'authentification à l'élément sélectionné à l'aide de la fonction du sélecteur, et maintenez l'état de l'envoi distinct de l'état du sélecteur afin qu'une requête échouée n'oblige pas l'utilisateur à rouvrir la bibliothèque. type Un certain nombre de vérifications empêchent les échecs courants que j'ai observés lors de la revue :

Confirmez que le fichier local existe avant de construire la requête

• Affichez une prévisualisation avant l'envoi afin que les utilisateurs puissent détecter le fichier incorrect dès le début uri Empêchez les appels répétés pendant que la requête est en cours d'exécution
• Gérez les échecs de réseau séparément des annulations du sélecteur ou des erreurs de permission
• Attendez-vous à ce que la validation back-end rejette les fichiers volumineux, les types MIME non pris en charge ou les informations d'authentification manquantes
• Si votre serveur exige la base64 au lieu de multipart, il s'agit généralement d'une contrainte du serveur et non d'une exigence du sélecteur. Multipart est moins coûteux en termes de mémoire et plus facile à raisonner sur les appareils mobiles.
• Où les différences de plateforme ont un impact réel

L'interface utilisateur du sélecteur est native, elle hérite donc du comportement natif. Cela affecte à la fois ce que les utilisateurs voient et ce que votre __CAPGO_KEEP_0__ devrait supposer.

Un certain nombre de vérifications empêchent les échecs courants que j'ai observés lors de la revue :

The picker UI is native, so it inherits native behavior. That affects both what users see and what your code should assume.

On iOS, les flux d'édition et les invites de permission suivent les conventions d'Apple. L'accès aux photos limité peut retourner un ensemble d'actifs plus étroit que votre compte de test a vu sur un appareil avec une autorisation complète. Sur Android, le comportement du sélecteur varie plus en fonction de la version du système d'exploitation et de la peau du fabricant, surtout autour des albums, des noms de fichiers et de la façon dont les captures de la caméra sont retournées. Les applications React Native nues ressentent ces différences plus directement car vous possédez plus de la configuration native, mais les applications Expo gérées ont toujours besoin de code qui traite le sélecteur comme plateforme plutôt que parfaitement uniforme.

La règle pratique est simple. Faites confiance aux champs que vous pouvez valider, pas à l'interface utilisateur identique ou aux métadonnées identiques entre appareils.

Un ou deux exemples comptent dans les applications réelles :

• Édition et recadrage : La mise en page et le comportement de recadrage ne sont pas identiques entre iOS et Android
• Les métadonnées retournées : fileName, mimeType, et fileSize peuvent être absents ou incohérents, il faut donc ajouter des valeurs par défaut
• Permissions : L'accès aux photos sur iOS peut être limité aux éléments sélectionnés, tandis que le comportement d'Android dépend plus de la version du système d'exploitation et du support du sélecteur système
• Sortie de la caméra : Les images capturées peuvent revenir avec des caractéristiques de nommage, d'orientation ou de compression différentes que les actifs de la bibliothèque

Si votre équipe travaille également en dehors d'Expo, cela Guide de développement d'applications DesignStack fournit un contexte Android utile pour les décisions de gestion de médias qui se produisent au-delà d'une seule bibliothèque.

Différences entre les workflows gérés et non gérés

À ce stade, les choix de configuration commencent à avoir un impact opérationnel.

Dans le workflow géré, les chaînes de permission et la configuration du plugin vivent généralement dans la configuration de l'application, et les changements natifs sont appliqués lors de la création d'une nouvelle build. Cela garde la surface de JavaScript propre, mais cela signifie également que la correction de la configuration n'est pas visible avant la prochaine build native. Les mises à jour OTA ne corrigent pas les permissions natives manquantes.

Dans le workflow non géré, le même fonctionnement a plus de parties en mouvement. Vous devez vérifier les descriptions d'utilisation iOS natives, le comportement du manifest Android, l'installation du package et la synchronisation de la rebuild vous-même. L'avantage est le contrôle. Le coût est que les problèmes de sélection peuvent être causés par la configuration native, et non par le site de l'appel JavaScript.

Les équipes qui passent entre Expo et Capacitor sous-estiment souvent la différence entre ces couches d'abstraction. Capgo a une explication utile de comment Capacitor gère les différences de plateforme, et c'est un point de comparaison pertinent si vous vous décidez à quel point de la configuration native votre équipe souhaite s'occuper.

Mon préférence est cohérente dans les deux workflows. Gardez le sélecteur code étroit, normalisez le résultat une fois, envoyez-le à travers une couche dédiée API et traitez le comportement spécifique à la plateforme comme quelque chose à configurer et à tester explicitement plutôt que de le lisser avec des hypothèses.

Résoudre les problèmes courants

La plupart des bogues de l'outil de sélection d'image Expo se répartissent en quelques catégories. La solution la plus rapide consiste généralement à identifier la couche qui ne fonctionne pas : la configuration, les autorisations, la gestion des résultats ou la mise en page.

Vérifications rapides des échecs courants

Si le sélecteur ne s'ouvre pas ou si les autorisations échouent, vérifiez d'abord la mise en place native. Dans les applications bare en particulier, les descriptions d'utilisation iOS manquantes constituent une cause courante de racine.

Si l'application s'effondre après que l'utilisateur a fermé le sélecteur, inspectez votre gestion des résultats. De nombreuses implémentations supposent toujours une URI directe et ignorent la vérification. canceled Un certain nombre de mappages rapides vous aideront :

Bogues d'autorisations refusées :

• Vérifiez votre configuration d'application et les chaînes de permission native, puis rebuild. URI d'image :
• undefined Lisez de , pas result.assets?.[0]?.uriSi vous utilisez Capacitor, assurez-vous que votre application est configurée correctement pour les autorisations. result.uri.
• Rien n'arrive après annuler : Cela peut être correct. Traitez l'annulation comme un état sans opération.
• L'image ne s'affiche pas : Confirmez que l'URI a été stockée dans l'état et passée dans <Image source={{ uri }} />.
• La caméra fonctionne de manière étrange dans le simulateur : Testez sur un appareil physique avant de poursuivre une erreur de bibliothèque.

Un petit checklist de production

Utilisez cela comme dernier passage avant la livraison :

• Installer avec les outils Expo : Utilisez npx expo install expo-image-picker.
• Configurez les pièces natives : Ajoutez le plugin et les descriptions des permissions requises.
• Demandez les permissions intentionnellement : Faites couler les flux de la caméra et de la bibliothèque de médias séparément.
• Gardez chaque résultat protégé : Vérifiez result.canceled et lisez en toute sécurité assets[0].
• Préférez les téléchargements basés sur URI : Gardez base64 pour les cas spéciaux uniquement.
• Testez des appareils réels : Surtout pour la capture de la caméra et les invitations de permission.

Si votre équipe expédie Capacitor ou des applications Electron aux côtés de projets React Native, Capgo est une option pour livrer des mises à jour de JavaScript, CSS, de configuration et d'actifs sans attendre la revue de la boutique pour chaque changement. C'est pertinent lorsque les corrections d'image vivent dans votre couche web, telles que l'interface de téléchargement, les règles de validation, les copies ou la gestion d'actifs autour du flux de sélection.