Une nouvelle façon d'architecturer son application

Eviter le two-way binding.

Oui, c'est le plus gros point fort de flux à l'usage. On ne s'en rend pas bien compte au début (je venais d'Angular 1 moi aussi), on a l'impression que c'est chiant et tout, mais ça évite un plat de spaghetti indémerdable. Quand une app Angular grossit, il est très très difficile de comprendre (tracker) d'où proviennent les données. Avec flux tu as un seul point d'interception pour le comprendre : ton reducer. C'est lui et lui seul qui va mettre à jour le state.

Ensuite pour la question générale, je pense que c'est possible avec Angular, mais en esquivant des fonctionnalités d'Angular (notamment le 2-way binding). Donc tu as des vues qui ne font que lire des données et les afficher, et dispatcher des actions. Dans ce cas là, tu vas te retrouver avec une vue très simple bannissant les ng-bind. Et par contre, ton contrôleur va grossir avec un ensemble de méthodes de dispatch (en fait il va appeler des primitives directement sur le service).

Ca me paraît jouable mais ça impose plein de trucs :

• faire attention, dans la vue, à ne faire que "lire" des données, pas de binding
• dans le contrôleur, ne conserver strictement aucun état, et avoir uniquement des dispatch-like (en gros service.setData())
• dans le service, écrire des méthodes d'extraction des données : "les personnes dont le nom commence par 'A'" (ou alors dans le contrôleur ? on voit que ça commence à être merdique déjà).

Donc ça implique de s'imposer beaucoup de contraintes, et pour peu que tu bosses à plusieurs, c'est mort.

Aussi, si tu as besoin de mettre à jour les données de ton service depuis plusieurs points d'accès (une API, une websocket, une action utilisateur) ça va vite être le bordel.

L'idée de Flux c'est de vraiment bien séparer les responsabilités. Ta vue ne fait qu'afficher des données et dispatcher des actions, ton reducer vient mettre à jour le state en fonction des actions reçues, ton "sélecteur" extrait les informations du state pour les passer à la vue. Afin d'être certain que si des portions du state dont tu te fous changent, ta vue n'est pas impactée.

L'avantage, c'est qu'une grande partie de tout ça peut s'écrire sous forme de pures fonctions : une même entrée => une même sortie. Je pense notamment aux vues (et aux sélecteurs). Ce qui rend ton code beaucoup plus simple à débugger et à tester unitairement. Et ça permet aussi de bénéficier gratuitement de mémoisation (cf. reselect par exemple) entre autres choses.

Le seul truc qui m'ennuie dans Flux, c'est que comme il existe différentes implémentations, on n'est pas vraiment guidé au début, et on a vite tendance à faire des conneries. Contrairement à Angular, Meteor, Ember, etc. qui te mettent sur des rails.

En réponse à ce problème, si jamais il t'ennuie également, il existe Elm. Le langage intègre lui-même ("nativement" si je puis dire) ce système Flux de CQRS. Si tu regardes ici on retrouve le triplet model, view, update :

1

StartApp.start { model = 0, view = view, update = update }

Avec la vue qui décrit uniquement la sortie en fonction du model et qui envoie des actions :

1
2
3
4
5
6

view address model =
  div []
    [ button [ onClick address Decrement ] [ text "-" ]
    , div [] [ text (toString model) ]
    , button [ onClick address Increment ] [ text "+" ]
    ]

Et la mise à jour du modèle en fonction des actions :

1
2
3
4
5
6

type Action = Increment | Decrement

update action model =
  case action of
    Increment -> model + 1
    Decrement -> model - 1

C'est un langage compilé, avec un compilateur extrêmement sympathique qui lorsque tu rencontres une erreur, t'explique ce qu'il essaie de faire, et pourquoi il n'y arrive pas, en Anglais dans le texte.

C'est un langage fortement typé, ce qui est très appréciable lorsqu'on sait utiliser les types à bon escient (c'est loin d'être évident, mais franchement c'est une excellente gymnastique quand on vient d'autres langages).

Et c'est un langage fonctionnel, qui permet notamment de composer des fonctions, etc. Ce dont tu auras nécessairement besoin dans une architecture flux (la fonction de sélection de tous les utilisateurs qui ont plus de 20 ans et dont le nom commence par 'A', ça peut s'écrire comme la composition de 2 fonctions).

Franchement ça vaut le coup d’œil. C'est dur à prendre en main quand on vient du JS, Java, Ruby ou autre, mais je trouve que c'est du très beau boulot.

J'espère que j'ai répondu à tes questions