DEV Community: Clara Belair

Gestion des erreurs RXJS -NGRX

Clara Belair — Fri, 09 Apr 2021 12:28:42 +0000

Dans un projet frontend, lorsqu'on fait un appel HTTP, il ne faut pas oublier la gestion des cas d'erreurs. Un appel HTTP peut être en erreur pour diverses raisons, on peut citer :

un serveur est inaccessible : le backend est "tombé" à cause d'une erreur interne par exemple
un timeout si la requête prend plus d'un certain temps à répondre
une erreur renvoyée par le backend avec un message spécifique : l'utilisateur n'a pas le droit d'accéder à cette ressource par exemple

Dans chaque cas, si le frontend ne gère pas ces erreurs, on se retrouve avec une application qui fonctionne mal ou, dans le pire des cas, plus du tout.

Dans cet article, je vais vous présenter la façon de gérer vos erreurs lors d'un appel HTTP pour un projet Angular. On verra d'abord la gestion des erreurs dans un subscribe, puis la gestion des erreurs dans un effect.

Prenons l'exemple d'un service HobbitsService et de la méthode findHobbits qui fait un appel HTTP pour retourner un observable d'une liste d'Hobbits.

@Injectable()
export class HobbitsService {
  constructor(private http: HttpClient) {}

  findHobbits(): Observable<Hobbit[]> {
    return this.http.get<Hobbit[]>('api/hobbits');
  }
}

On veut afficher la liste des Hobbits, et pendant que la requête HTTP est en cours, on affiche un loader à l'utilisateur.

Gérer les erreurs dans un `subscribe`

Exemple d'une erreur non traitée

Dans le composant HobbitsComponent une liste d'Hobbits est récupérée à l'initialisation du composant. Un loader est affiché lorsque le booléen isLoading est à true.

export class HobbitsComponent implements OnInit {

  isLoading = true;
  hobbits: Hobbit[] = [];

  constructor(private hobbitsService: HobbitsService) {}

  ngOnInit() {
    this.hobbitsService.findHobbits().subscribe(
      (hobbits: Hobbit[]) => {
        this.hobbits = hobbits;
        this.isLoading = false;
      }
    );
  }
}

Que se passe-t-il si l'appel findHobbits échoue ?

Le loader va être affiché, sans s'arrêter, alors que l'appel est terminé.

Pourquoi ?

La gestion du statut du loader est placé dans la fonction NEXT du subscribe. Quand une erreur survient, on ne passe pas dans NEXT mais dans la fonction ERROR du subscribe.

NEXT, ERROR, COMPLETE : les 3 fonctions d'un `subscribe`

subscribe a 3 fonctions optionnelles : NEXT, ERROR, COMPLETE.

this.hobbitsService.findHobbits().subscribe(
    () => console.log('Next'),
    () => console.log('Error'),
    () => console.log('Completed')
);

Si l'appel HTTP réussit, on voit les logs suivant :

Next
Completed

En cas de succès, la valeur est émise dans la fonction NEXT. Puis l'observable se ferme et il passe dans la fonction COMPLETE. C'est la fin du lifecycle de l'observable, aucune erreur n'a été émise.

Si l'appel HTTP échoue, on voit les logs suivant :

Error

En cas d'erreur, aucune valeur n'est émise dans la fonction NEXT. On passe dans la fonction ERROR, c'est la fin du lifecycle de l'observable.

A savoir :

Un appel HTTP est un observable qui "complete" après avoir émit une valeur. On a alors deux "chemins" possibles :

On ne peut pas être dans un COMPLETE et ERROR dans le lifecycle d'un observable, c'est soit l'un, soit l'autre.

Pour résoudre le problème

Pour gérer l'affichage du loader en cas d'erreur, on va traiter son état dans la fonction NEXT et dans la fonction ERROR.

export class HobbitsComponent implements OnInit {

  isLoading = true;
  hobbits: Hobbit[] = [];

  constructor(private hobbitsService: HobbitsService) {}

  ngOnInit() {
    this.hobbitsService.findHobbits().subscribe(
      (hobbits: Hobbit[]) => {
        this.hobbits = hobbits;
        this.isLoading = false;
      },
      () => {
        this.isLoading = false;
      }
    );
  }
}

Si l'appel HTTP réussit ou échoue, on aura le booléen isLoading à false et donc on n'aura plus le loader affiché à l'infini.

Traiter ou logger l'erreur

