import { connect } from 'react-redux'
import * as PassagesActions from '../actions/passages'
import PassageMain from '../components/passage/main'
const mapStateToProps = (state) => {
return {
passageState: state.PassageReducer
}
}
const mapDispatchToProps = (dispatch) => {
return {
fetchPassages: () => {
const params = {
url: `${process.env.REACT_APP_API_ENDPOINT}/passages`
}
dispatch(PassagesActions.fetchData(params, 'passages'))
},
fetchPassage: (passageId) => {
const params = {
url: `${process.env.REACT_APP_API_ENDPOINT}/passages/${passageId}`
}
dispatch(PassagesActions.fetchData(params, 'passage'))
}
}
}
export default connect(
mapStateToProps, mapDispatchToProps
)(PassageMain)
3 Réponses :
Le moyen plus "REDUX" de faire cela consiste à envoyer une action dans le magasin pour mettre à jour l'état et à reformer Redux Rendez votre composant. Ce que vous avez ici ne serait pas considéré comme une bonne pratique.
Le problème que vous êtes que l'état des composants sera désactivé de synchronisation avec le magasin, de sorte que si le magasin est mis à jour et qu'un rendu est déclenché, le composant peut recevoir de nouveaux accessoires (éventuellement pas si rien d'autre ne met pas à jour le < code> État.passagereducer ) et remplacera l'état local.
Regardez les Documents Redux sur Flux de données unidirectionnelles et le EXEMPLE TODO Où ils Ajouter de nouveaux Todos .
C'est contre la "philosophie testaux" pour de bonnes raisons, vous avez une architecture et un cadre conçu pour stocker et centraliser l'état de votre application, vous devez l'utiliser! Si vous utilisez l'état du composant, vous décentralisez l'état de l'application et plus tôt ou tard, vous allez avoir une catastrophe. Coller à l'architecture Redux autant que possible, utilisez l'état des composants uniquement pour les détails de l'interface utilisateur mineure, voire mieux, ne l'utilisez pas du tout.
Cela pourrait aider à jeter un coup d'œil à votre réducteur, mais il est évident que vous n'avez pas besoin de l'état du composant si vous conservez déjà la collection de Si vous avez déjà des informations de base sur un et que vous devez charger davantage à partir du serveur pour ce composant, tous vos passages doivent avoir un drapeau indiquant si vous avez déjà cette information ou non. Lorsque votre composant ne charge que vous ne récupérez que si nécessaire.
Il n'est pas nécessaire d'utiliser REDUX est un cadre de niveau très bas, et cela vous donne beaucoup de liberté. Si vous doutez si vous faites ou non les bonnes décisions, gardez toujours à l'esprit:
Une autre chose à noter est que votre composant ne doit recevoir que les propriétés dont il a besoin. Vous le transmettez tout le réducteur, cela pourrait être complètement correct, mais si vous avez beaucoup de données dans le réducteur qui n'affecte pas la composante de toutes les performances diminueront, car vous ferez la force de réagir pour mettre à jour le composant lorsque Il n'y a pas besoin de le faire. passages dans votre magasin Redux. < / p>
composantwillreceiveProps , il suffit de déclencher l'action, mettez à jour le magasin dans le réducteur lorsque l'action se termine et c'est tout. Votre collection aura le passage, vous aurez besoin de le transmettre au composant (tout cela, pas seulement de l'ID).
Les autres commentaires font de bons points, mais aussi surestimer le cas. Performation de la question Redux FAQ chez http: // redx.js.org/docs/faq/organizingstate.html#organizing-State-only-Redux-state :
à l'aide de l'état de composant local est bien . En tant que développeur, c'est votre travail de déterminer quels types d'État constituent votre candidature et où chaque pièce devrait vivre. Trouvez un équilibre qui fonctionne pour vous et allez avec. Certaines règles communes de pouce pour déterminer le type de données doivent être mis à Redux:
- Les autres parties de la demande sont-elles soucies de ces données?
- Avez-vous besoin de pouvoir créer de nouvelles données dérivées en fonction de ces données originales?
- est les mêmes données utilisées pour conduire plusieurs composants?
- Y a-t-il de la valeur pour que vous puissiez restaurer cet état à un point donné à temps (c'est-à-dire le débogage du voyage temporel)?
- Voulez-vous cacher les données (c.-à-d. Utilisez ce qui est en état si elle est déjà là au lieu de la demander à nouveau)?
Ainsi, si vous souhaitez utiliser l'état de composant local comme zone "Données temporaires" avant de dépêcher une action avec le résultat, ça va.