Je travaille sur une petite application React qui utilise Redux pour la gestion des états.
Le tableau ci-dessous affiche une liste dynamique d'objets, qui sont récupérés à partir du backend REST, qui est implémenté en Java avec Spring. Actuellement, je dois cliquer sur un bouton pour ajouter le dernier delta de données (au magasin Redux).
La table doit se mettre à jour automatiquement de manière performante. J'ai trouvé une solution de contournement hacky qui a utilisé de manière récursive la méthode setTimeout de Window pour récupérer périodiquement des données du backend , mais je n’ai pas aimé la solution.
Quels frameworks, outils ou approches puis-je utiliser pour la mise à jour automatique qui s'intègre bien avec React, Redux, React Redux et Redux Thunk?
4 Réponses :
Utiliser window.setInterval est mieux que window.setTimeout à cet effet. Autre que la récupération périodique des données de votre client, vous pouvez consulter une bibliothèque websockets telle que socket.io < / a> bien que cela nécessite une configuration côté serveur.
Merci pour l'alternative! Je viens de lire que l'utilisation de window.setTimeout sur window.setInterval évite la congestion et l'empilement des fonctions ( stackoverflow.com/a/8682723/1809463 ).
Oh, cela a du sens, je vais certainement utiliser setTimeout sur setInterval à partir de maintenant lorsque je veux récupérer des données asynchrones périodiquement, merci pour l'info
Puisque vous utilisez déjà redux et react-redux, si une action est distribuée et que l'état du magasin est mis à jour, le composant doit être renvoyé avec les nouvelles données.
Lorsque vous appelez setTimeout pour récupérer périodiquement des données, vous utilisez une technique appelée interrogation.
Pour éviter d'avoir à faire des sondages, cela dépend également du backend, que vous preniez en charge l'abonnement WebSocket ou GraphQL ou que vous utilisiez une sorte de source de données en temps réel (par exemple Firebase)
Si vous parlez de mise à jour automatique des données de manière réactive - lorsque quelque chose dans votre base de données est mis à jour - vous avez besoin d'une sorte de serveur socket pour cela. Vous pouvez déclencher un événement à partir de votre backend, vous y abonner dans votre frontend, puis effectuer une requête pour récupérer les données. Je ne pense pas que l'utilisation de setInterval soit une bonne idée pour ce type de choses (dans la plupart des cas).
Découvrez Pusher .
Peut-être que CouchDB (ou Couchbase (ce n'est pas la même chose) avec PouchDB pourrait vous aider? Pourquoi l'essayer dans quelques jours.
On dirait qu'ils ont des bibliothèques Spring Data
Je pense que cette question est trop large. Quelles sont les restrictions par rapport au serveur? Pouvez-vous demander au serveur de vous informer du changement de données via WebSocket? Si le serveur ne peut pas vous dire quand les données changent, vérifier les changements par intermittence est plus ou moins votre seule option.
Veuillez commenter, au lieu de voter pour la fermeture.
L'un n'exclut pas l'autre. La question est trop large pour SO. Si vous avez besoin d'idées, vous en avez reçu une. C'est un cas d'utilisation pour les sockets Web. L'interrogation (setTimeout) est le dernier recours.
J'ai ajouté des informations sur le serveur. Je n'utilise actuellement pas WebSockets. Ainsi, j'aimerais connaître le (s) moyen (s) non-WebSocket.
@mike Si vous avez un serveur REST et que vous n'êtes pas disposé ou capable de changer la situation, l'interrogation est la seule option.
@estus Oui, mais je ne savais pas comment faire un sondage correct dans ce contexte (j'ai à l'origine un fond Java). Il semble que
window.setTimeoutsoit la voie à suivre.@mike setTimeout ou setInterval doit avoir lieu quelque part. Une bonne chose est de ne pas avoir de requêtes d'interrogation simultanées, cela empêche les mises à jour d'état qui peuvent se remplacer. Vous pouvez annuler les demandes précédentes lorsque vous en faites une nouvelle, ou attendre la précédente avant d'en faire une autre. Ceci est très spécifique à vos détails d'implémentation, c'est pourquoi la question est trop large.