Come posso restituire l'HTML generato e anche una risposta?

Should I return HTML, then make another AJAX call for the response?

A meno che tu non abbia una ragione convincente per non farlo (non ce n'è alcuna che possa pensare), dovresti decisamente preferire ridurre al minimo il numero di chiamate. Ogni chiamata ha il sovraccarico della risoluzione dell'URL / ecc. e se stai ricevendo gli stessi dati che invierai comunque nella singola chiamata, non c'è motivo per questo spreco.

Should I return the HTML as part of the JSON?

Restituire HTML in JSON va bene, se usi jQuery (o anche l'accesso DOM nudo), è facile aggiornare l'HTML di un elemento. Se non hai bisogno del messaggio HTML, quella proprietà può essere nullo o omessa del tutto, quindi non sarebbe inutile includerla solo nei casi in cui ne hai bisogno.

Should I only return one or the other?

Dalla funzione ASP.NET? Penso che probabilmente è meglio includere la proprietà HTML come parte di un protocollo standard. Ad esempio, ho 3 proprietà standard da tutte le chiamate AJAX: Success, ErrorMessage, ErrorTitle. Ciò rende più facile per qualcuno lavorare anche da quando possono contare su chi è sempre presente e agire di conseguenza.

Should I return HTML and store the response in data- tags?

Potresti avere un caso d'uso in cui ciò ha senso, ma in generale, ha più senso avere le funzioni JS per rispondere al protocollo dei messaggi standard. In questo modo consente al chiamante un maggiore controllo su come, quando, dove, ecc. Vengono visualizzati i messaggi. Puoi anche trovare delle impostazioni predefinite che possono essere ignorate se ce n'è bisogno.

Una buona pratica è mantenere la risposta coerente, nel senso che è necessario sempre avere JSON che offra una struttura che sia coerente e fornisca informazioni sufficienti per dedurre se la chiamata è stata un successo.

Prima controlla lo stato Ajax che il comando è stato gestito correttamente. Una volta determinato che il comando è stato gestito correttamente, procedi quindi a controllare il tuo json, in particolare una sorta di indicatore che implica se il tuo programma interno possa gestire quella particolare richiesta.

Se entrambi sono corretti, cerca una proprietà aggiuntiva che devi garantire di essere sempre li che contiene la stringa HTML. Se qualcosa va storto, allora si cerca una proprietà aggiuntiva che è necessario garantire in caso di errore che contiene il messaggio di errore.

Ciò che è importante è che tu abbia sempre un indicatore del successo per farti sapere cosa aspettarti dalla risposta. Questo è ovviamente del tutto arbitrario, ma la best practice impone che se il comando ajax andasse bene, dovresti fornire abbastanza informazioni in modo che il tuo programma javascript sappia cosa fare dopo.

Dichiarazione di non responsabilità: questa risposta non è d'accordo con la risposta corrente accettata. Mantenere una mente aperta e vedere perché. Stiamo solo cercando di condividere la conoscenza qui, giusto? Vai alla fine per TL; DR

Per chiunque ne sia inciampato ora, questa risposta cerca di attenersi al modello di progettazione di MVC nel contesto del web definito semplicemente di seguito:

• Modello: il livello di persistenza dei dati
• Visualizza: il sistema di template
• Controller: azione che ottiene i dati e li fornisce a una determinata vista

Non spiegherò il motivo per cui la separazione ha appena saputo che questo modello di progettazione è noto per essere più scalabile quando viene seguito in modo appropriato.

Alcuni altri termini (le sigle non significano davvero nulla):

• AJAX: niente più che una tecnica che utilizza javascript per ottenere dati e aggiornare quella pagina invece di aggiornare la pagina
• JSON: uno standard per i dati strutturati

Should I return the HTML as part of the JSON?

No, JSON dovrebbe essere solo rappresentazioni di dati. Questo fa parte del 'modello' in MVC. Se restituisci l'HTML reso nel tuo JSON, non puoi modificare l'implementazione della vista. Una volta ottenuto l'HTML reso, sei bloccato con esso.

Should I only return one or the other?

Sì, JSON fa parte del "modello" perché rappresenta i dati. HTML è parte della 'vista'. Quando hai HTML in una risposta JSON, stai restituendo dati con una vista al suo interno. Credo che questo non segua MVC.

Se qualcuno utilizza specificamente ASP.NET, ti consiglio di restituire un PartialView quando vuoi "restituire solo HTML" quando AJAXing. Tieni presente che devi solo restituire una vista parziale quando desideri modificare una determinata parte della pagina senza aggiornarla completamente (defAJAX). Questa risposta potrebbe essere di aiuto.

Should I return HTML, then make another AJAX call for the response?

Questa domanda potrebbe essere strana. Suppongo che l'obiettivo nel contesto sia quello di aggiornare la pagina senza aggiornarla completamente, ovvero AJAX. Quando "restituisci HTML" fai una chiamata AJAX per HTML e aggiorni una determinata parte della pagina dall'HTML reso. Non ha senso effettuare due chiamate AJAX perché la chiamata AJAX che fai per HTML dovrebbe già avere una "vista" renderizzata con le informazioni al suo interno.

Se si effettua una chiamata AJAX solo per i dati (in formato JSON), si prenderanno quei dati e si manipolerà il DOM utilizzando i dati, ovvero creare un elemento e inserire data.message.

Should I return HTML and store the response in data- tags?

No, non penso che avrebbe senso. Quello che stai cercando di fare è salvare lo 'stato' del documento nei tag dei dati e dovresti semplicemente 'salvare lo stato' semplicemente cambiando il testo degli elementi stessi.

TL; DR L'obiettivo finale delle chiamate AJAX è di cambiare lo stato del DOM senza aggiornare la pagina. Dovresti rendere AJAX per i dati (sotto forma di JSON) non renderizzati HTML perché questo è molto più flessibile e riutilizzabile.

Fai una chiamata AJAX per i dati quindi usa javascript per cambiare pagina.

Mantieni l'interfaccia e l'implementazione semplici. Dal momento che stai usando la richiesta http, dovresti approfittare delle sue funzionalità. Ad esempio, invece di creare una nuova interfaccia "tipo", puoi utilizzare il codice di stato http.

Se si utilizza il codice di stato http, quindi sul lato JavaScript, è possibile sfruttare anche questo vantaggio. Ad esempio, se si utilizza jquery, ha gestori per le chiamate ajax che utilizza il codice di stato HTTP come fattore per decidere se deve chiamare l'errore o il gestore di successo.

Se devi ancora restituire json & html, hai la tua interfaccia che restituisce i dati in entrambi i formati in base al valore di intestazione http Accept impostato dal client quando si effettua una chiamata jax. Quindi il tuo codice per la visualizzazione di html non ha bisogno di sapere sul formato dei dati restituito perché ottiene solo ciò di cui ha bisogno, quale html.