Introduction à la table de tri dans layui

Aujourd'hui, parlons du tri des tables. Laissez-moi vous donner un aperçu, le but est de faire la distinction entre le tri frontal et le tri du serveur. La pagination actuelle des tableaux est en fait assez "désordonnée", je crois que de nombreux étudiants qui l'utilisent depuis un certain temps, en particulier ceux qui le font. Le tri du serveur rencontrera cette situation dans une certaine mesure.

Recommandé : Tutoriel Layui

Examinons d'abord l'effet du tri fourni avec le tri layui par dictionnaire n'est pas l'objet de cette discussion. et si Il y a des situations où des entiers négatifs et 0 apparaissent

Alors pouvons-nous ajuster la logique de manière à ce que la logique de jugement des nombres négatifs et 0 soit correcte ? Ce n’est en fait pas l’objet de cette discussion.

Le fait est que le tri du serveur. En fait, le tri de la plupart des tableaux n'est pas simplement un simple tri d'une seule page, mais les conditions sont transmises à l'arrière-plan pour le tri par l'arrière-plan. , il s'agit de surveiller le tri, puis de recharger et de transmettre les conditions. Tout est ok et la logique est bonne.

Mais quel est l’effet réel ? Parce que le tableau actuel ne fait pas de distinction entre le tri au premier plan et le tri du serveur, après avoir reçu les données puis rendu le tableau, il est déterminé qu'il y a initSort, puis les données seront à nouveau triées puis affichées. Cela présente un problème très sérieux !

Évidemment que le serveur l'a trié, pourquoi devons-nous le trier à nouveau en js ? Plus sérieusement, peut-on s'assurer que le résultat du tri est cohérent avec le résultat de la règle de tri en arrière-plan ? Quelle garantie y a-t-il ?

Regardez le code ci-dessous lorsqu'il surveille le rechargement, puis simule l'arrière-plan pour renvoyer les données selon la règle des nombres négatifs

Code :

Effet

Vous pensez peut-être qu'il n'y a pas de différence avec le précédent, mais le tri est toujours erroné. C'est une exception. . lieu. Jetez un œil à la structure des données renvoyées par ma simulation

Données d'origine :

Données renvoyées par l'interface simulée :

Après ce retour , c'est évident L'effet affiché ne correspond pas à l'ordre des données réelles

La raison est celle mentionnée ci-dessus. Lors de l'envoi réel du tri en arrière-plan, vous devez toujours passer par le tri frontal lorsqu'il est effectué. temps de rendu, ce qui équivaut à effectuer un processus superflu. En fait, si l'on définit les données renvoyées par le tri du serveur, ce sera l'ordre à afficher.

Vous ne devez pas utiliser le tri front-end pour trier cette logique. Sinon, quelle est la signification du tri back-end et comment s'assurer que la logique est cohérente avec le back-end. , ce sera au mieux un effort inutile, mais si la cohérence ne peut être garantie, c'est un gros accident.

Solution : Fournir aux utilisateurs un élément de configuration pour décider s'ils doivent trier par premier plan ou par serveur. Modifier ce qui suit

La zone de code d'origine qui doit être modifiée

Le code de la zone correspondante après modification :

La table testée est dans La configuration de sortType a été ajoutée lors du rendu

Enfin, le suivi du tri

L'effet final

Le code de test complet contient également les éléments suivants. L'adresse de modification correspondante de table.js : https://pan.baidu.com/s/1OjwwVmjy02wRQ0rT1euLlQ

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!