Actuellement, lorsque Socket.io émet un "gmessage" de mon serveur et que la prise de mon composant l'attrape, mon état entier est remplacé.
Donc, le flux de courant est comme celui-ci:
J'envoie un message du composant, il passe à mon serveur, puis à l'API Watson. L'API envoie une réponse à mon serveur et le serveur envoie cela au composant.
de sorte que le premier message crée la connexion à Socket.io, la deuxième socket.io événement est prise sur la même connexion.
est là un meilleur moyen de configurer la connexion Socket.IO et gérer à la fois l'émetteur et la partie "sur gmessage" de cela? Merci pour
3 Réponses :
Puisque vous utilisez déjà REDUX, il est préférable de créer des actions de socket.io Dispatch Redux pour vous, vous pouvez utiliser Redux Saga identique à celle de ce Article décrit ou vous pouvez utiliser cette implémentation sans saga, mais vous devez avoir 1- Créer un fichier permet de dire puis à l'intérieur de ce fichier Créer 2- puis à l'intérieur de votre application 3- Vous pouvez désormais déclencher n'importe quelle prise de socket.IO à partir de n'importe quel composant à l'aide de ce type: p> lib / socket.js p> socket.io code> Le client permet d'appeler socket code> et créer initsocketo code> fonction dans laquelle vous peut déclencher des actions Redux en réponse à Socket.io: P> appelle code> Appelez cette action une fois votre code> est monté: p> myMethod = () => {
// you can use "this" here
}
render = (){
return <Launcher onMessageWasSent={this.myMethod} />
}
Selon votre application, je pense que Redux serait surchargé pour cela.
Je changerais ici à une expression de Lambda ici même pour éviter d'enregistrer ces références: P>
const Workshop = () => {
const [messageList, setMessageList] = useState([]);
...
Fareed a fourni une solution de rougeurs de travail et a suggéré des améliorations pour une approche non-REDUX. J'aimerais donc aborder les problèmes de votre code actuel:
Vous réinitialisez la variable de prise et crée son auditeur à chaque fois qu'un nouveau message est reçu au lieu de configurer et d'initialiser l'objet de socket une seule fois à l'intérieur d'un fichier séparé, puis de la consommer par votre composant d'atelier et éventuellement d'autres composants. sur votre projet.
Vous pouvez ajouter le message nouvellement reçu en appelant Pour résoudre le premier problème, vous pouvez créer un fichier séparé et déplacer vos importations liées à la prise et l'initialisation liées à celui-ci comme: gardez à l'esprit, Il s'agit d'une configuration minimale, vous pouvez modifier votre objet de socket avant de l'exporter autant que l'API Socket.io vous permet de. Puis, à l'intérieur du composant de l'atelier du composant de l'atelier ComposantDIdMount > Abonnez-vous à cet objet de prise comme: réagir docs dis Si vous devez charger des données à partir d'un point d'extrémité distant, c'est un bon endroit pour instancier la demande de réseau.
Pour résoudre le deuxième problème, _Anmessagewassent La fonction de gestionnaire ne doit recevoir le nouveau message que pour l'ajouter aux messages précédents à l'aide de SetState, comme celui-ci: setState ({Messages: [...]}) deux fois dans _onMessagewassent .
C'est une bonne réponse, mais je suppose que vous avez 2 numéros, il n'est d'abord nécessaire de disposer du client Socket Io attaché au composant dont vous n'avez besoin que d'un client pour votre projet.
2ème que vous n'avez pas besoin d'assigner "Ceci" à "mythis, il suffit d'utiliser la fonction de flèche, des fonctions de flèche ne possèdent pas cela, donc" cette "fonction de flèche intérieure sera le composant quelque chose comme" this.socket.on ("gmessage ", () => {This._onmessagewassent ....})
Corriger. J'ai supposé que ceci est un projet de pratique de base et toute la logique sera probablement contenue dans cette classe d'atelier. Je vais faire un changement en mentionnant cela. Vous avez raison sur l'autre question aussi. Personnellement, j'utilise toujours des fonctions de flèche dans mon code, mais je voulais souligner les erreurs à l'aide de son propre style de codage pour éviter des explications supplémentaires, mais je suppose que les meilleures pratiques devraient être appliquées à tout moment.
Je comprends, mais comme vous l'avez dit, il est toujours préférable de forcer les meilleures pratiques en particulier de son principal problème lié au mot-clé "Ce"
J'ai édité ma réponse à la prise d'entrée dans un fichier séparé et vous l'abonnez-vous à l'intérieur du composant, il aurait dû être définitivement l'un des points principaux de ma réponse. Appréciez les notes.