mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 13:31:43 +02:00
Integrate Next.js runtime-only backend pattern
This commit is contained in:
@@ -174,32 +174,6 @@ Lors d'une implémentation, valider que chaque champ mentionné dans les tâches
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : 10_backend_patterns_valides.md
|
||||
|
||||
Pourquoi :
|
||||
Le module sendPasswordResetEmail utilise `server-only` ce qui le rend non-importable dans le runner de tests Node. Résolution : tester la logique pure (safeHttpUrl) dans un fichier séparé sans dépendances Next.js.
|
||||
|
||||
Proposition :
|
||||
**Pattern : Isolation des guards purs des modules server-only**
|
||||
Extraire la logique pure (validation URL, sanitisation) dans des fonctions utilitaires sans import `server-only` ou `nodemailer`. Le module email orchestre uniquement. Cela permet de tester les guards en isolation sans les contraintes du runtime Next.js.
|
||||
|
||||
---
|
||||
2026-03-16 — app-template-resto
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : 10_backend_patterns_valides.md
|
||||
|
||||
Pourquoi :
|
||||
Pattern validé sur story 1.10 — la règle `server-only` vs testabilité est implicite dans le projet mais mérite d'être explicitée pour les agents futurs.
|
||||
|
||||
Proposition :
|
||||
**Pattern : `server-only` réservé aux modules avec APIs Next.js exclusivement serveur**
|
||||
Ne pas mettre `import "server-only"` sur les modules de logique pure injectés via dépendances (ex: `deleteSession({ prisma, sessionToken })`). Réserver `server-only` aux modules qui appellent des APIs Next.js runtime-only (`cookies()`, `headers()`, `redirect()`). Les modules purs sans ces imports peuvent être importés par le test runner Node et testés unitairement sans friction.
|
||||
|
||||
---
|
||||
2026-03-16 — app-template-resto
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : 10_backend_patterns_valides.md
|
||||
|
||||
Pourquoi :
|
||||
Pattern validé sur story 1.10 — suppression de session avec gestion idempotente, réutilisable pour toute opération de révocation.
|
||||
|
||||
@@ -208,31 +182,26 @@ Proposition :
|
||||
Lors d'une déconnexion ou révocation de session, entourer le `prisma.session.delete()` d'un try/catch qui absorbe silencieusement le code Prisma `P2025` (record not found). Une session peut déjà avoir été supprimée (expiration, logout concurrent) — ce n'est pas une erreur, ne pas la propager.
|
||||
|
||||
---
|
||||
2026-03-16 — app-template-resto
|
||||
2026-03-19 — app-template-restau
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : 10_backend_patterns_valides.md
|
||||
Fichier cible : 10_frontend_patterns_valides.md
|
||||
|
||||
Pourquoi :
|
||||
Pattern validé sur story 1.10 — Server Action Next.js qui orchestre des dépendances Next.js runtime non-testables : isoler la logique pure dans un module injectable.
|
||||
Sur les fonctionnalités publiques reposant sur un service tiers en mode link-out (ex: réservation), un parcours canonique unique évite les ambiguïtés UX et centralise mieux les garde-fous, le wording et les fallbacks.
|
||||
|
||||
Proposition :
|
||||
**Pattern : Server Action Next.js — isoler la logique pure dans un module injectable**
|
||||
Une Server Action qui appelle `cookies()`, `headers()` ou `redirect()` ne peut pas être testée unitairement (imports runtime-only). Pattern : extraire la logique pure (suppression DB, validation) dans une fonction avec injection de dépendances (`performSignOut({ prismaClient, sessionToken, redirectFn })`). La Server Action reste fine et orchestre uniquement les dépendances Next.js. Le module extrait est testable sans friction avec le runner Node natif.
|
||||
### Intégration tierce en mode link-out : préférer une page locale canonique
|
||||
|
||||
---
|
||||
2026-03-16 — app-template-resto / code-review story 1.11
|
||||
Quand une fonctionnalité publique dépend d’un service tiers accessible via lien externe, préférer le parcours :
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : 10_backend_risques_et_vigilance.md
|
||||
- CTA internes (home, navigation, landing) → page locale du site
|
||||
- page locale dédiée → service tiers externe
|
||||
|
||||
Pourquoi :
|
||||
`import "server-only"` dans les repositories casse les tests Node.js hors Next.js — rencontré lors de cette review.
|
||||
Éviter de mélanger plusieurs parcours concurrents (ex: home qui sort directement vers le tiers alors qu’une page `/reservation` dédiée existe déjà).
|
||||
|
||||
Proposition :
|
||||
## Risque : `server-only` dans les repositories bloque les tests unitaires
|
||||
|
||||
`import "server-only"` empêche l'exécution des fichiers hors runtime Next.js.
|
||||
Solution : créer un stub `node_modules/server-only/index.js` (no-op) pour les tests.
|
||||
Alternativement, ne mettre `server-only` que dans les fichiers qui utilisent des APIs
|
||||
Next.js (`cookies()`, `headers()`), pas dans les repositories purs.
|
||||
Bénéfices :
|
||||
- UX plus cohérente
|
||||
- garde-fous centralisés au même endroit
|
||||
- fallbacks plus simples à gérer
|
||||
- évolution facilitée vers une variante embed / click-to-load
|
||||
|
||||
Reference in New Issue
Block a user