Corrections des articles

docs/01_decouverte_des_bases.md

@@ -143,7 +143,9 @@ Les ressources du `Provider` sont libérées `<6>` avec celles du `ProviderConta
 > Un état ne sera initialisé qu'à partir du moment où il sera lu, reflétant la nature paresseuse (lazy) du `ProviderContainer`.
 
 Pour des questions de consommation mémoire, il est parfois nécessaire d'écourter la vie d'un `Provider` en libérant ses ressources dès qu'il n'est plus utilisé.
-Ce comportement additionnel du `Provider` est à ajouter dès sa déclaration avec le _modifier_ `autodispose` :
+Ce comportement additionnel du `Provider` est ajouté avec le _modifier_ `autodispose` :
+
+> Un _modifier_ est une méthode supplémentaire appelée lors de la déclaration d'un `Provider`.
 
 [source : autodispose_test.dart](https://gitlab.ippon.fr/adbonnin/article_flutter_riverpod/-/blob/main/test/article_01/autodispose_test.dart)
 ```dart

docs/02_integration_avec_flutter.md

 # Riverpod par la pratique : Intégration avec Flutter
 
 Cet article à pour objectif de vous faire découvrir l'intégration de Riverpod dans une application Flutter.
-Il fait suite au précédent article sur la découverte des bases et s'appuie pour sur ses notions pour en ajouter de nouvelles.
+Il fait suite au précédent article sur la découverte des bases et s'appuie sur ces notions pour en ajouter de nouvelles.
 Le code source est disponible sur le [GitLab Ippon](https://gitlab.ippon.fr/adbonnin/article_flutter_riverpod/-/tree/main/lib/article_02) et les exemples sur la [GitLab page](http://adbonnin.pages-gitlab.ippon.fr/article_flutter_riverpod/#/) associée.
 
 ## Intégration dans une application
 
 Dans Flutter, tout est widget.
-En suivant ce principe, Riverpod s'adapte à Flutter avec le widget `ProviderScope` dont la responsabilité est de partager ses états aux widgets enfants.
+En suivant ce principe, Riverpod s'adapte à Flutter avec le widget `ProviderScope` dont la responsabilité est de partager les états qu'il contient à ses widgets enfants.
 Plusieurs manières permettent d'accéder à ces états, le widget `Consumer` étant la solution la moins intrusive : 
 
 [_source : consumer_example.dart_](https://gitlab.ippon.fr/adbonnin/article_flutter_riverpod/-/blob/main/lib/article_02/consumer_example.dart)
@@ -45,18 +45,18 @@ class MyExample extends StatelessWidget {
 
 Un `Provider` est défini pour retourner `'Hello world'` `<1>`.
 Les états sont disponibles pour les widgets enfants à partir du parent `ProviderScope` `<2>`.
-La méthode `builder` du `Consumer` `<3>` fournit en paramètre un `WidgetRef` qui permet de surveiller le provider et afficher son état `<4>`.
+La méthode `builder` du `Consumer` `<3>` fournit en paramètre un `WidgetRef` permettant de surveiller le provider et afficher son état `<4>`.
 
 Le `ProviderScope` vient encapsuler dans un widget le `ProviderContainer` pour le rendre accessible aux widgets enfants par l'intermédiaire d'un `WidgetRef`.
 De la même manière que le `ProviderRef`, le `WidgetRef` est une façade pour le `ProviderContainer` et le fonctionnement attendu des méthodes `read` et `watch` est identique.
 
 L'utilisation de la méthode `watch` indique que le widget sera reconstruit à chaque changement de l'état.
 Étant donné que l'état du `Provider` `<1>` conservera toujours la même valeur, la méthode `read` aurait eu le même comportement que la méthode `watch` `<4>`.
-Ce choix est motivé par la [documentation officielle](https://riverpod.dev/docs/concepts/reading/#using-refread-to-obtain-the-state-of-a-provider) qui favorise le fonctionnement réactif de la méthode `watch` par rapport à la méthode `read`.
+Ce choix est néanmois motivé par la [documentation officielle](https://riverpod.dev/docs/concepts/reading/#using-refread-to-obtain-the-state-of-a-provider) qui favorise le fonctionnement réactif de la méthode `watch` par rapport à la méthode `read`.
 
 D'un point de vue conceptuel, à chaque fois qu'un widget utilise un `Provider` il en dévient dépendant.
 Cette dépendance ne pose pas de problème sur le court terme mais peut s'avérer coûteuse sur le long terme.
-A partir du moment où ces widgets sont utilisés il faut tenir compte de l'état des `Provider`s dont ils dépendent.
+À partir du moment où ces widgets sont utilisés il faut tenir compte de l'état des `Provider`s dont ils dépendent.
 Cette préoccupation est particulièrement présente à l'écriture des tests où chaque `Provider` doit être correctement initialisé.
 
 Le widget `Consumer` est une manière simple d'accéder au `WidgetRef` mais vient alourdir l'écriture de la méthode `build` avec un widget supplémentaire.
@@ -124,11 +124,11 @@ Ce service est un `StateNotifier` dont le state est un nombre qui peut être inc
 La classe `ConsumerWidget` remplace `StatelessWidget` `<4>` et ajoute le paramètre `WidgetRef` au niveau de la méthode `build` `<5>`.
 Le `WidgetRef` est utilisé de la même manière qu'avec le `Consumer`, les modifications de l'état sont écoutées `<6>` pour être affichées `<7>`.
 Le même `WidgetRef` est ensuite passé en paramètre de la méthode appelée lors d'un clique sur le bouton `<8>`.
-Lors de cette méthode, la lecture du `notifier` présent dans le `countServiceProvider` donne accés au service pour appeler la méthode `increment`.
+Lors de cette méthode, la lecture du `notifier` présent dans le `countServiceProvider` donne accès au service pour appeler la méthode `increment`.
 
-Remplacer la classe étendue par le `Widget` est une solution qui peut se réléver contraignante voir ridibitoire pour certains développeurs.
+Remplacer la classe étendue par le `Widget` est une solution qui peut se révéler contraignante voire rédhibitoire pour certains développeurs.
 Cependant, ce choix d'implémentation simplifie l'intégration de Riverpod en donnant accès directement accès au `WidgetRef` depuis la méthode `build`.
-Comme pour le `BuildContext`, ce `WidgetRef` est passé aux méthodes qui ont besoin d'accéder aux états.
+Comme pour le `BuildContext`, ce `WidgetRef` est à passer aux méthodes qui ont besoin d'accéder aux états.
 
 ## StatefulWidget et ConsumerStatefulWidget
 
@@ -208,8 +208,8 @@ Contrairement au `ConsumerWidget`, la signature de la méthode `build` reste ide
 La première valeur du service est lue à l'initialisation du widget `<5>` puis ses modifications sont écoutées `<7>` pour être affichées `<8>`.
 Le `WidgetRef` en propriété est utilisé pour lire le service et incrémenter l'état.
 
-A la différence du `StatelessWidget`, le `WidgetRef` est directement accessible avec la propriété `ref`.
-Ce choix d'implémentation donne accés aux états de n'importe où dans le widget en conservant un code lisible ; le `WidgetRef` n'étant plus passé de méthode en méthode.
+À la différence du `StatelessWidget`, le `WidgetRef` est directement accessible avec la propriété `ref`.
+Ce choix d'implémentation donne accès aux états de n'importe où dans le widget en conservant un code lisible ; le `WidgetRef` n'étant plus passé de méthode en méthode.
 
 Jusqu'à présent, les `Provider`s étaient surveillés avec la méthode `watch`, dans le `builder` du `Consumer` ou dans la méthode `build` des widgets.
 Dans les cas spécifiques où la surveillance est inutile le `Provider` est simplement lu avec la méthode `read`.
@@ -314,7 +314,7 @@ class _CounterState extends ConsumerState<Counter> {
 
 Le service et le provider associé sont identiques à l'exemple précédent `<1>`.
 Un chiffre aléatoire est retourné par le `Provider` `randomProvider` `<2>`.
-Le `Provider` `multiplyByRandomProvider` `<3>` vient écouter le provider `countServiceProvider` et retourne sa valeur multipliée le `randomProvider`.
+Le `Provider` `multiplyByRandomProvider` `<3>` vient écouter le provider `countServiceProvider` et retourne sa valeur multipliée par celle du `randomProvider`.
 Un premier `ProviderScope` est déclaré `<4>` avec un `Counter` associé `<5>`. 
 Un second `ProviderScope` est déclaré `<6>` en temps que widget enfant du précédent avec également un `Counter` associé `<8>`.
 Ce second `ProviderScope` vient surcharger la valeur du `counterServiceProvider` `<7>`.
@@ -323,9 +323,11 @@ Comme précédemment, le widget `Counter` vient lire `<9>`, surveiller `<10>` et
 Les deux widgets `Counter`s partagent le même état du `Provider` `randomProvider` `<2>`.
 Ce n'est qu'à partir du moment où le `ProviderScope` surcharge le `countServiceProvider` `<7>` que chacun dispose de sa propre valeur.
 Le provider `multiplyByRandomProvider` dépendant de `countServiceProvider` dispose également de son propre état.
-Cette dépendance a été indiqué lors de la déclaration du `multiplyByRandomProvider` `<3>` pour que Riverpod en ai conscience.
+Cette dépendance a été indiqué lors de la déclaration du `multiplyByRandomProvider` `<3>` pour que Riverpod en ait conscience.
 Il en résulte deux `Counter` qui interagissent avec des états indépendants avec un multiplicateur commun.
 
 ## L'aventure continue
 
-Maintenant que toutes les bases sont posées vous devriez être en mesure d'utiliser Riverpod dans votre application.
+Maintenant que toutes les bases sont posées vous devriez être en mesure de comprendre et d'utiliser Riverpod dans vos applications.
+
+![Zelda sword](images/zelda_sword_2.png)
\ No newline at end of file