Apollo expose deux types d'erreurs à travers son API: erreurs GraphQL , qui sont retournés dans le cadre de la réponse que errors
, à côté data
, et les erreurs de réseau qui se produisent lorsqu'une requête échoue. Une erreur réseau se produit lorsqu'un serveur ne peut pas être atteint ou si l'état de la réponse est autre que 200 - les requêtes qui ont errors
dans la réponse peuvent toujours avoir un état de 200. Mais une requête non valide, par exemple, entraînera un état 400 et une erreur de réseau dans Apollo Client.
Apollo Client propose en fait quatre façons différentes de gérer les erreurs de mutation:
1.) L'appel de la mutate
fonction retournée par le hook renvoie une promesse. Si la demande aboutit, la promesse se résoudra en un objet de réponse qui inclut celui data
renvoyé par le serveur. Si la demande échoue, la Promesse rejettera avec l'erreur. C'est pourquoi vous voyez un message "Rejet non géré" dans la console - vous devez gérer la promesse rejetée.
login()
.then(({ data }) => {
// you can do something with the response here
})
.catch(e => {
// you can do something with the error here
})
ou avec la syntaxe async / wait:
try {
const { data } = await login()
} catch (e) {
// do something with the error here
}
Par défaut, la promesse rejettera sur soit des erreurs GraphQL ou des erreurs de réseau. En définissant errorPolicy sur ignore
ou all
, cependant, la promesse ne rejettera que sur les erreurs réseau. Dans ce cas, les erreurs GraphQL seront toujours accessibles via l'objet de réponse, mais la promesse sera résolue.
2.) La seule exception à ce qui précède se produit lorsque vous fournissez une onError
fonction. Dans ce cas, la promesse sera toujours résolue au lieu de rejeter, mais si une erreur se produit, onError
elle sera appelée avec l'erreur résultante. Le errorPolicy
paramètre que vous définissez s'applique ici également - onError
sera toujours appelé pour les erreurs réseau, mais ne sera appelé qu'avec des erreurs GraphQL lorsque vous utilisez la valeur par défaut errorPolicy
de none
. L'utilisation onError
équivaut à intercepter la promesse rejetée - elle déplace simplement le gestionnaire d'erreurs du site d'appel de la mutate
fonction vers le site d'appel du hook.
3.) En plus de la mutate
fonction, le useMutation
hook renvoie également un objet résultat. Cet objet expose également toutes les erreurs rencontrées lors de l'exécution de la mutation. Contrairement aux fonctions de gestionnaire d'erreurs que nous avons décrites ci-dessus, cet error
objet représente l' état de l'application . Les objets error
et ainsi data
exposés existent à titre de commodité. Ils équivalent à faire ceci:
const [mutate] = useMutation(YOUR_MUTATION)
const [data, setData] = useState()
const [error, setError] = useState()
const handleClick = async () => {
try {
const { data } = await mutate()
setData(data)
catch (e) {
setError(e)
}
}
Un état d'erreur comme celui-ci peut être utile lorsque vous souhaitez que votre interface utilisateur reflète le fait qu'il y a une erreur. Par exemple, vous pouvez modifier la couleur d'un élément jusqu'à ce que la mutation s'exécute sans erreur. Au lieu d'avoir à écrire vous-même le passe-partout ci-dessus, vous pouvez simplement utiliser l'objet de résultat fourni.
const [mutate, { data, error }] = useMutation(YOUR_MUTATION)
REMARQUE: vous pouvez utiliser l'état d'erreur exposé pour mettre à jour votre interface utilisateur, mais cela ne remplace pas la gestion réelle de l'erreur. Vous devez fournir un onError
rappel ou catch
l'erreur afin d'éviter les avertissements concernant un rejet de promesse non géré.
4.) Enfin, vous pouvez également utiliser apollo-link-error pour ajouter une gestion globale des erreurs à vos demandes. Cela vous permet, par exemple, d'afficher une boîte de dialogue d'erreur, quel que soit le point d'origine de votre demande.
Laquelle de ces méthodes que vous utilisez dans votre application dépend fortement de ce que vous essayez de faire (global vs local, état vs rappel, etc.). La plupart des applications utiliseront plusieurs méthodes de gestion des erreurs.