#Gérer les perturbations réseau et les erreurs

Access est, par définition, dynamique. Cela signifie qu'afin d'afficher la bonne action au bon moment pour un utilisateur particulier, il doit communiquer avec votre Dashboard. Cela présente de nombreux avantages, comme des apparences, des textes et des options personnalisées, mais avec une légère limite : ça peut échouer.

Nous, les développeurs, le savons mieux que quiconque : si nous pensons que quelque chose pourrait échouer, il échouera très certainement à un moment donné. Et c'est normal. S'y préparer est même un concept appelé Chaos Engineering.

Chez Poool, nous avons décidé de gérer une partie de ce problème pour vous : si nous ne pouvons pas communiquer avec votre Dashboard en moins de 10 secondes ou si nous ne parvenons pas à le faire, nous déclencherons un timeout, nous afficherons un paywall par défaut (que vous pouvez configurer), et nous déclencherons un événement onError vous permettant d'afficher votre propre fallback si celui par défaut n'est pas à votre goût.

C'est la meilleure façon de s'assurer que vos visiteurs ont une expérience cohérente en visitant votre site, et cela peut être réalisé de différentes manières.

Historiquement, en cas d'erreur de notre part, nous avions l'habitude de forcer le contenu à rester verrouillé et d'afficher un paywall demandant un abonnement. Vous pouvez désormais personnaliser ce comportement par défaut.

En supposant que vous savez déjà lu notre guide « comment créer un paywall basique », nous pouvons ajouter quelques lignes de configuration pour nous assurer que le comportement par défaut correspond à ce que nous voulons :

Ici, en définissant le default_widget sur le widget invisible, nous aurions pu déverrouiller le contenu automatiquement si jamais une erreur de réseau se produisait. Nous pouvons appliquer la même logique avec le widget gift, par exemple, si nous voulons toujours déverrouiller notre contenu premium mais que nous voulons demander à notre visiteur de le déverrouiller manuellement :

Vous pouvez appliquer la même logique pour tout autre widget, mais nous vous recommandons d'utiliser 'gift', 'unlock', 'invisible' ou 'subscription' pour éviter tout problème lié à une erreur de réseau.

De plus, vous pouvez configurer la durée maximale d'attente avant d'interrompre toute demande en cours et afficher un paywall par défaut :

Très utile, mais un peu limité si nous ne pouvons pas avoir accès à toutes les merveilleuses apparences que nous avons créées dans notre Dashboard, non ?

L'un des problèmes les plus fréquemment remontés à notre équipe Support depuis le début est probablement le suivant : « Pourquoi mon paywall est-il soudainement noir ? » La réponse est très simple : nous n'avons pas pu obtenir l'apparence personnalisée que vous avez créée sur votre Dashboard en raison d'une erreur de réseau, et comme c'est votre première visite, nous ne l'avons pas mise en cache.

Pour éviter ce problème, nous vous encourageons vivement à intégrer un certain nombre de styles et de messages personnalisés directement dans votre code :

Ainsi, vous serez certain qu'en cas d'erreur de réseau (ou autre), le paywall par défaut qui s'affichera aura le même design que le reste de votre site.

ℹ️ Si tout se passe bien au niveau du réseau et que vous n'avez défini aucune option en lecture seule, la configuration de votre Dashboard remplacera celle que vous avez définie dans le code. Cela garantit une meilleure expérience globale, sans qu'un paywall noir bizarre apparaisse sous votre page verte flashy 😅.

Si vous souhaitez aller plus loin et que vous voulez, par exemple, afficher un formulaire de newsletter Mailchimp au lieu d'un paywall en cas d'erreur, vous pouvez également utiliser l'événement onError et masquer le paywall généré par défaut pour afficher ce qui correspond à vos besoins.

Supposons que nous ayons un formulaire de newsletter (simplifié pour le bien de la personne qui écrit ce guide) sous notre contenu premium :

Le formulaire sera caché dans la page et attendra son moment pour briller. Tout ce qu'il vous reste à faire est de gérer l'événement onError :

Tout est maintenant correctement paramétré 🚀 et nous pouvons passer à notre prochain guide où nous verrons comment utiliser le compagnon d' Access.js, Audit.js, pour pouvoir utiliser une fonctionnalité unique appelée la segmentation native.