L'altra risposta inviata è valida. La rimozione delle righe nascoste dal DOM ti offrirà prestazioni migliori. Tuttavia, non affronta il problema di fondo che stai trasmettendo tutti i dati al browser prima di applicare qualsiasi filtro ad esso; che crea molti problemi tangenziali come l'uso eccessivo della larghezza di banda e tempi di risposta più elevati per ottenere l'elenco di elementi.
because users will complain about filters and sorting being applied to loaded records but not to all records
In altre parole, se si restituisce la pagina 2 (articoli da 101 a 200) e l'utente ha chiesto di filtrare i nomi contenenti "pippo", si applica tale filtro a quei 100 articoli; invece di applicare il filtro sul database e quindi di mostrare la pagina 2 del set risultante?
Questo è il tuo problema. I filtri devono essere applicati prima dell'impaginazione. Se si esegue il filtraggio solo sulla pagina Web dopo che tutti gli elementi sono stati caricati, l'impaginazione deve avvenire logicamente anche nel browser.
Potrebbero esistere soluzioni alternative per il tuo attuale problema di prestazioni (come la rimozione degli elementi filtrati dal DOM), ma quando la dimensione dei dati aumenta, il problema relativo alle prestazioni (e alla larghezza di banda) verrà visualizzato di nuovo in una forma diversa (una che non può essere risolto rimuovendo cose dal DOM).
L'unico modo per risolvere in modo sostenibile questo è non passare tutti i dati alla pagina web .
I thought about server sorting and filtering instead but that would just is still not suitable for working with other data manipulation functionality such as grouping.
Non sto seguendo la tua spiegazione qui. Il raggruppamento è solo un altro passo sulla strada per ottenere l'output desiderato. Esiste una logica sequenziale sul recupero dei dati:
- Filtro
- gruppo
- Ordine
- Seleziona
- Impagina
Non tutti i passaggi sono necessari, ma l'ordine in cui eseguirli è solitamente lo stesso (salvo alcuni casi marginali, ad esempio il filtraggio di gruppi complessi - a quel punto il raggruppamento diventa un dato e non un'opzione secondo la descrizione)
Quello che stai facendo ora è smorzare il tuo back-end e assumersi tutte le responsabilità nel frontend, che non è semplicemente un buon design. Il back-end (in particolare un'archiviazione dei dati basata su SQL) è adattato per un efficiente recupero dei dati.
Non vedo alcun argomento ragionevole per trasferire tutta questa responsabilità a un frontend che è intrinsecamente meno capace di gestire grandi raccolte di dati e di eseguire costose operazioni di dati. Sconvolge tutte le parti coinvolte:
- La rete interna tra database e backend invia più dati di quanti l'utente sia effettivamente interessato.
- Il back-end deve istanziare più dati di quanti l'utente sia effettivamente interessato.
- La rete esterna tra back-end e frontend invia più dati di quanti l'utente sia effettivamente interessato.
- Il frontend deve gestire molti più dati di quanti l'utente sia effettivamente interessato.
Stai facendo perdite nel carico di rete, nell'uso della larghezza di banda, nelle prestazioni delle applicazioni e nell'esperienza utente, il tutto a vantaggio di non dover sviluppare un metodo per filtrare / raggruppare / ordinare / impaginare dati sul back-end?
I professionisti non superano gli svantaggi qui.
[From a comment] there are client side functions that are driven by the users interaction that should take all data into account
Stai mettendo il carro davanti al cavallo qui. Li stai già chiamando "funzione lato client" che è la fonte del problema. Se dovessi impostare un'interazione tra il frontend e il backend in modo che il backend possa gestire la manipolazione dei dati necessaria, allora non sono più "funzioni lato client".
Non riesco a pensare a nessuna manipolazione di dati che può essere fatta solo lato client e non lato server. Mi interessa ascoltare un esempio di queste "funzioni lato client".