Dans le cas où on veut utiliser l'erreur pour debugger ou pour afficher un message précis à l'utilisateur par exemple, on peut utiliser l'erreur retournée comme ceci :

this.hobbitsService.findHobbits().subscribe(
    () => console.log('Next'),
    (error) => console.log('Error', error),
    () => console.log('Completed')
);

Gestion les erreurs dans un `effect`

Pour gérer vos effets de bord, par exemple vos appels backends, vous pouvez également utiliser la librarie NGRX et les effects. Personnellement c'est la manière dont je gère ces appels. Je ne donne pas la responsabilité au composant de récupérer les données.

L'action loadHobbits met un booléen isLoading à true dans le store. L'action loadHobbitsSuccess passe ce booléen à false et enregistre la liste des Hobbits dans le store. Le loader est affiché si le booléen isLoading est à true

Exemple sans gestion d'erreur

@Injectable()
export class HobbitsEffects {

  loadHobbits$ = createEffect(() =>
    this.actions$.pipe(
      ofType(loadHobbits),
      concatMap(() =>
        this.hobbitsService.findHobbits().pipe(
          map((hobbits: Hobbit[]) => loadHobbitsSuccess({ hobbits }))
        )
      )
    )
  );

  constructor(
      private actions$: Actions,
      private hobbitsService: HobbitsService
  ) {}
}

Que se passe-t-il si l'appel findHobbits échoue ?

Le loader va être affiché, sans s'arrêter, alors que l'appel est terminé.

Pourquoi ?

Seul l'action loadHobbitsSuccess met le booléen isLoading à false. Or, en cas d'erreur, on ne passe pas dans le map qui suit l'appel HTTP. Il faudrait attraper l'erreur à l'aide de l'opérateur catchError.

`catchError`

L'opérateur catchError va permettre, comme son nom l'indique, d'attraper l'erreur et de retourner un nouvel observable.

this.hobbitsService.findHobbits().pipe(
    map(() => /*SUCCESS*/),
    catchError(() => of(/*ERROR*/)),
);

Pour résoudre le problème

On va créer une nouvelle action loadHobbitsError qui va permettre dans notre exemple de mettre le booléen isLoading à false et donc d'arrêter d'afficher le loader en cas d'erreur.

@Injectable()
export class HobbitsEffects {

  loadHobbits$ = createEffect(() =>
    this.actions$.pipe(
      ofType(loadHobbits),
      concatMap(() =>
        this.hobbitsService.findHobbits().pipe(
          map((hobbits: Hobbit[]) => loadHobbitsSuccess({ hobbits })),
          catchError(() => of(loadHobbitsError()))
        )
      )
    )
  );

  constructor(
      private actions$: Actions,
      private hobbitsService: HobbitsService
  ) {}
}

A savoir :

Si vous êtes sur une version antérieure à la version 8 d'NGRX, en cas d'erreur "non attrapée" dans l'observable principal à l'aide d'un catchError, l'effect est complete. Depuis la version 8, si aucune erreur est "attrapée" dans l'observable principal, l'effect se resouscrit avec une limite maximum d'erreurs.

Appels multiples

En cas d'appels multiples, on peut choisir de retourner un observable avec des données pour gérer les cas d'appels qui ont échoués.

Dans l'exemple ci-dessous, on a une liste d'ids d'Hobbits donnée par l'action loadHobbitsBeers.
Pour chaque id d'Hobbit, on fait un appel HTTP via favoriteBeersByHobbitId qui va retourner une liste de string qui correspond aux bières préférées d'un Hobbit donné.
Ces appels sont effectués en parallèles, et si l'un d'eux échoue, on enregistre l'id du Hobbit, ainsi que la bière Prancing Pony's Ale par défaut. Ainsi, les appels qui ont échoué sont traités avec des données par défaut.

@Injectable()
export class HobbitsEffects {
  loadHobbitsDetails$ = createEffect(() =>
    this.actions$.pipe(
      ofType(loadHobbitsBeers),
      mergeMap(({ hobbitsIds }) =>
        forkJoin(
          hobbitsIds.map(hobbitId =>
            this.hobbitsService.favoriteBeersByHobbitId(hobbitId).pipe(
              map((beers: string[]) => ({
                id: hobbitId,
                beers,
              })),
              catchError(() =>
                of({
                  id: hobbitId,
                  beers: [`Prancing Pony's Ale`]
                })
              )
            )
          )
        )
      ),
      map((hobbitsBeers: HobbitsBeers[]) => loadHobbitsBeersSuccess({ hobbitsBeers }))
    )
  );

