Le produit veut afficher un tableau de cinquante mille lignes avec tri et édition en ligne. Comment le construiriez-vous ?

Ne mettez pas cinquante mille lignes dans le DOM. Virtualisez pour ne rendre que la fenêtre visible plus un petit dépassement, gardez une hauteur de ligne prévisible ou mesurez-la, et sortez le tri et le filtrage du rendu vers des données dérivées mémoïsées ou vers le serveur. Paginez ou diffusez les données elles-mêmes, gardez l'état de la ligne en édition en local pour qu'une frappe ne re-rende pas le tableau, et testez avec un processeur bridé.

La première chose que je dis, c'est que cinquante mille lignes ne devraient jamais être dans le DOM en même temps, parce que le layout et la mémoire croissent avec le nombre de noeuds quelle que soit la rapidité de mon framework. Donc je virtualise : je rends les lignes de la zone visible plus un petit dépassement, je les positionne en absolu dans une cale de la hauteur totale, et je les recycle au défilement. Ensuite je traite les données comme un problème séparé. Trier et filtrer cinquante mille enregistrements à chaque frappe bloquera le thread principal, donc soit le serveur le fait et je demande une page, soit je mémoïse le tableau dérivé pour qu'il ne se recalcule que quand la clé de tri change vraiment. Pour l'édition en ligne, je garde la valeur brouillon dans l'état propre à la ligne et je ne la remonte qu'à la validation, sinon chaque caractère re-rend le tableau. Ce que les gens oublient, c'est l'accessibilité et la recherche dans la page : les lecteurs d'écran et la recherche du navigateur ne voient que les lignes rendues, donc je pose explicitement les attributs de nombre de lignes et je fournis un vrai champ de recherche plutôt que de compter sur celui du navigateur.