Alors il me semble que pas du tout. Je vais imaginer comment flux pourrais être implémenter en go. Ça ne vaut pas grand chose. Je ne suis pas un dev go et je fais ça sur un coin de table.
Tu va plutôt t'appuyer sur les channels. Toutes modifications de l'état, qu'elle vienne de l'ui ou pas est un envoi dans un channel vers cette goroutine.
Cette goroutine garde toujours le dernier état global de l'application. Quand il reçoit une action, il exécute un à un tout les reducers qui sont de simple fonctions pures (c'est-à-dire qu'elles ne prennent aucune entrée autre que leur paramètre donc elles ne regarde pas l'heure ou ne vont rien chercher sur le réseau). Pour chacune tu leur donne l'état précédent et l'action et il te donne le nouvel état (qui sera du coup donné au reducer suivant). Une fois le nouvel état complètement calculé, on va le dispatch. Il y a des détails d'implémentation qui sont des choix et contraintes du langage (est-ce que l'on peut rendre une structure immuable ? Combien coûte d'en faire une copie profonde ?).
Ceux qui font actuellement un get par binding, vont simplement devoir avoir le nouvel état qu'ils vont récupérer en une fois.
L'épine dorsal en tout ça c'est les channels. Je ne connais pas forcément assez pour savoir si ça peut fonctionner dans le cas contraire je ne doute pas qu'il existe des bibliothèques de queues efficaces (au lieu de faire des synchro tu utilise des entiers atomiques c'est moins lourd et bien plus simple). Et les reducers doivent tous s'exécuter dans le même thread.
Avec une implémentation efficace, le point de contention c'est quand tout le monde cherche à écrire des actions et ça revient simplement à incrémenter un nombre atomique. Le dispatch c'est de la mise à disposition d'une structure immuable (ou d'une structure par consommateurs éventuellement) donc tu ne devrait pas avoir de synchronisation.
La clef c'est que l'envoi de message peut être très efficace entre des threads.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à 4.
Alors il me semble que pas du tout. Je vais imaginer comment flux pourrais être implémenter en go. Ça ne vaut pas grand chose. Je ne suis pas un dev go et je fais ça sur un coin de table.
Tu va plutôt t'appuyer sur les channels. Toutes modifications de l'état, qu'elle vienne de l'ui ou pas est un envoi dans un channel vers cette goroutine.
Cette goroutine garde toujours le dernier état global de l'application. Quand il reçoit une action, il exécute un à un tout les reducers qui sont de simple fonctions pures (c'est-à-dire qu'elles ne prennent aucune entrée autre que leur paramètre donc elles ne regarde pas l'heure ou ne vont rien chercher sur le réseau). Pour chacune tu leur donne l'état précédent et l'action et il te donne le nouvel état (qui sera du coup donné au reducer suivant). Une fois le nouvel état complètement calculé, on va le dispatch. Il y a des détails d'implémentation qui sont des choix et contraintes du langage (est-ce que l'on peut rendre une structure immuable ? Combien coûte d'en faire une copie profonde ?).
Ceux qui font actuellement un get par binding, vont simplement devoir avoir le nouvel état qu'ils vont récupérer en une fois.
L'épine dorsal en tout ça c'est les channels. Je ne connais pas forcément assez pour savoir si ça peut fonctionner dans le cas contraire je ne doute pas qu'il existe des bibliothèques de queues efficaces (au lieu de faire des synchro tu utilise des entiers atomiques c'est moins lourd et bien plus simple). Et les reducers doivent tous s'exécuter dans le même thread.
Avec une implémentation efficace, le point de contention c'est quand tout le monde cherche à écrire des actions et ça revient simplement à incrémenter un nombre atomique. Le dispatch c'est de la mise à disposition d'une structure immuable (ou d'une structure par consommateurs éventuellement) donc tu ne devrait pas avoir de synchronisation.
La clef c'est que l'envoi de message peut être très efficace entre des threads.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll