Scrivere gli stati prima di disegnare l’animazione
È un flusso proposto per un’app escursionistica dello sviluppatore, non una registrazione del comportamento osservato dell’API. La persona inserisce offline maps, richiede discussioni storiche e aspetta. L’app deve distinguere un modulo ancora intatto, una richiesta non risolta, record restituiti, una risposta vuota riuscita e un fallimento. Un unico pannello vuoto non comunica situazioni così diverse.
Inizia con una schermata neutra che spieghi cosa verrà cercato. Digitare non deve necessariamente inviare richieste. Quando l’invio è esplicito, salva la domanda insieme alla richiesta e mostra l’etichetta di caricamento. Mantieni leggibile l’input e impedisci che tocchi ripetuti inviino più volte la stessa azione. L’animazione segnala attesa, non un progresso dimostrato nell’archivio.
Tenere la risposta tardiva legata alla sua domanda
Immagina che la persona cambi l’input in regioni scaricate mentre la richiesta sulle mappe offline è ancora in corso. È un’interazione illustrativa, non un esempio di ricerca recuperato. La tua app deve decidere se attendere, avviare un’altra richiesta o permettere di chiudere la vista. Qualunque scelta tu implementi, la risposta precedente non deve diventare silenziosamente la risposta alla nuova frase.
Associa ogni richiesta all’input inviato nello stato della tua applicazione. All’arrivo, verifica se la risposta appartenga ancora alla vista corrente. Scartare una risposta tardiva dalla schermata non equivale ad annullare il lavoro del server: una richiesta già inviata può terminare con successo ed essere addebitata. Verifica questa distinzione nella tua implementazione.
Trattare il vuoto riuscito come risultato
Per i record restituiti mostra i campi effettivamente disponibili e mantieni l’etichetta di fonte storica. Per un array data vuoto, usa un messaggio separato che spieghi che quella richiesta non ha restituito record. Consenti di modificare frase o filtri conservandoli, così il lettore può scegliere consapevolmente. Non sostituire il vuoto con post popolari inventati.
I recuperi vuoti riusciti costano un credito, come le risposte riuscite con record. È un motivo per rendere intenzionali i cambi di query, non per nascondere i risultati vuoti come errori. Evita messaggi secondo cui non esistono discussioni pertinenti da nessuna parte: l’archivio è incompleto e la risposta dipende da una query specifica e da una finestra limitata.
Affidare il problema tecnico al gestore
Una risposta 400 richiede un controllo dell’input. Se l’app ha fornito una data non valida o un parametro non supportato, non incolpare l’escursionista per un errore del contratto del backend. 401 indica una chiave del servizio assente o non valida: ricaricare l’app o far accedere la persona non ripara necessariamente quella credenziale.
402 indica crediti insufficienti nell’account del servizio. Affida la decisione al gestore invece di mostrare una fattura all’escursionista. 429 richiede di rispettare Retry-After e ridurre le richieste ripetute. L’app può condividere un account tra più lettori: evita di dire automaticamente a una persona che ha causato il limite.
Separare un fallimento noto da un esito sconosciuto
Il gateway restituisce 502 quando il recupero a monte fallisce. Il credito riservato viene liberato o indicato come in attesa di riconciliazione. Conserva query ed eventuale pagina già visibile, poi offri una scelta limitata di riprovare. Tentativi automatici ripetuti possono creare altre richieste senza aiutare il lettore a capire cosa sia accaduto.
Se l’app non riceve mai una risposta, potrebbe non sapere se il server abbia fallito o concluso. Registra l’incertezza per la riconciliazione, senza dichiarare un rimborso o successo certo. La rotta pubblica /v1/status è un controllo statico di perimetro e risposta HTTP: non risolve questo dubbio e non certifica la salute della ricerca nell’archivio.
Rivedere le transizioni, non solo le schermate
Ripercorri la sequenza proposta con chi gestisce l’app: invio, modifica durante l’attesa, risposta vuota, nuovo tentativo dopo il fallimento, altra pagina e uscita dalla schermata. Per ogni passaggio indica input conservato, contenuto visibile e azione seguente. Un’immagine ben disegnata non dimostra che le transizioni funzionino.
Tieni diagnostica del gestore, risposte grezze e credenziali lontane dai messaggi pubblici. Dai all’escursionista il contesto per continuare a preparare la gita senza dipendere da una funzione di discussione indisponibile. Torna a /it/#field-notes per le decisioni su budget e Mostra altro che modellano questo flusso.
