REACT CONTEXT Flashcards
Qu’est-ce que l’API Context de React et quand a-t-elle été introduite officiellement?
L’API Context est une fonctionnalité native de React qui permet de partager des données entre des composants sans passer par les props. Elle a été officiellement introduite dans la version 16.3 de React, après avoir été disponible en version expérimentale.
Expliquez le problème du “prop drilling” et comment Context le résout.
Le prop drilling est la nécessité de passer des props à travers plusieurs niveaux de composants, même si les composants intermédiaires n’utilisent pas ces données. Context résout ce problème en créant un “état partagé” auquel les composants peuvent accéder directement, sans que les composants parents intermédiaires n’aient à transmettre les props.
Décrivez les 3 étapes principales pour implémenter Context dans une application React.
- Créer le contexte avec createContext(),
- Fournir le contexte avec un Provider qui enveloppe les composants concernés et passe des valeurs via la prop value,
- Consommer le contexte avec useContext() dans les composants enfants.
Pourquoi est-il recommandé de créer un hook personnalisé pour utiliser Context?
Un hook personnalisé permet d’encapsuler la logique d’utilisation du contexte, de vérifier s’il est bien fourni, et d’améliorer la maintenabilité du code. Il offre une meilleure API aux composants consommateurs et évite de répéter le code d’accès au contexte.
Comment vérifiez-vous qu’un contexte est bien fourni dans un hook personnalisé?
En vérifiant si la valeur retournée par useContext() est null ou undefined.
Par exemple:
const value = useContext(ThemeContext); if (value === null) { throw new Error(“useTheme must be used within a ThemeProvider”); }
Quel est le rôle de la valeur par défaut dans createContext()?
La valeur par défaut est utilisée lorsqu’un composant appelle useContext() sans être enveloppé par un Provider correspondant. Elle peut servir pour les tests unitaires ou comme valeur de secours, mais dans la pratique, il est généralement préférable de vérifier que le contexte est bien fourni.
Comment associez-vous un état local à un contexte pour le rendre dynamique?
En utilisant useState dans le composant Provider et en passant à la fois la valeur de l’état et la fonction de mise à jour via la prop value du Provider:
function ThemeProvider({ children }) {
const [theme, setTheme] = useState(“light”);
return (
<ThemeContext.Provider value={{ theme, setTheme }}>
{children}
</ThemeContext.Provider>
);
}
Pourquoi est-il recommandé de ne pas exporter directement le contexte?
Pour encapsuler la logique du contexte et éviter que les composants n’accèdent directement au contexte sans passer par le Provider. Cela renforce le pattern d’utilisation correct et évite les erreurs potentielles.
Comment géreriez-vous plusieurs contextes dans une application React?
En créant un fichier séparé pour chaque contexte avec son Provider et son hook personnalisé, puis en imbriquant les Providers dans le composant racine:
function App() {
return (
<ThemeProvider>
<AuthProvider>
<LocaleProvider>
<AppContent></AppContent>
</LocaleProvider>
</AuthProvider>
</ThemeProvider>
);
Quels types de données sont généralement partagés via Context?
Les données qui peuvent être considérées comme “globales” pour l’arbre de composants: thèmes d’interface, préférences utilisateur, état d’authentification, localisation/traductions, et autres états qui seraient autrement passés à travers de nombreux composants.
Comment Context s’intègre-t-il dans une architecture plus large avec d’autres solutions de gestion d’état comme Redux?
Context peut être utilisé pour des données qui changent rarement (thème, langue) tandis que Redux peut gérer l’état global plus complexe de l’application. Ils peuvent coexister: Context pour la UI/préférences, Redux pour les données métier.
Comment pourrait-on optimiser les performances avec Context lors de mises à jour fréquentes?
En séparant les contextes par domaine fonctionnel pour éviter les re-rendus inutiles, en utilisant useMemo pour mémoriser les valeurs du Provider, et en considérant useReducer au lieu de useState pour des logiques d’état complexes.
