Istruzioni avanzate per il debug
Revisione completa del sistema (audit della codebase)
- _“1. Separa le chiamate API dai componenti: Il componente _
ProjectListsta recuperando i dati direttamente. Suggerimento: sposta il fetch dei dati in un hook o in un context dedicato per mantenere i componenti come pura UI.*
- Riduci l’accoppiamento nella logica dei Task: Il toggle di completamento del task sta aggiornando sia lo stato sia scrivendo direttamente in localStorage. Dovrebbe essere effettuato un refactoring per avere una singola fonte di verità.
- Organizza le funzioni di utilità: Ci sono funzioni di utilità in
App.tsxche sarebbe meglio spostare in una cartellautils(ad esempio, le funzioni di formattazione delle date). - …”*
Rendi i tuoi prompt più dettagliati e specifici
Approccio sicuro per aggiornamenti delicati
Verifica dell’ottimizzazione delle prestazioni
- “Data fetching: Il componente
ProjectListrecupera i dati a ogni render. Questo potrebbe essere migliorato aggiungendo una cache o spostando il fetch in un contesto più alto, così da non ripeterlo inutilmente. Valuta di usare uno state o un context per memorizzare i progetti una volta recuperati. - Re-renders: Il componente
TaskItemnon è memoizzato e viene renderizzato di nuovo ogni volta che cambia qualunque stato del componente padre. Se abbiamo molte attività, questo può rallentare le interazioni. Suggerimento: usaReact.memoperTaskItemper evitare re-render inutili. - Assets: È stata rilevata un’immagine (logo) da 2MB. È piuttosto grande; comprimila oppure usa una risoluzione più piccola per un caricamento più rapido.
- Bundle size: Tutte le pagine sono in un unico bundle. Valuta il code splitting (
import()dinamico per i moduli di grandi dimensioni) in modo che il caricamento iniziale sia più veloce. - …”*
Gestire gli errori persistenti
- Chiedi all’AI cosa ha già provato. A volte, dopo alcuni tentativi di “Try to Fix” o istruzioni manuali, non è chiaro cosa sia stato modificato. Usa: _“Quali soluzioni abbiamo provato finora per questo errore?”_. L’AI può elencare i tentativi, aiutandoti a evitare di ripetere le stesse correzioni.
- Fai spiegare all’AI l’errore in termini semplici. “Spiega in termini semplici perché si verifica questo errore.” Questo può rivelare se l’AI (e tu) lo avete davvero compreso. Potresti individuare qui un fraintendimento.
- Valuta un approccio alternativo. Chiedi: _“Dato che questo errore continua a verificarsi, possiamo provare un approccio diverso per raggiungere l’obiettivo?”_. L’AI potrebbe suggerire una strategia di implementazione diversa che aggira l’area problematica.
- Ripristina e riprova. Nello scenario peggiore, potresti tornare indietro di alcuni passaggi. Lovable ti consente di ripristinare versioni precedenti e persino modificare i messaggi passati ed eseguire un revert per adottare un approccio diverso. Poi procedi con modifiche più piccole.
Esempi di flussi di debug
Il “blocco nel loop di errori”
1
Passi a Chat mode.
2
Chiedi: “Qual è la causa principale di questo errore di build?”
3
L'AI spiega che si tratta di un mismatch di tipi nella chiamata API.
4
Poi dici: “Mostrami il codice rilevante e i tipi attesi.”
5
L'AI mostra che la funzione si aspettava un ID numerico ma ha ricevuto un oggetto.
6
Ora che lo vedi, fornisci l'istruzione: “Modifica il codice per passare solo l'ID numerico alla funzione, non l'intero oggetto.”
7
Passi a Default, esegui quell'istruzione e la build va a buon fine.
8
Se non fosse andata a buon fine, torneresti indietro, magari chiedendo: “Cos'altro potrebbe causare questo?” ecc.
La “funzionalità che non funziona come dovrebbe”
1
Non viene mostrato alcun errore, quindi chiedi in Chat: “La notifica email non funziona – mi aspettavo un’email quando un’attività è in ritardo, ma non ho ricevuto nulla. Come possiamo fare debug?”
2
L’IA suggerisce di controllare se la funzione sul server è stata attivata e se la risposta del servizio email contiene un errore.
3
Recuperi il log del server (magari da Supabase) e vedi un errore di permessi.
4
Mostri questo all’IA: “Il log dice ‘permission denied when trying to send email.’”
5
L’IA deduce che forse la chiave API per il servizio email non è stata impostata o il servizio l’ha bloccata.
6
Quindi correggi la chiave API nelle impostazioni (al di fuori di Lovable) oppure fornisci un’istruzione per modificare la funzione in modo che usi un metodo diverso.
“L’elemento dell’interfaccia utente è scomparso.”
1
Dici all’AI: “La sezione con l’elenco dei progetti non viene più visualizzata. Funzionava prima dell’ultima modifica.”
2
L’AI potrebbe verificare se il componente viene ancora renderizzato o se manca un’istruzione return.
Magari si rende conto che il refactoring ha rimosso
ProjectList dal JSX del componente padre. Suggerisce di re-importarlo e includerlo di nuovo. Oppure potrebbe essere che le modifiche allo stato nel componente padre facciano sì che l’elenco venga ora filtrato involontariamente.3
L’AI potrebbe passare in rassegna le possibilità: “I dati vengono ancora recuperati? Il componente riceve i dati? Aggiungiamo un console.log nel render per vedere se riceve le props.”
4
Lo fai tu (oppure lo fa l’AI tramite istruzione) e non vedi alcun log, il che significa che il componente non è montato.
Aha\\! Allora dai un’istruzione: _“Ripristina _
<ProjectList>nel JSX della pagina Dashboard (è stato rimosso per errore).” Problema risolto.Usare gli Strumenti di sviluppo e i registri della console
Analisi delle cause alla radice, rollback e miglioramento progressivo
Causa principale vs. sintomo
Vedo che hai corretto l’errore di null pointer aggiungendo un controllo, ma perché era null in primo luogo? Possiamo intervenire su quella causa?
Esegui il rollback con criterio:
Ho ripristinato il Progetto a prima della funzionalità di notifiche. Implementiamola di nuovo, ma con più attenzione questa volta.
Miglioramento progressivo:
- Aggiungi i casi di test che falliscono.
- Isola il problema e analizza le dipendenze.
- Documenta le conclusioni prima di applicare le correzioni.
Documenta man mano che procedi:
Riassumi qual era il problema e come lo abbiamo risolto.
README o in un log. Questo è ottimo per il te stesso del futuro, o per chiunque altro stia lavorando sul Progetto, per capire cosa è successo.
Sapere quando chiedere aiuto umano:
Guida alla risoluzione dei problemi della community
Correzione degli errori
Correzione degli errori
Quando correggi gli errori, concentrati esclusivamente sulle sezioni di codice rilevanti, senza modificare le parti funzionanti non correlate. Analizza il messaggio di errore e risali alla sua origine. Applica correzioni mirate che risolvano il problema specifico, mantenendo la compatibilità con la codebase esistente. Prima di confermare qualsiasi soluzione, verifica che risolva il problema originale senza introdurre nuovi bug. Preserva sempre la funzionalità esistente ed evita di riscrivere codice non direttamente correlato all’errore.
Approccio alla modifica del codice
Approccio alla modifica del codice
Quando modifichi codice esistente, adotta un approccio chirurgico che cambi solo ciò che è necessario per implementare la funzionalità richiesta o la correzione. Mantieni i nomi delle variabili, i pattern di codice e le decisioni architetturali presenti nella codebase. Prima di suggerire modifiche, analizza le dipendenze per assicurarti che le modifiche non compromettano la funzionalità esistente. Presenta le modifiche come diff minimi anziché riscritture complete. Quando individui miglioramenti che vanno oltre l’attività immediata, limitati a suggerirli separatamente senza implementarli automaticamente.
Integrazione del database
Integrazione del database
Prima di suggerire nuove strutture del database, esamina attentamente lo schema esistente per identificare tabelle, relazioni e campi già presenti. Sfrutta le tabelle esistenti ogni volta che è possibile invece di duplicare i modelli di dati. Quando sono necessarie modifiche al database, assicurati che siano compatibili con le query esistenti e con le modalità di accesso ai dati in uso. Considera strategie di migrazione per le modifiche allo schema che preservino i dati esistenti. Verifica sempre le relazioni di chiave esterna e i vincoli di integrità dei dati prima di proporre modifiche.
Analisi dettagliata dei problemi
Analisi dettagliata dei problemi
Affronta ogni problema con un processo diagnostico esaustivo. Inizia raccogliendo tutte le informazioni rilevanti tramite un esame accurato dei messaggi di errore, dei registri e del comportamento del sistema. Formula diverse ipotesi sulle possibili cause invece di trarre subito conclusioni affrettate. Verifica ogni ipotesi in modo metodico finché non identifichi la causa radice. Documenta il processo di analisi e i risultati prima di proporre soluzioni. Considera i possibili casi limite e come potrebbero influenzare il sistema.
Verifica della soluzione
Verifica della soluzione
Prima di confermare qualsiasi soluzione, implementa un rigoroso processo di verifica. Testa la soluzione sul problema originale per confermare che lo risolva. Controlla che non ci siano effetti collaterali indesiderati nelle funzionalità correlate. Assicurati che le prestazioni non siano compromesse. Verifica la compatibilità con diversi ambienti e configurazioni. Verifica i casi limite per garantirne la robustezza. Solo dopo aver completato questa verifica dovresti presentare la soluzione come confermata.
Coerenza del codice
Coerenza del codice
Mantieni la coerenza con la codebase esistente in termini di stile, pattern e approcci. Analizza il codice per identificare le convenzioni di denominazione, le preferenze di formattazione e i pattern architetturali. Segui questi pattern consolidati quando implementi nuove funzionalità o correzioni. Usa le stesse strategie di gestione degli errori, gli stessi approcci di logging e le stesse metodologie di testing presenti nel progetto. In questo modo preservi leggibilità e manutenibilità, riducendo al contempo il carico cognitivo per gli sviluppatori.
Miglioramento progressivo
Miglioramento progressivo
Quando aggiungi nuove funzionalità, basati sull’architettura esistente invece di introdurre paradigmi completamente nuovi. Identifica i punti di estensione nel design attuale e sfruttali per le nuove funzionalità. Implementa modifiche in linea con i pattern e i principi consolidati della codebase. Concentrati sulla retrocompatibilità per assicurare che le funzionalità esistenti continuino a funzionare come previsto. Documenta come le nuove aggiunte si integrano e ampliano il sistema esistente.
Documentazione e spiegazioni
Documentazione e spiegazioni
Fornisci spiegazioni chiare e concise per tutte le modifiche e le raccomandazioni. Spiega non solo quali modifiche vengono apportate, ma anche perché sono necessarie e come funzionano. Documenta tutte le ipotesi e le dipendenze rilevanti per la soluzione. Includi commenti nel codice quando introduci logica complessa o soluzioni non ovvie. Quando suggerisci modifiche architetturali, fornisci diagrammi o spiegazioni di alto livello che aiutino a visualizzarne l’impatto.
Consapevolezza del debito tecnico
Consapevolezza del debito tecnico
Riconosci quando le soluzioni potrebbero introdurre debito tecnico e sii trasparente rispetto a questi compromessi. Quando i vincoli di tempo rendono necessarie soluzioni non ideali, identifica chiaramente quali aspetti trarrebbero beneficio da un refactoring futuro. Distingui tra correzioni rapide e soluzioni adeguate, raccomandando l’approccio più appropriato in base al contesto. Quando il debito tecnico è inevitabile, documentalo in modo chiaro per facilitare i miglioramenti futuri.
Apprendimento e adattamento
Apprendimento e adattamento
Adattati continuamente ai pattern e alle preferenze specifiche del Progetto. Presta attenzione al feedback sui suggerimenti precedenti e integra queste lezioni nelle raccomandazioni future. Costruisci un modello mentale dell’architettura dell’applicazione che diventi sempre più accurato nel tempo. Ricorda i problemi e le soluzioni passate per evitare di ripetere gli stessi errori. Cerca attivamente di comprendere i requisiti di business alla base delle decisioni tecniche.
Prevenire la duplicazione dei componenti
Prevenire la duplicazione dei componenti
Prima di creare nuove pagine, componenti o flussi, esegui un inventario approfondito degli elementi esistenti nel codice. Cerca funzionalità simili usando parole chiave e pattern di file pertinenti. Identifica le opportunità per riutilizzare o estendere componenti esistenti invece di crearne di nuovi e duplicati. Quando esistono funzionalità simili, analizzale per capire se possono essere parametrizzate o adattate invece di duplicate. Mantieni un modello mentale della struttura dell’applicazione per riconoscere quando le soluzioni proposte potrebbero creare elementi ridondanti. Quando sono necessarie pagine o flussi simili, valuta la creazione di componenti astratti riutilizzabili che possano essere usati con dati o configurazioni diversi, promuovendo i principi DRY (Don’t Repeat Yourself).
Eliminazione del codice morto
Eliminazione del codice morto
Identifica e rimuovi attivamente il codice inutilizzato invece di lasciarlo accumulare. Quando sostituisci una funzionalità, rimuovi in modo pulito la vecchia implementazione invece di limitarti a commentarla o a lasciarla affiancata al nuovo codice. Prima di eliminare il codice, verifica il suo utilizzo in tutta l’applicazione controllando import e riferimenti. Usa strumenti come l’analisi delle dipendenze, quando disponibili, per confermare che il codice sia davvero inutilizzato. Durante il refactoring, tieni traccia dei metodi deprecati e assicurati che vengano rimossi correttamente una volta che non sono più referenziati. Analizza regolarmente la base di codice alla ricerca di componenti orfani, import inutilizzati, blocchi commentati e condizioni non raggiungibili. Quando suggerisci la rimozione di codice, fornisci una motivazione chiara sul perché è considerato codice morto e verifica che non esistano dipendenze non evidenti prima di eliminarlo. Mantieni pulita la base di codice dando priorità all’eliminazione dei percorsi di codice che non vengono più eseguiti.
Mantenere le funzionalità esistenti
Mantenere le funzionalità esistenti
Tratta le funzionalità già funzionanti come sistemi bloccati che richiedono un’autorizzazione esplicita per essere modificati. Prima di suggerire modifiche a qualsiasi componente funzionante, identifica chiaramente i suoi confini e le sue dipendenze. Non rimuovere né modificare in modo sostanziale funzionalità attualmente operative senza indicazioni esplicite. Quando si verificano errori in un’area, evita di apportare modifiche “per sicurezza” a componenti funzionanti non correlati al problema. Mantieni una chiara comprensione di quali parti dell’applicazione sono stabili e quali sono in fase di sviluppo. Usa un approccio incentrato sulle funzionalità, in cui le modifiche sono isolate a set di funzionalità specifici senza propagarsi alle altre. Quando modifichi componenti condivisi utilizzati da più funzionalità, assicurati che tutte le funzionalità dipendenti continuino a funzionare come previsto. Crea meccanismi di sicurezza documentando accuratamente le dipendenze tra funzionalità prima di apportare modifiche che potrebbero influenzarle. Conferma sempre esplicitamente le intenzioni prima di suggerire modifiche a parti dell’applicazione consolidate e funzionanti.
Approccio di problem solving approfondito
Approccio di problem solving approfondito
Quando ti imbatti in errori complessi, resisti alla tentazione di applicare correzioni immediate senza una comprensione più approfondita. Fai consapevolmente un passo indietro per esaminare il problema da più prospettive prima di proporre soluzioni. Prendi in considerazione approcci radicalmente diversi invece di piccole variazioni della stessa strategia. Documenta almeno tre possibili soluzioni con i relativi pro e contro prima di raccomandare un approccio specifico. Metti in discussione le ipotesi iniziali sulla causa degli errori, soprattutto quando le correzioni standard non funzionano. Considera fonti di problemi non convenzionali, come configurazioni dell’ambiente di esecuzione, dipendenze esterne o race condition che potrebbero non essere immediatamente evidenti. Prova a ribaltare il tuo modo di pensare: invece di chiederti “perché questo non funziona?”, chiediti “a quali condizioni questo comportamento avrebbe effettivamente senso?”. Scomponi i problemi complessi in componenti più piccoli che possano essere verificate in modo indipendente. Implementa strategie di debug mirate, come logging, breakpoint o tracciamento dello stato, per raccogliere più informazioni quando l’origine di un errore non è chiara. Sii disposto a proporre correzioni sperimentali come opportunità di apprendimento, più che come soluzioni definitive, quando affronti problemi particolarmente oscuri o sfuggenti.
Verifica delle query del database
Verifica delle query del database
Prima di suggerire qualsiasi query al database o modifica allo schema, verifica sempre prima lo stato attuale del database. Esamina tabelle, campi e relazioni esistenti per assicurarti di non raccomandare la creazione di elementi già presenti. Quando suggerisci query, controlla innanzitutto se nella base di codice esistono query simili che possono essere adattate. Esamina i modelli di dati esistenti, i file di migrazione e le definizioni di schema per costruirti una comprensione accurata della struttura del database. Per qualsiasi proposta di creazione di tabelle, conferma esplicitamente che la tabella non esiste già e spiega perché è necessaria una nuova tabella invece di modificare una tabella esistente. Quando suggerisci l’aggiunta di campi, verifica che campi simili non stiano già svolgendo la stessa funzione con nomi diversi. Considera le implicazioni sulle prestazioni del database delle query suggerite e fornisci alternative ottimizzate quando opportuno. Contestualizza sempre i suggerimenti di query all’interno dell’architettura del database esistente, invece di trattarli come operazioni isolate.
Coerenza dell'interfaccia utente e dei temi
Coerenza dell'interfaccia utente e dei temi
Mantieni un rispetto rigoroso per il design system e la palette di colori stabiliti in tutta l’applicazione. Prima di creare nuovi componenti UI, studia quelli esistenti per comprendere il linguaggio visivo, i pattern di spaziatura, i modelli di interazione e l’approccio al theming. Quando implementi nuove interfacce, riutilizza i pattern dei componenti esistenti invece di creare varianti visive. Estrai i valori di colore, tipografia, spaziatura e gli altri design token dalla codebase esistente invece di introdurre nuovi valori. Assicurati di gestire in modo coerente gli stati (hover, attivo, disabilitato, errore, ecc.) in tutti i componenti. Rispetta i pattern di comportamento responsive stabiliti quando implementi nuovi layout. Quando suggerisci miglioramenti alla UI, assicurati che migliorino, anziché compromettere, la coesione visiva dell’applicazione. Mantieni gli standard di accessibilità in modo coerente in tutti i componenti, inclusi i rapporti di contrasto dei colori, la navigazione da tastiera e il supporto per gli screen reader. Documenta tutte le varianti dei componenti e i relativi contesti di utilizzo appropriati per facilitare un’applicazione coerente. Quando introduci nuovi elementi visivi, mostra esplicitamente come si integrano e completano il design system esistente invece di rimanere separati da esso.
Approccio sistematico al debugging
Approccio sistematico al debugging
Quando riscontri degli errori, adotta una metodologia di debug scientifica invece di apportare modifiche casuali. Inizia riproducendo esattamente il problema in un ambiente controllato. Raccogli dati completi, inclusi registri della console, richieste di rete, stato dei componenti e messaggi di errore. Formula diverse ipotesi sulle possibili cause e mettile alla prova in modo sistematico. Isola il problema restringendo i componenti interessati e identificando le condizioni che lo determinano. Documenta il tuo processo di debug e le tue scoperte per riferimento futuro. Usa strumenti di debug appropriati, inclusi gli strumenti per sviluppatori del browser, React DevTools e tecniche di debug a livello di codice. Verifica sempre che la tua soluzione risolva completamente il problema senza introdurre nuove criticità o regressioni in altre parti dell’applicazione.
Type safety e validazione dei dati
Type safety e validazione dei dati
Prima di implementare qualsiasi funzionalità, analizza attentamente le definizioni di tipo sia dallo schema del database che dalle interfacce TypeScript. Mantieni un controllo dei tipi rigoroso in tutta la base di codice, evitando il tipo ‘any’ come scappatoia. Quando lavori con trasformazioni dei dati, verifica la sicurezza dei tipi a ogni passaggio della pipeline. Presta particolare attenzione alle incongruenze di tipo più comuni, come numeri dal database che arrivano come stringhe, requisiti di parsing delle date e gestione dei campi nullable. Implementa convenzioni di naming coerenti tra le colonne del database e le interfacce TypeScript. Documenta le relazioni complesse tra tipi e gli eventuali requisiti di gestione speciale. Esegui test con strutture di dati reali e verifica i casi limite, in particolare la gestione di null/undefined. Quando si verificano errori, traccia la pipeline di trasformazione dei dati per identificare esattamente dove i tipi divergono e suggerisci correzioni che mantengano la sicurezza dei tipi.
Gestione del flusso di dati
Gestione del flusso di dati
Concettualizza il flusso di dati come una pipeline completa dal database, attraverso l’API e lo stato, fino alla UI. Quando implementi nuove funzionalità, tieni traccia con attenzione di come i dati vengono trasformati in ogni fase. Implementa pattern corretti di invalidazione delle query per garantire che la UI rimanga sincronizzata con lo stato del database. Aggiungi log in console in punti critici per monitorare le transizioni dei dati. Crea modelli mentali chiari su quando e come i dati dovrebbero aggiornarsi in risposta alle azioni. Presta molta attenzione alle strategie di caching e ai potenziali problemi di dati obsoleti. Quando esegui il debug di problemi di flusso, segui in modo metodico il percorso dei dati dalla sorgente alla destinazione. Controlla problemi di timing, race condition ed errori di trasformazione. Verifica che la struttura finale dei dati che raggiunge i componenti corrisponda a ciò che si aspettano. Implementa robuste error boundary e una gestione efficace degli stati di caricamento per mantenere la stabilità della UI durante le interruzioni del flusso di dati.
Ottimizzazione delle prestazioni
Ottimizzazione delle prestazioni
Monitora in modo proattivo le prestazioni dell’applicazione invece di aspettare che i problemi diventino gravi. Rivedi le strategie di caching delle query per ridurre al minimo le chiamate al database non necessarie. Verifica ed elimina i re-render dei componenti non necessari tramite una corretta memoization e una gestione accurata delle dipendenze. Analizza i pattern di data fetching per individuare potenziali problemi di query N+1, waterfall eccessive o richieste ridondanti. Implementa la virtualizzazione per liste lunghe e applica la paginazione a dataset di grandi dimensioni. Ottimizza la dimensione del bundle tramite code splitting e lazy loading. Comprimi e ottimizza gli asset, incluse le immagini. Usa strumenti adeguati per la misurazione delle prestazioni per identificare i colli di bottiglia, tra cui React DevTools, la scheda Performance, il pannello Network e il Memory profiler. Concentrati sulle ottimizzazioni che impattano direttamente l’esperienza utente, come i tempi di caricamento, il time to interactive e la reattività della UI. Implementa interventi mirati di miglioramento delle prestazioni invece di ricorrere a ottimizzazioni premature.
Gestione degli errori e resilienza
Gestione degli errori e resilienza
Implementa una strategia completa di gestione degli errori che mantenga la stabilità dell’applicazione fornendo al tempo stesso un feedback significativo. Usa in modo strategico i blocchi try/catch attorno alle sezioni di codice potenzialmente problematiche. Crea una gerarchia di error boundary per contenere i malfunzionamenti all’interno di componenti specifici invece di mandare in crash l’intera applicazione. Progetta pattern di degrado graduale in cui i componenti possano continuare a funzionare con dati limitati. Fornisci messaggi di errore chiari e intuitivi per l’utente che spieghino il problema senza usare gergo tecnico. Implementa meccanismi di ripristino, inclusa la logica di retry, i fallback e i reset di stato. Mantieni un sistema robusto di logging degli errori che catturi un contesto sufficiente per il debugging rispettando al contempo la privacy. Testa in modo approfondito gli scenari di errore per assicurarti che i meccanismi di ripristino funzionino come previsto. Quando suggerisci soluzioni, assicurati che affrontino la causa principale invece di limitarsi a sopprimere i sintomi e verifica che funzionino in tutti gli ambienti e casi limite rilevanti.
Architettura dei componenti
Architettura dei componenti
Progetta i componenti con una chiara comprensione della loro gerarchia e delle rispettive responsabilità. Immagina i componenti come un albero genealogico con corrette relazioni genitore-figlio. Riduci al minimo il prop drilling usando in modo strategico il contesto o la gestione dello stato dove appropriato. Definisci confini chiari tra componenti container (smart) e presentational (dumb). Stabilisci pattern coerenti per la comunicazione tra componenti, incluse le interazioni genitore-figlio e tra componenti fratelli. Quando effettui il debug di problemi sui componenti, analizza l’intero albero dei componenti, il flusso delle prop, la posizione dello stato e le connessioni dei gestori di eventi. Progetta i componenti con una singola responsabilità e interfacce chiare. Documenta le relazioni e le dipendenze tra componenti per facilitare la manutenzione futura. Implementa ottimizzazioni delle prestazioni, incluse memoization, lazy loading e code splitting, quando risultano vantaggiose. Mantieni un equilibrio tra riusabilità e specializzazione dei componenti per evitare sia la duplicazione sia un’eccessiva astrazione.
Integrazione API e gestione della rete
Integrazione API e gestione della rete
Affronta l’integrazione con le API con una strategia completa per richieste, risposte e gestione degli errori. Verifica gli header di autenticazione, i parametri e il formato del body per ogni richiesta. Implementa una gestione degli errori adeguata per tutte le operazioni di rete, con gestione specifica per i diversi tipi di errore. Assicurati di avere una tipizzazione coerente tra i payload delle richieste, le risposte attese e lo stato dell’applicazione. Configura correttamente le impostazioni CORS e verifica che funzionino in tutti gli ambienti. Implementa meccanismi di retry intelligenti per i guasti temporanei con backoff esponenziale. Considera le implicazioni del rate limiting e implementa un throttling appropriato. Aggiungi un caching strategico delle richieste per migliorare le prestazioni e ridurre il carico sul server. Monitora le prestazioni di rete, inclusi i tempi delle richieste e le dimensioni dei payload. Testa le integrazioni API sia sui casi di successo (happy path) sia su vari scenari di errore. Mantieni una documentazione chiara di tutti gli endpoint API, dei loro scopi, dei parametri attesi e dei formati di risposta per facilitare lo sviluppo futuro e il debugging.