113 lines
3.8 KiB
Markdown
113 lines
3.8 KiB
Markdown
# Suppression des fallbacks dans l'application
|
|
|
|
**Date** : Décembre 2024
|
|
**Status** : ✅ Tous les fallbacks supprimés
|
|
|
|
## Fallbacks supprimés
|
|
|
|
### 1. `components/PaymentModal.tsx` - Fallback vers Lightning URI ✅ SUPPRIMÉ
|
|
**Lignes** : 71, 75, 81
|
|
|
|
**Description** : Si WebLN/Alby échoue, l'application ouvrait le Lightning URI dans le navigateur.
|
|
|
|
**Action** : ✅ Supprimé - Affiche maintenant une erreur à la place
|
|
|
|
**Modifications** :
|
|
- Suppression de tous les fallbacks vers `window.location.href = paymentUrl`
|
|
- Affichage d'une erreur si WebLN n'est pas disponible
|
|
- Affichage d'une erreur si le paiement échoue (sauf si l'utilisateur a annulé)
|
|
|
|
---
|
|
|
|
### 2. `lib/invoiceResolver.ts` - Fallback vers storage puis création ✅ SUPPRIMÉ
|
|
**Ligne** : 26-31
|
|
|
|
**Description** : Si l'invoice n'est pas dans les tags de l'événement, essayait le storage, puis créait une nouvelle invoice.
|
|
|
|
**Action** : ✅ Supprimé - Utilise uniquement l'invoice des tags de l'événement
|
|
|
|
**Modifications** :
|
|
- Suppression du fallback vers storage
|
|
- Suppression de la création automatique d'invoice
|
|
- Lève une erreur si l'article n'a pas d'invoice dans les tags
|
|
- L'invoice doit être créée par l'auteur lors de la publication
|
|
|
|
---
|
|
|
|
### 3. `lib/payment.ts` - Continue même si zap request échoue ✅ SUPPRIMÉ
|
|
**Ligne** : 39
|
|
|
|
**Description** : Si la création du zap request échouait, continuait quand même avec l'invoice.
|
|
|
|
**Action** : ✅ Supprimé - Le zap request est maintenant requis
|
|
|
|
**Modifications** :
|
|
- Suppression du try/catch qui ignorait l'erreur
|
|
- Le zap request doit maintenant réussir, sinon une erreur est levée
|
|
- Le paiement ne peut pas continuer sans zap request
|
|
|
|
---
|
|
|
|
### 4. `lib/articleInvoice.ts` - Continue sans invoice si création échoue ✅ SUPPRIMÉ
|
|
**Ligne** : 22-23
|
|
|
|
**Description** : Si la création d'invoice via Alby échouait, continuait sans invoice.
|
|
|
|
**Action** : ✅ Supprimé - La création d'invoice est maintenant requise
|
|
|
|
**Modifications** :
|
|
- Suppression du try/catch qui retournait `undefined`
|
|
- La fonction lève maintenant une erreur si la création échoue
|
|
- L'article ne peut pas être publié sans invoice
|
|
- `createArticleInvoice` retourne maintenant `Promise<AlbyInvoice>` au lieu de `Promise<AlbyInvoice | undefined>`
|
|
|
|
---
|
|
|
|
### 5. `lib/articleStorage.ts` - Commentaire obsolète ✅ CORRIGÉ
|
|
**Ligne** : 23
|
|
|
|
**Description** : Commentaire mentionnait encore localStorage (obsolète).
|
|
|
|
**Action** : ✅ Corrigé - Commentaire mis à jour
|
|
|
|
**Modifications** :
|
|
- Commentaire mis à jour pour refléter l'utilisation exclusive d'IndexedDB
|
|
|
|
---
|
|
|
|
### 6. `lib/nostrRemoteSigner.ts` - Commentaire fallback ✅ CORRIGÉ
|
|
**Ligne** : 35
|
|
|
|
**Description** : Commentaire mentionnait "This is a fallback that will throw an error".
|
|
|
|
**Action** : ✅ Corrigé - Commentaire mis à jour
|
|
|
|
**Modifications** :
|
|
- Commentaire mis à jour pour refléter que la clé privée est requise
|
|
- Message d'erreur amélioré
|
|
|
|
---
|
|
|
|
## Résumé des modifications
|
|
|
|
Tous les fallbacks ont été supprimés. L'application utilise maintenant une approche "fail-fast" :
|
|
|
|
1. ✅ **PaymentModal.tsx** : Affiche une erreur si WebLN échoue (pas de redirection)
|
|
2. ✅ **invoiceResolver.ts** : Utilise uniquement l'invoice des tags (erreur si absent)
|
|
3. ✅ **payment.ts** : Le zap request est requis (erreur si échec)
|
|
4. ✅ **articleInvoice.ts** : La création d'invoice est requise (erreur si échec)
|
|
5. ✅ **articleStorage.ts** : Commentaire corrigé
|
|
|
|
## Impact
|
|
|
|
### Comportement avant
|
|
- L'application essayait plusieurs alternatives en cas d'échec
|
|
- Continuait même si certaines opérations échouaient
|
|
- Fallback vers des méthodes alternatives
|
|
|
|
### Comportement après
|
|
- L'application échoue immédiatement si une opération requise échoue
|
|
- Pas de fallback, pas de continuation silencieuse
|
|
- Erreurs claires pour l'utilisateur
|
|
- Code plus prévisible et plus strict
|