mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 13:31:43 +02:00
fix(leadtech): résoudre les chemins Lead_tech selon la machine
- aliases.sh : détection par uname au lieu de tester l'existence du dossier
- _AI_INSTRUCTIONS.md : placeholder {{LEADTECH}} pour tous les chemins
- sync-ai-instructions.sh : substitution {{LEADTECH}} → REPO_ROOT à la génération
- .gitignore : exclure CLAUDE.md et AGENTS.md (fichiers générés, machine-spécifiques)
This commit is contained in:
@@ -133,6 +133,66 @@ Proposition :
|
||||
|
||||
---
|
||||
|
||||
2026-03-27 — app-alexandrie
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : knowledge/frontend/risques/react-native.md
|
||||
|
||||
Pourquoi :
|
||||
Anti-pattern récurrent dans les stores Zustand mobile : le catch d'une erreur throwée depuis `apiRequest` (qui throw un objet JSON, pas une Error) ne donne pas de message lisible si on fait `err instanceof Error` uniquement. Détecté lors de la review 5.2.
|
||||
|
||||
Proposition :
|
||||
|
||||
## Catch Zustand store — objet throwé vs Error
|
||||
|
||||
Quand `apiRequest` propage une erreur HTTP en throwant le JSON brut `{ error: { code, message } }`, le catch Zustand ne peut pas se limiter à `err instanceof Error`. Le pattern robuste :
|
||||
|
||||
```typescript
|
||||
catch (err: unknown) {
|
||||
let message = 'Erreur de connexion au serveur.';
|
||||
if (err instanceof Error) {
|
||||
message = err.message;
|
||||
} else if (
|
||||
typeof err === 'object' && err !== null &&
|
||||
'error' in err &&
|
||||
typeof (err as { error: { message?: string } }).error?.message === 'string'
|
||||
) {
|
||||
message = (err as { error: { message: string } }).error.message;
|
||||
}
|
||||
set({ error: message, isLoading: false });
|
||||
}
|
||||
```
|
||||
|
||||
Appliquer ce pattern dans tous les stores qui appellent `apiRequest` directement.
|
||||
|
||||
---
|
||||
|
||||
2026-03-27 — app-alexandrie
|
||||
|
||||
FILE_UPDATE_PROPOSAL
|
||||
Fichier cible : knowledge/frontend/risques/react-native.md
|
||||
|
||||
Pourquoi :
|
||||
`apiRequest` (http-client.ts) ne vérifiait pas `response.ok` — retournait le JSON brut même sur 404/500. Erreur non throwée → `res.error` dépendait du format de l'API NestJS. En cas de réponse non-JSON (proxy 502 HTML), `response.json()` throwait une SyntaxError cryptique. Détecté review 5.2.
|
||||
|
||||
Proposition :
|
||||
|
||||
## `fetch` sans vérification `response.ok` — toujours throw sur non-2xx
|
||||
|
||||
Après tout `fetch()`, toujours vérifier `response.ok` avant de retourner le JSON :
|
||||
|
||||
```typescript
|
||||
const json = (await response.json()) as T;
|
||||
if (!response.ok) {
|
||||
throw json; // throw le body d'erreur structuré
|
||||
}
|
||||
return json;
|
||||
```
|
||||
|
||||
Sans ce check, les erreurs 404/500 passent silencieusement si le service appelant ne vérifie que le body. Risque accru avec les proxies qui retournent du HTML sur erreur.
|
||||
|
||||
---
|
||||
|
||||
# Format attendu
|
||||
|
||||
Chaque proposition doit suivre ce format :
|
||||
|
||||
Reference in New Issue
Block a user