  constructor(
      private actions$: Actions,
      private hobbitsService: HobbitsService
  ) {}
}

Traiter ou logger l'erreur

Dans le cas où on veut utiliser l'erreur pour debugger ou pour afficher un message précis à l'utilisateur par exemple, on peut utiliser l'erreur retournée comme ceci :

this.hobbitsService.findHobbits().pipe(
  map((hobbits: Hobbit[]) => /*SUCCESS*/),
  catchError((error) => { 
      console.log('ERROR', error);
      return of(/*ERROR*/);
  })
)

Git au quotidien : les seules commandes que j'utilise vraiment

Clara Belair — Fri, 09 Apr 2021 12:28:20 +0000

Je ne suis pas une experte Git, je ne connais pas toutes les commandes, mais depuis quelques années, j'ai une routine et quelques commandes que j'utilise au quotidien. Ces commandes me permettent de gérer 95% de mes besoins.

Avec seulement 7 commandes, je peux gérer mon projet au quotidien. Voici la liste des commandes que je vais présenter à travers mon workflow de développement :

git fetch
git checkout
git branch
git add
git commit
git push
git rebase

Démarrer mon développement

Je présente deux façons de démarrer mon développement. Je vais commencer par GitLab, un outil ultra répandu, que j'ai toujours connu via mes différentes expériences, chez les petits comme chez les gros clients. Il m'est arrivé de démarrer mon développement sans passer par GitLab, donc je présenterai également cette deuxième option.

La branche principale de développement de votre projet peut s'appeler master, dev, main... Cela dépend de votre projet, et peut importe son nom, c'est la branche sur laquelle toute l'équipe fait partir ses branches pour faire son développement. Dans mon exemple, la branche principale de développement s'appelle main.

Cas 1 : je démarre mon développement via GitLab

Quand je démarre un développement, je créé ma branche à partir de l'issue GitLab, il y a un bouton pour créer une branche, et ça la rattachera à votre issue. Ici mon issue s'appelle : "Add new feature", et la branche va s'appeler automatiquement add-new-feature.

Une fois la branche créée via GitLab, je veux tout simplement la récupérer et me placer sur cette branche.

Récupération de ma branche

Je récupère ma branche en local en faisant :

git fetch

Je peux voir dans ma console, le nom de ma branche apparaître.

Se déplacer sur ma branche

Pour commencer mon développement, je vais me déplacer sur ma branche. Je fais cette commande :

git checkout add-new-feature

Cas 2 : je démarre mon développement à la mano

Récupération des modifications du projet

Je fais la commande suivante :

git fetch

Se déplacer sur la branche principale

Je me place sur la branche principale de développement de mon projet. Pour me déplacer, j'utilise git checkout. Ici, la branche principale de développement de mon projet s'appelle main, donc je fais :

git checkout main

Écraser la branche principale pour la mettre à jour

J'écrase la branche main locale par la branche distante main :

git reset --hard origin/main

A partir de ce moment là, je sais que la branche main locale est la même que la branche distante. Je m'assure ainsi de créer ma branche à partir de la branche principale à jour.

Création de ma branche et se déplacer sur celle-ci

Je veux créer ma branche à partir de main pour faire mon développement et me déplacer sur la branche créée. Je veux appeler ma branche add-new-feature, je vais donc faire la commande suivante :

git checkout -b add-new-feature

En cours de développement

Je développe sur ma branche, et une fois tout ou partie de mon développement terminé je fais les commandes suivantes :

J'ajoute mes modifications

J'ajoute toutes mes modifications, je fais :
git add .
ou
git add -A

Cas 1 : je commit pour la première fois

Je créé mon commit avec ce message feat(example): add new feature. Je fais la commande suivante :
git commit -m "feat(example): add new feature"
ou
git commit (va m'ouvrir l'éditeur de mon choix, vim par défaut)

Si le Conventional-Changelog ne vous dit rien, voici un article pour vous.

Cas 2 : j'ajoute des modifications à mon commit précédent

Si je veux ajouter un développement supplémentaire sur ma branche, je travaille en général avec un seul commit pour mon développement, donc j'utilise git commit --amend :

git commit --amend
ou
git commit --amend --no-edit

Je ne travaille pas avec des commits intermédiaire du genre :

feat(example): add something
feat(example): delete something
feat(example): update something else

