22/02/2021

Comprendre le fonctionnement des composants FLUTTER

La première difficulté quand on se lance dans l'apprentissage de FLUTTER, c’est le langage DART. Encore un langage à apprendre, avec son lot de bizarreries et de concepts abscons.

Enfin, personnellement, c’est ce que je m’étais dit.

Et bien finalement DART est très proche du C, voire du C# et Javascript. Donc pas de soucis de ce côté là pour qui connaît au moins l’un de ces deux langages. En tout cas pas tout de suite...

Ce qui m’a paru le plus complexe, au début, c'est la construction du Stateful Widget et son emboîtement avec son objet State.

De prime abord, cette articulation m’a paru plutôt étrange et difficile à intégrer, à rentrer dans le coco comme dit l’autre (pas si) débile de la télé ;-)

Enfin, à bien y regarder, ce n’est pas si mystérieux.

Autant un simple SatelessWidget se déclare en une seule classe qui étend la classe Stateful Widget et qui surcharge une méthode ‘build’, qui doit renvoyer un Widget.

Il se doit d’utiliser ce type de Widget Stateless quand les données initiales sont finales et qu'elles ne vont pas changer. Un composant figé, en somme.

Quant au StatefullWidget, c’est une autre paire de manches. Il s’emploie quand les données sont susceptibles de changer et que, en conséquence, les représentations de ces données (Text, Button, etc... ) vont devoir être redessinées à l’écran à chaque fois que les données changent.

C’est pourquoi un StatefullWidget se déclare en deux classes ; l'une pour le Widget et l’autre pour son état.

Mais comme son nom ne l’indique pas, c’est la deuxième classe qui va contenir le code d’initialisation des valeurs initiales et la fameuse méthode build, qui va contenir l'arbre des Widget à afficher. Autant dire tout ce qui est intéressant.

La première classe, celle qui étend StatefullWidget, n’est qu’une coquille qui ne s’occupe que d’initialiser son état.

En quelque sorte elle est chargée de faire rentrer l’escargot dans sa coquille :)

A l’instar de React, il faut employer la méthode setState pour signaler un changement de données et provoquer ainsi la propagation du changement dans l'arbre des Widgets. Tous les Widgets concernés par le changement seront reconstruits illico en accord avec les nouvelles données, et replacés dans l’arbre.

En fait il y a deux arbres, un ‘Widget Tree’ et un ‘Element Tree’, auquel s’ajoute un objet ‘State Objet’, mais ce sera le sujet d’un autre post.