10. Conclusion intermédiaire

Nous avons rencontré, un exemple après l'autre, tout ce qu'il faut pour écrire le client [Ionic] de [RdvMedecins] :

Besoin	En Flutter	En Ionic + Angular
un écran	un arbre de widgets, décrit par build()	un composant : une classe TypeScript et un gabarit HTML, fait de composants d'Ionic
des données qui changent	l'état d'un StatefulWidget (setState), ou un ChangeNotifier	des signaux (signal, computed, effect)
des formulaires	TextField et ses contrôleurs, InputDecoration.errorText	ion-input, ngModel, les formulaires réactifs (FormGroup, Validators)
plusieurs écrans, des adresses, des gardes	go_router (GoRoute, ShellRoute, redirect)	le routeur d'Angular, ion-router-outlet, ion-tabs, les gardes (CanActivateFn)
des données partagées	provider (ChangeNotifierProvider, context.watch / read)	des services à signaux, fournis par l'injection de dépendances (inject)
attendre	Future, Stream, async / await, FutureBuilder	Promise, Observable (RxJS), async / await, resource, toSignal
des requêtes HTTP	le paquet http, un client qui gère les cookies, une couche d'accès à l'API	HttpClient, le proxy de développement, CapacitorHttp sur Android, une couche d'accès à l'API
deux langues	des dictionnaires JSON, intl, flutter_localizations	des dictionnaires JSON, l'objet Intl, l'attribut locale des composants d'Ionic
un stockage sur l'appareil	shared_preferences	@capacitor/preferences

Le client [Flutter] utilisait quelques paquets, un par besoin ; le client [Ionic] n'en utilise aucun en dehors d'[Angular], d'[Ionic] et de [Capacitor] : [Angular] apporte le routeur, les formulaires, le client HTTP, l'injection de dépendances et les signaux ; [Ionic] les composants, la pile des pages, les fenêtres, les onglets, le calendrier ; [Capacitor] le stockage et les requêtes natives. Et sur [Android], le cookie du jeton, que le client [Flutter] devait gérer lui-même, est rangé et renvoyé par le code natif, comme le fait un navigateur. Il reste à assembler le tout.