Je comprends que render () doit être pur. Imaginez que vous créez un composant qui affiche / restitue le contenu d'un objet système ou de base de données. L'objet est passé en tant que paramètre. Au fil du temps, une autre activité change quel objet est passé à ce composant, ou change quelque chose à propos de l'objet. Lorsque render () est appelé, il détecte qu'il a besoin de plus de données, ce qui pourrait signifier un autre fetch () et doit attendre ces données avant de pouvoir afficher / rendre.
Je ne sais pas comment gérer cela au mieux. didMount () aide à la PREMIÈRE utilisation du composant, mais pas si l'objet se met à jour d'une manière ou d'une autre (autres activités) et / ou est maintenant un objet nouveau / différent pour le composant actif.
Pour l'instant, dans render (), je file le fetch () et retourne une roue occupée et plus tard, lorsque les données arrivent, je change d '«état» pour que le composant effectue un nouveau rendu avec toutes les données dont il a besoin. Mais je doute que ce soit une approche pure.
Je suis sûr que c'est un scénario très courant et il existe donc une manière correcte de gérer cela.
3 Réponses :
D'après ce que j'ai compris, vous avez un cas d'utilisation où différentes activités peuvent être associées à votre composant et par conséquent vous avez des difficultés à les gérer. Il existe plusieurs façons de résoudre ce problème, la plus simple et la plus facile à maintenir étant de diviser la logique de vos composants principaux comme suit:
Composants: composants sans état qui ne se soucient que de la vue. c'est-à-dire, étant donné certaines données, il rendra une interface utilisateur. Peu importe d'où proviennent les données ou qui les récupère. Il restitue toujours la même interface utilisateur pour les mêmes données, donc appelé composant pur. Toutes les interactions se produisent via des gestionnaires d'événements, et le composant lui-même ne doit pas avoir de logique métier stockée.
Conteneurs: composants chargés de récupérer et de maintenir les données d'une activité. Celles-ci sont chargées d'effectuer les appels réseau réels et de gérer l'état des données. Sur la base des données, le conteneur monte un composant pur avec les données et les gestionnaires d'événements passés comme accessoires.
Si vous avez un grand nombre d'activités, vous pouvez toujours créer plusieurs conteneurs pour chaque activité.
De cette façon, vous auriez une séparation claire des préoccupations et serait facile à maintenir. Le même composant peut être utilisé par plusieurs conteneurs s'ils ont la même interface utilisateur.
Je vous suggère de lire cet article .
Tout d'abord, pensez à tout composant React comme un code prenant en charge le rendu. React est considéré comme View dans le style d'architecture Model-View-Controller. Donc, tout ce qui se passe dans React Component est prêt à prendre en charge le rendu. En général, votre composant doit connaître à tout moment l'objet qu'il rendra et demander à l'avance tout ce dont il a besoin pour le rendu (par exemple en réponse à un clic sur un bouton ou en utilisant un intervalle)
Vous pouvez envisager de diviser votre application en composants de présentation et composants de conteneur (comme Redux le suggère , même si vous ne va pas utiliser Redux)
Premiers composants de présentation de conception qui ne rendront l'interface utilisateur qu'en fonction des accessoires.
Par exemple
export class ContainerOfObject extends React.Component {
constructor () {
super();
this.state = {
object = {}
}
this.refreshObject();
}
async refreshObject () {
let newObject = await get('http://backend.com/object');
this.setState ({ object: newObject });
}
handleClieck () {
refreshObject();
}
render () {
return <div>
<PresetationOfObject object={this.state.object}/>
<button onClick={this.handleClick.bind(this)}>Update object</button>
</div>
}
}
N'apportez rien ici. Vous pouvez effectuer un rendu conditionnel en fonction des accessoires reçus, mais ne pas demander de nouvelles données.
Le composant conteneur, quant à lui, récupérera tout ce qui est nécessaire pour le rendu. Il doit posséder l'objet qui sera rendu. En possédant, je veux dire que l'objet provient du composant de conteneur et que le composant de conteneur sait tout sur les changements possibles d'Object.
La plupart du temps, l'objet (ou toute autre donnée) change en réponse aux actions de l'utilisateur. Ainsi, lorsque l'utilisateur clique sur un bouton, le composant du conteneur récupère les données.
Par exemple
export function PresetationOfObject (porps) {
return <div>My object is {props.myObject.toString()}</div>
}
Oui.
didMount () aide à la PREMIÈRE utilisation du composant, mais pas si le l'objet se met à jour d'une manière ou d'une autre (autres activités) et / ou c'est maintenant un objet nouveau / différent pour le composant actif.
Utilisez componentDidUpdate () qui se déclenche après chaque mise à jour des données sauf la première.
https://reactjs.org/docs/react-component.html#componentdidupdate