Communication entre Reactjs Components

Après avoir trop lutté avec Redux, le flux et d'autres méthodes pub / sub, j'ai fini avec la technique suivante. Je ne sais pas si cela peut causer de gros dégâts ou des défauts afin de l'afficher ici pour éclaircir les programmeurs expérimentés au sujet de ses avantages et inconvénients.

var thisManager = function(){ var _Manager = []; return{ getThis : function(key){ return _Manager[key]; }, setThis : function(obj){ _Manager[obj.key] = obj.value; } } }; var _thisManager = new thisManager(); // React Component class Header extends Component{ constructor(){ super(); _thisManager.setThis({ key: "Header", value:this} } someFunction(data){ // call this.setState here with new data. } render(){ return <div /> } } // Then from any other component living far somewhere you can pass the data to the render function and it works out of the box. ie class Footer extends Component{ _click(e){ let Header = _thisManager.getThis('Header'); Header.somefunction(" Wow some new data from footer event "); } render(){ return( <div> <button onClick={this._click.bind(this)}> send data to header and call its render </button> </div> ); } }

J'envoie json en tant que données dans ma demande et il rend parfaitement les composants souhaités et je peux invoquer le rendu sans aucun pub / sub ou deep passant les accessoires pour invoquer une méthode parent en modifiant this.setState pour provoquer le redistribution .

Jusqu'à présent, l'application fonctionne bien et j'aime aussi sa simplicité. Lancez volontiers cette technique pour les avantages et les inconvénients

Cordialement

MODIFIER:

Il est mauvais d'appeler le rendu, donc je l'ai changé en une autre méthode pour obtenir plus de avantages et inconvénients de cette configuration.

Deux préoccupations principales avec cette configuration:
1. Vous ne devriez jamais appeler les méthodes réactives de cycle de vie directement
2. Les portes arrière dans les composants sont une mauvaise idée, qui détruisent la maintenance de la réaction

Ad 1: si vous invoquez directement render() (ou toute autre méthode de réaction) directement, réagir ne peut probablement pas appeler componentDidMount() , componentDidUpdate () `et d'autres méthodes de cycle de vie dans l'arborescence des composants.

Les dangers sont les suivants:

De nombreuses conceptions avec composant getInitialState() dépendent fortement des méthodes de cycle de vie en cours de getInitialState() : getInitialState() , componentWillReceiveProps() , shouldComponentUpdate() , componentDidMount() , etc. etc. Si vous appelez directement render() , de nombreux composants risquent de se rompre ou de montrer un comportement étrange .
Vous courez le risque de faire réagir le moteur de la différence: grâce à la gestion du cycle de vie, la réaction conserve une copie virtuelle de DOM dans sa mémoire (interne). Pour fonctionner correctement, l'intégrité de cette copie est essentielle pour réagir.

Mieux serait (mais encore en violation de mon deuxième point):

Inclure une méthode différente dans le composant.
Ce qui a un setState() si vous voulez re-render.
Et appeler cette méthode de l'extérieur.

Annonce 2. Une référence directe à un composant monté (comme le détient votre gestionnaire) comporte des risques supplémentaires. Les conceptions et les limites de React sont là pour une raison: maintenir le flux unidirectionnel et la hiérarchie des composants avec les accessoires et l'état, pour rendre les choses faciles à entretenir.

Si vous brisez ce modèle – en construisant une porte dérobée dans un composant, ce qui permet la manipulation de l'état – vous brisez ce principe de conception de réagir. C'est un raccourci rapide, mais est sûr de causer une grande douleur et une frustation lorsque votre application grandit.

Pour autant que je sache, les seules exceptions acceptables à cette règle sont les suivantes:

Méthodes dans un composant qui répond aux résultats d'appel ajax, à l'état de mise à jour (p. Ex. Après avoir récupéré des données du serveur)
Méthodes à l'intérieur d'un composant pour gérer les déclencheurs à partir de ses composantes enfants descendants directs (par exemple, exécuter la validation sur formulaire après avoir cliqué sur un bouton enfant)

Donc, si vous voulez l'utiliser à cette fin, vous devriez être bien. Mot d'avertissement: l' approche réactive standard protège l'accès aléatoire aux composants , car le composant ou la méthode appelant doit faire référence au composant. Dans ces deux exemples, une telle référence est disponible.
Dans votre configuration, TOUT morceau de code externe pourrait rechercher la référence à l'en-tête de votre table et appeler la méthode qui met à jour l'état. Avec une telle référence indirecte, et aucun moyen de dire quelle source est réellement appelée votre composant, votre code est susceptible de devenir beaucoup plus difficile à débaucher / à maintenir.