J'ai une application où l'utilisateur se connecte d'abord comme d'habitude. Mon application dispose de plusieurs écrans qui sont parcourus par react-native-navigation.
Dans chaque écran autre que celui de connexion, j'ai besoin de savoir quel utilisateur utilise mon application car le contenu est spécialisé par son identifiant unique. J'obtiens cet uniqueID lorsque l'utilisateur se connecte avec succès mais je ne sais pas comment transmettre cet uniqueID à d'autres écrans.
Dois-je utiliser Redux ou l'API contextuelle pour gérer ce problème ou existe-t-il une autre façon pour passer ces données d'un écran à l'autre sans changer de projet.
Voici mon App.js:
const Stack = createStackNavigator({
Main: { screen: MainScreen },
Login: {screen: LoginScreen},
Profile: {screen: ProfileScreen},
NewSurvey: {screen: NewSurveyScreen},
},
{
initialRouteName: 'Login',
headerMode: 'none',
navigationOptions: {
headerVisible: false,
gesturesEnabled: false,
}
})
export const AppNavigator = createAppContainer(Stack);
Voici mon composant Navigator: p>
import React, { Component, PropTypes } from 'react';
import { AppNavigator } from './components/Navigator';
class App extends React.Component {
render() {
return (
<AppNavigator />
);
}
}
export default App;
4 Réponses :
Redux et ContextApi sont tous deux des gestionnaires d'état pour votre application. Ils présentent certains avantages et inconvénients pour votre application.
tweet de dan_abramov (créateur de Redux):
Mon résumé personnel est que le nouveau contexte est prêt à être utilisé pour mises à jour improbables à basse fréquence (comme les paramètres régionaux / le thème). C'est aussi bon de utilisez-le de la même manière que l'ancien contexte était utilisé. Pour les valeurs statiques puis propagez les mises à jour via les abonnements. Ce n'est pas prêt à être utilisé en remplacement de toute propagation d'état de type Flux.
En fait, j'utilise plutôt Redux dans votre cas.
Je pense que vous utilisez React Navigation selon le code partagé. Je vous suggère de mettre en œuvre le flux d'authentification comme suggéré ici et d'utiliser Redux pour définir / accéder à l'identifiant unique. Redux sert beaucoup plus de choses et est largement utilisé pour la gestion des états.
Vous pouvez définir uniqueID dans _signInAsync (), puis y accéder via. LocalStorage peut être une option mais pas une solution réalisable car l'accès aux valeurs de LocalStorage peut affecter les performances de l'application.
Merci beaucoup, à part la méthode mentionnée ci-dessus, je vais essayer la vôtre aussi.
Pour transmettre des données à d'autres écrans, vous pouvez utiliser la méthode de navigation React Navigation et y passer des données.
Je ne sais pas comment vous avez stocké vos données que vous utilisiez une base de données comme Realm ou SQLite etc ... mais chaque fois que vous récupérez des données à partir de là et que vous voulez passez-le à d'autres écrans procédez comme ci-dessous:
const username = navigation.getParam('username', 'Default'); //default is a value that will be used if there was no username passed
par exemple:
this.props.navigation.navigate('Homescreen', {
username: this.state.username,
});
et ensuite vous pouvez obtenir ces données comme ci-dessous:
this.props.navigation.navigate('SecondPage', {
//your data goes here
});
C'est exactement ce dont j'ai besoin. Puisque si la connexion réussit, je navigue vers MainScreen et ici j'ai besoin de rendre un contenu qui est totalement unique à l'utilisateur. Afin de rendre le contenu correctement, j'ai besoin de la méthode que vous avez mentionnée. Merci beaucoup.
redux ou react-context
"Redux est un conteneur d'état prévisible pour les applications JavaScript."
"Le contexte permet de transmettre des données à travers l'arborescence des composants sans avoir à passer manuellement les accessoires à tous les niveaux. »
Pour les mises à jour à basse fréquence comme les paramètres régionaux, les changements de thème, l'authentification de l'utilisateur, etc., le contexte React convient parfaitement. Mais avec un état plus complexe avec des mises à jour à haute fréquence, le contexte de réaction ne sera pas une bonne solution. Parce que le contexte React déclenchera un nouveau rendu à chaque mise à jour, et l'optimiser manuellement peut être très difficile. Et là, une solution comme Redux est bien plus simple à mettre en œuvre.
Quand utiliser l'API contextuelle
Si vous utilisez Redux uniquement pour éviter de passer des accessoires à des composants profondément imbriqués, vous pouvez remplacer Redux par l'API de contexte
Quand utiliser Redux
Redux est un conteneur d'état prévisible, gérant la logique de votre application en dehors de vos composants, centralisant l'état de votre application, utilisant Redux DevTools pour suivre quand, où, pourquoi et comment l'état de votre application a changé, ou en utilisant des plugins tels que Redux Form, Redux Saga, Redux Undo, Redux Persist, Redux Logger, etc.
Dans ce cas, nous pouvons utiliser Redux.
Utiliser
reduxest mieux pour vous@ ma_dev_15 c'est discutable, et c'est le problème avec cette question. De plus, cela a déjà été demandé .
vous pouvez également utiliser localstorage
d'accord, pour vous rendre plus clair, vous pouvez obtenir les détails de l'utilisateur dans les accessoires si vous utilisez connect depuis
reduxet lorsque vous utilisezcontext, vous finirez par écrireConsumer à l'intérieur de chaque composant. Alors, vous pouvez décider lequel sera le mieux? Et chaque fois que la valeur deProviderest modifiée, tout leConsommateureffectue un nouveau rendu, ce qui affecte fortement les performances reactjs.org/docs/context.html#caveatsvotre question n'est pas claire à mon avis, si votre problème est simplement de passer des données à travers les écrans, lisez ma réponse, mais si vous voulez dire lequel utiliser (redux - contextAPI) ce serait autre chose
@James en fait la question que vous avez fournie n'est pas ma réponse puisque je n'ai pas demandé laquelle devrais-je utiliser, mais j'ai demandé s'il y avait une solution autre que le contexte ou le redux.
@AlkanV peut-être que vous devriez renommer le titre de la question dans ce cas, je pense qu'il y a beaucoup d'ambiguïté entre ce que je supposais que vous demandiez et ce que vous étiez vraiment.