Une idée de cours pour Flutter

Je viens — sous toutes réserves, c’est pas pareil au brouillon et au propre en Debug et en release — de me débarrasser d’un problème qui me titillait sur Flutter depuis un sacré moment, et qui ne se pose même pas avec SwiftUI, c’est la gestion de l’état global d’une appli, en somme comment faire pour qu’un widget tienne compte de l’état d’un autre. Là, le setState ne suffit plus. J’ai alors essayé d’utiliser une bibliothèque réputée aisée à l’usage, provider, qui m’a fait trébucher je ne vous dirai pas combien de fois ni combien de temps, parce que c’est la honte. Mais yes, le problème a cédé enfin. Mais je me dis que ce qui serait bien, ce serait d’avoir un petit cours là-dessus, et de faire le tri, pour choisir entre Redux, BloC, et autres manières de gérer ça, en évitant ou non InheritedWidget.
Parce que Flutter, c’est pas ce qu’on croit. SwiftUI, qui nous mâche le travail, qu’est-ce que c’est agréable à côté. Avec les Google trucs, quoi qu’ils fassent, c’est les mains dans le cambouis jusqu’au cou, c’est comme ça. Et les Docs, c’est bien, il y a des exemples, mais jamais les bons, il faut fouiner, s’angliciser la comprenette, c’est pas rien.
Ça parle à quelqu’un, mon truc ?

Merci François pour ce retour, je comprends ton soucis et je me suis posé moi même cette question quand j’ai commencé à utilisé Flutter, et aussi quand j’ai préparé le cours.
J’ai hésité à traiter ces « kit d’architecture tout prêts » (provider, redux, etc.) mais j’ai préféré les éviter car ils ne sont pas indispensables et ils créent à mon goût plus de problèmes qu’ils n’en résolvent.

En théorie :
L’idée est de faire de l’architecture avec une techno spécifique en échange de la promesse de
quelques lignes de code en moins (par rapport au même concept en créant des classes standard en Dart).

En pratique tout n’est pas si rose :

  • il faut passer pas mal de temps à les apprendre (tu peux en témoigner)
  • ils constituent une dépendance avec tout ce que ça implique (mises à jour, etc.)
  • ils permettent souvent de faire des choses non recommandées (« faire en sorte qu’un widget tienne en compte l’état de l’autre » n’est pas une bonne idée à mon avis)

En choisissant de l’architecture classique comme on l’a vu dans le cours, tu as une solution générique qui marche à la fois en Flutter/Dart et en SwiftUI/Swift (et même d’ailleurs dans les autres langages que l’on utilise pas ici). Plus besoin d’apprendre le dernier truc à la mode, qui change tous les 6 mois, et ça c’est vraiment confortable.

Qu’en penses tu ?

C’est vrai, il faut du temps pour les apprendre; c’est vrai, c’est une dépendance, mais je ne me suis pas encore trop confronté aux problèmes des mises à jour, et, en plus, c’est très intriqué avec la doc officielle, voire presque présenté comme si c’était juste un truc qui fait presque partie du Flutter officiel.
Quant au problème que pose une gestion globale de l’état, SwiftUI ne le fait-il pas un peu avec les @Binding ? Les ObservedObjects ?
Dans ce cas, je vais revoir comment m’y prendre si je peux y arriver autrement, sans provider. Mais ça me chagrine d’avoir perdu du temps à me coltiner ça.
:trumpet: Flûte, alors. Toujours tout à refaire. Bon, ben, c’est parti… :footprints:

Avec les bindings on peut échanger des valeurs entre des widgets, mais c’est un peu comme un retour de fonction. Le widget qui remplit le bindings ne connaît pas le widget parent ce qui permet de le réutiliser avec n’importe quel autre widget.
En revanche si un widget connaît un widget, alors il ne devient dépendant de celui-ci.

Oui. J’ai finalement pu me débrouiller autrement, j’ai écouté, remis provider au placard, et trouvé une autre solution. L’idée c’était que, en fonction de l’état de deux Widgets (des TextField selon qu’ils avaient été utilisés ou non) un troisième Widget changeait de nature (un Text servant de message d’alerte versus une ListView imitant un picker). C’était pratique, parce que pour court-circuiter provider, j’ai dû tous les rassembler dans un gros Widget conglomérat. Bon, j’ai aussi la solution de revoir toute l’architecture, de faire des alertes qui soient des alertes etc. Mais même si je n’ai guère le temps et que je le fasse quand même, je risque d’avoir d’autres problèmes comme ça.