Quanto è sicuro nascosto AJAX richiede prestazioni false?

Non è tanto la prestazione "finta" quanto la reattività reale. Ci sono una serie di motivi per cui è popolare:

• Le connessioni Internet sono abbastanza affidabili al giorno d'oggi. Il rischio che una richiesta AJAX fallisca è molto bassa.
• Le operazioni eseguite non sono davvero critiche per la sicurezza. Se le tue e-mail non vengono cancellate sul server, la cosa peggiore che si verifica è che devi cancellarle di nuovo la prossima volta che verrai sulla pagina.
• Puoi progettare la tua pagina per annullare l'azione se la richiesta non riesce, ma in realtà non devi essere così sottile perché significa che la tua connessione al server è interrotta. È più facile dire "Connessione persa, impossibile salvare le modifiche recenti. Riprova più tardi."
• Puoi progettare la tua pagina per consentire solo una richiesta AJAX in sospeso, quindi il tuo stato non sarà troppo fuori sincrono dal server.
• Il browser ti avvisa se tenti di chiudere o navigare lontano da una pagina mentre una richiesta AJAX è in sospeso.

Supponendo che qualcosa funzioni e visualizzi un errore nel caso in cui fallisca sul lato remoto è molto più user-friendly che bloccare l'utente dal fare qualsiasi altra cosa finché non ci sarà una risposta dal server.

Un client email è in realtà un ottimo esempio per questo: quando ho una lista con 5 e-mail e quella superiore è selezionata, mi aspetto che quando si preme DEL tre volte le prime tre e-mail vengono cancellate. Con "non bloccante AJAX" questo funziona bene - ogni volta che prendo la chiave l'e-mail selezionata viene rimossa immediatamente. Se qualcosa va storto viene mostrato un errore e le e-mail non cancellate correttamente vengono visualizzate di nuovo OPPURE la pagina viene ricaricata per eliminare lo stato locale incoerente.

Quindi nel caso più comune - che è successo - migliora l'usabilità. Nel caso raro - errore - l'usabilità è degradata (l'elemento eliminato viene visualizzato di nuovo o l'applicazione è "riavviata") ma durante la creazione di un'applicazione si desidera avere la migliore usabilità per i casi comuni, non in caso di errori.

Gli utenti non si preoccupano di cosa sta facendo il software dietro le quinte: vogliono che le loro azioni abbiano un impatto visibile e siano in grado di lavorare al loro ritmo.

Se un'azione ha avuto successo sul lato client, ad esempio l'eliminazione delle e-mail, è anche il tuo lavoro renderlo efficace sul lato server. Perché la cancellazione è fallita? Se è dovuto a qualche tipo di limitazione (ad esempio, non puoi rimuovere un'email che è stata archiviata), l'utente deve essere informato che prima la sua azione non è riuscita.

Se l'errore è causato da qualcosa di più grave (diciamo un arresto anomalo del database), dovresti avere un modo per salvare l'operazione e riprovarla quando il sistema è di nuovo attivo.

Un buon esempio di gestione di questo è il modo in cui Facebook gestisce la chat. Non c'è modo di impedire a un utente di disconnettersi all'improvviso, il che significa che non sarà in grado di leggere i messaggi inviati prima che se ne andassero. Invece di visualizzare un errore, il sistema salva tutti quei messaggi e li rende disponibili all'utente quando ritorna. Nessun dato è andato perso.

È possibile scendere a compromessi tra le due opzioni. Ad esempio, se l'utente cancella una e-mail, è possibile contrassegnarla in rosso o in grigio fino a quando non si ottiene una conferma dal server e solo dopo rimuoverla dall'elenco. L'utente può ancora fare altre cose mentre una azione è in sospeso, quindi non blocca, ma lascia ancora un piccolo promemoria per l'utente che le sue azioni non sono state ancora eseguite.

Amazon AWS adotta questo approccio: quando si interrompe / avvia un'istanza, la casella di controllo che consente di selezionarla si trasforma in uno spinner (quindi non si può fare nulla per alcuni secondi), ma questo non ti impedisce di interagire con altre istanze.

Penso che questo si accompagni a un numero sempre maggiore di siti Web che tentano di comportarsi come Applicazioni e che eseguono più elaborazioni nel browser (come la convalida dei dati del modulo) rispetto ai siti più tradizionali. Non vedo un grosso problema in questo finché il tuo codice è affidabile e puoi aspettarti che abbia successo in condizioni normali.

Dici "È in questo momento che il codice JavaScript scopre che la richiesta AJAX non è riuscita. Lo script potrebbe mostrare un messaggio di errore, ma al momento non ha senso."

Perché dovrebbe essere inutile? Puoi tornare all'elenco delle email e fare di nuovo l'eliminazione. Perché aspettare invece? In realtà non c'è molto di un "rischio" e non "sembrano" essere veloci, in realtà lavorano più velocemente. Quindi se l'attività non è "critica" perché essere lenti?

Il mio 2c è: ci sono situazioni in cui è meglio avere, come si dice, operazioni Ajax "non bloccanti" e altre in cui è una cattiva scelta progettuale. Esempio: votazione di un video di YouTube. Non vuoi che nessuna parte della pagina venga bloccata mentre fai clic sulle piccole partenze. È meglio fallire silenziosamente. Persino un messaggio di conferma sarebbe troppo pericoloso. Tuttavia, il tuo esempio con la cancellazione di e-mail mi qualificherebbe obbligatorio per la richiesta Ajax di tipo bloccante.

Mongo DB fa qualcosa del genere (e questo potrebbe essere considerato un esempio di applicazione desktop). Hanno varie "preoccupazioni scritte" per le loro operazioni, e puoi configurarlo su valori diversi per ogni operazione, che vanno da "riattiva subito e non aspettare nulla" a "bloccare fino a quando non hai conferma del corretto trasferimento di rete e quindi tornare "a" attendere che il contenuto sia pianificato correttamente per la scrittura del disco sulla macchina remota prima del tuo ritorno ". Ovviamente, se si crea un client thick Desktop (come in C ++) usando il driver Mongo, si imposta il più leggero problema di scrittura per le operazioni db con "criticità" minima (come il controllo di nuove e-mail) e altre su problemi di scrittura più rigidi .

Mentre vedo l'utilità di Ajax non bloccante, sono d'accordo con te sul fatto che sta accadendo troppo. Ad un certo punto c'era almeno un famoso sito di "social networking" che avrebbe fatto questo per il caricamento di foto. Avresti scelto la tua foto da caricare e poi bam, subito ti avrebbe detto che è stato fatto, e poi sicuramente il giorno dopo, quando volevi aggiungere qualche altra foto (o usarla su quello che pensavi di aver già aggiunto), non fu mai trovato Più tardi hanno rinunciato a questo, e in realtà hanno avuto il tempo di aspettare la risposta (e in effetti a volte avresti ricevuto messaggi come "fallito il caricamento della foto, prova più tardi").