Pour ensuite "squash" ces commits pour avoir 1 seul commit :

feat(example): add new feature

Je fais un seul commit, mon commit final, et j'amend ce commit pour n'avoir qu'un seul commit qui sera mergé sur la branche de développement. C'est une question d'habitude et de préférence.

A la fin de mon développement

Prérequis si vous créez vos branches en local : configurez votre git avec cette commande pour ne pas avoir à préciser à chaque fois l'upstream : git config --global push.default current

Je pousse mes modifications

Je fais cette commande pour pousser mon développement :
git push
ou
git push --force-with-lease

Si vous n'êtes pas familier avec l'option --force-with-lease, je vous recommande cet article.

Mise à jour de ma branche par rapport à la branche principale

Dans le cas où la branche principale de développement à évoluée par rapport à ma branche de développement, je dois faire un git rebase.

Je récupère toutes les modifications faites par les autres personnes de mon projet :

git fetch

Je mets à jour ma branche par rapport à main (la branche principale).

git rebase origin/main

Je gère les conflits éventuels via mon IDE pour plus de simplicité. Vous avez également des outils Git qui permettent de gérer les conflits plus facilement.

Et ensuite je push quand j'ai terminé mon rebase :

git push --force-with-lease

J'utilise également le rebase interactive -i | --interactive pour certaines situations. C'est une option que je conseille de regarder même si je ne l'utilise qu'occasionnellement (la doc du rebase).

Les commandes supplémentaires

Utilisées occasionnellement

Quand je veux voir l'historique des commits sur une branche :
git log

Quand je veux voir mes modifications en cours non commités :
git status

Quand je veux sauvegarder un "brouillon" de mon développement en cours sur une branche :
git stash
Quelques exemples de stash sont listés ici.

Utilisées rarement

Quand je démarre sur un nouveau projet :
git clone

Quand je définis mon nom d'auteur et l'email associé :
git config --global user.name "Clara Belair"
git config --global user.email clara.belair@example.com

Pourquoi je préfère `git fetch` à `git pull` pour récupérer les modifications distantes ?

On me pose souvent la question pourquoi je fais un git fetch au lieu d'un git pull. Attention, ce ne sont pas des commandes équivalentes. Si vous faites un git pull, par défaut, il y a un merge qui est fait juste après le fetch.

Voici la description de git pull (https://git-scm.com/docs/git-pull/fr) :

"Intègre les modifications d’un dépôt distant dans la branche actuelle. Dans son mode par défaut, git pull est l’abréviation de git fetch suivi de git merge FETCH_HEAD."

Pour éviter toute mauvaise surprise, je conseille donc de faire un git fetch pour récupérer les modifications distantes. Ou alors soyez conscient des commandes exécutées derrière git pull par défaut et de leurs conséquences sur votre branche actuelle.

DEV Community: Clara Belair

Gestion des erreurs RXJS -NGRX

Gérer les erreurs dans un subscribe

Exemple d'une erreur non traitée

NEXT, ERROR, COMPLETE : les 3 fonctions d'un subscribe

Pour résoudre le problème

Traiter ou logger l'erreur

Gestion les erreurs dans un effect

Exemple sans gestion d'erreur

catchError

Pour résoudre le problème

Appels multiples

Traiter ou logger l'erreur

Git au quotidien : les seules commandes que j'utilise vraiment

Démarrer mon développement

Cas 1 : je démarre mon développement via GitLab

Récupération de ma branche

Se déplacer sur ma branche

Cas 2 : je démarre mon développement à la mano

Récupération des modifications du projet

Se déplacer sur la branche principale

Écraser la branche principale pour la mettre à jour

Création de ma branche et se déplacer sur celle-ci

En cours de développement

J'ajoute mes modifications

Cas 1 : je commit pour la première fois

Cas 2 : j'ajoute des modifications à mon commit précédent

A la fin de mon développement

Je pousse mes modifications

Mise à jour de ma branche par rapport à la branche principale

Les commandes supplémentaires

Utilisées occasionnellement

Utilisées rarement

Pourquoi je préfère git fetch à git pull pour récupérer les modifications distantes ?

Gérer les erreurs dans un `subscribe`

NEXT, ERROR, COMPLETE : les 3 fonctions d'un `subscribe`

Gestion les erreurs dans un `effect`

`catchError`

Pourquoi je préfère `git fetch` à `git pull` pour récupérer les modifications distantes ?