L'interrogation de conception sur l'utilisation correcte de la notion de «effet secondaire» de ngrx/effets

Question

J'écris ceci pour savoir si je comprends bien ou non.

Sur exemples trouvés en ligne, le modèle va généralement comme ceci (exemple ici sur ajouter/supprimer des actions sur l'état et sur une base de données distante):

effects.ts:

@Effect() 
add$ = this.action$ 
    .ofType(ADD) 
    .switchMap((action: Action) => { 
    return this.http.put(...) 
     .map(response => response.json()) 
     .map(response => Observable.of({ type: ADD_SUCCESS, payload: action.payload })) 
     .catch(response => Observable.of({ type: ADD_FAIL, payload: response.status })) 

réducteur

. ts

... 
switch (action.type){ 
    case 'ADD_SUCCESS': 
    ... 
    return new_state; 
    case 'ADD_FAIL': 
    return state; 
} 

Il fonctionne, mais la vitesse d'exécution que ressentie par l'utilisateur dépend de la vitesse du réseau est. Alors je suis venu avec un motif que les paris sur la forte probabilité qu'aucune erreur ne sera retourné de l'API:

reducer.ts

... 
switch (action.type){ 
    case 'ADD': 
    ... // make the adequate addition 
    return new_state; 
    case 'ADD_FAIL': 
    ... // delete the addition previously made 
    return new_state; 
} 

effects.ts:

@Effect() 
add$ = this.action$ 
    .ofType(ADD) 
    .switchMap((action: Action) => { 
    return this.http.put(...) 
     .map(response => response.json()) 
     .catch(response => Observable.of({ type: ADD_FAIL, payload: action.payload })) 

Dans ce pattern, l'action d'enregistrer dans la base de données est vraiment un "effet secondaire". Dans le cas improbable mais possible où l'API renvoie une erreur, une deuxième action est effectuée pour annuler la première action.

Mais je n'ai pas encore trouvé ce design dans les exemples donnés en ligne: Puisque je suis un développeur amateur, je me demande si j'ai raté quelque chose qui le rend mal/dangereux/inefficace à la fin.

Answer 1

Je ne dirais pas qu'il y a quelque chose de mal/dangereux/inefficace à ce sujet. Tout est subjectif à vos exigences de programme. Si vous traitez vraiment réseaux lents, alors cela doit être pris en compte.

Mais dans ce cas, si un problème survient, l'utilisateur ne le saura pas jusqu'à ce que l'action se termine de toute façon. Avec le scénario d'un réseau lent et ayant à la fois SUCCESS et FAIL actions, alors l'utilisateur est plus confiant dans les données qu'ils ont parce qu'une action SUCCESS a dû déclencher. Si vous ignorez l'action SUCCESS, l'utilisateur peut être absent et ne pas savoir que ses données sont incorrectes jusqu'à ce que l'action FAIL se produise. Le résultat peut être mineur, ou il peut interrompre le flux de travail de l'utilisateur.

Maintenant, en général, le temps qu'il faut pour soumettre une demande put ou post et obtenir une réponse devrait être plutôt court. Et vos actions SUCCESS ou FAIL ne doivent pas être si grandes qu'elles prennent beaucoup de temps à calculer.

Prenez par exemple un système de caisse. Un utilisateur va à la caisse et posts au serveur. Vous ne voulez pas accéder à une page de confirmation avant de savoir si le post a réussi ou non. Donc, avoir des actions séparées SUCCESS et FAIL sont nécessaires dans cette situation. Je pense que cela fournit la meilleure expérience utilisateur pour être sûr que les données qu'ils voient sont exactes et ne pas annuler les modifications après une panne. Si l'utilisateur posts ou puts quelque chose au serveur, l'action SUCCESS devrait alors l'ajouter à l'état de l'application et pas avant, ainsi que la notification possible de l'utilisateur.Une action FAIL gérerait la notification de l'utilisateur, la journalisation potentielle, etc. en fonction de l'application.

Autre exemple: Supposons qu'un utilisateur modifie un profil en ligne. Si vous cliquez sur "Enregistrer", vous voulez que l'utilisateur soit averti lors d'une sauvegarde réussie sur le serveur. De cette façon, ils ne s'éloignent pas de la page en pensant «J'espère que cela a sauvé, je n'ai pas eu de réponse».

Je dirais que dans la plupart des scénarios, il est approprié d'avoir à la fois des actions SUCCESS et FAIL. Mais comme je l'ai dit, tout est subjectif pour votre application et ce qui est acceptable pour vos utilisateurs, dans votre environnement.

Espérons que ça aide.