# 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