Comment traiter avec de grands ensembles de données avec jQuery isotope

Prendre l'idée de lire le cache, quelque chose comme:

• Créez une méthode pouvant charger un lot d'éléments maximum de 100 (ou de tout numéro configurable). Ce serait:
  • Rechercher dans le cache (matrice JS avec clé primaire l'ID de l'élément) pour les éléments filtrés
  • Demande de Ajax Les éléments filtrés
  • Les éléments renvoyés par Ajax seraient ajoutés au cache
  • Les éléments renvoyés par Ajax seraient également ajoutés dans une zone "Chargement" au bas de la DOM (voir ci-dessous), avec l'ID de la DIV créée la clé primaire de l'élément
  • Le serveur enverrait jusqu'à 100 éléments. S'il n'y a pas de filtre, il n'enverrait pas encore les éléments suivants. Vous auriez besoin de suivre les éléments chargés. Si la taille des données en cache sur le côté serveur (c'est-à-dire la session) est essentielle, vous pouvez garder une piste uniquement de l'ID envoyé continu continu (c'est-à-dire si vous envoyez 1er ID par lots 1,2,3,6,9,10, puis le Identifiant le plus élevé est 3, alors la prochaine fois que vous enverriez de 4, ..., donc vous conservez une seule valeur)
  • Créez une méthode pouvant déplacer les divs mis en cache vers / depuis le conteneur Isotope
  • Charge ONDDomReady en utilisant la méthode ci-dessus et affiche les 20 premiers éléments par ordre naturel (dans votre cas, il serait alphabétiquement par nom). Il peut s'agir de 20 éléments ou 50 ou n'importe où ...
  • En arrière-plan, chargez-vous en boucle par Ajax et par lot de 100 tous les éléments.

    La zone de chargement pourrait être simplement: xxx

    de cette façon, vous pouvez charger tous les éléments étape par étape dans le DOM et vous pouvez afficher uniquement ce qui est nécessaire. .

La situation que vous décrivez est jolie: comment donner à votre utilisateur l'accès à plus de données que ce qu'ils ne peuvent éventuellement voir en détail à la fois.

Il existe plusieurs façons de répondre à la question et la bonne réponse est complètement subjective: cela dépend de ce que votre utilisateur tente de voir ou de faire avec les contacts. Avant de pouvoir obtenir une solution satisfaisante, vous devez savoir ce que les utilisateurs vont utiliser les contacts pour.

Juste deviner (mais vous sauriez mieux que moi!), Je m'attendrais à ce qu'il y ait deux choses qu'ils font:

• Recherche: à la recherche d'un contact spécifique et ils connaissent déjà leur nom / poignée.
• Explorez: Vous recherchez un contact spécifique mais ils ne peuvent pas se souvenir de leur nom / manche. Ou ils sont juste en navigation.

  Si vous filtrez pour toutes les solutions, l'objectif de recherche est à peu près dans le sac. L'objectif explore est celui que vous souhaitez concevoir pour:

  • Sous-fichier aléatoire: Ce n'est pas un excellent moyen de parcourir depuis que vous êtes essentiellement laissé avec un sous-ensemble à parcourir, puis de filtrer explicitement pour voir quelque chose de nouveau. Difficile à filtrer lorsque vous ne savez pas exactement ce que vous recherchez.
  • Infinite défilement: semble être une solution populaire ces jours-ci. Je trouve que c'est encombrant, surtout si vous êtes "infiniment" défilant à travers 1000 contacts. Probablement pas génial pour l'objectif explore.
  • Paging: aussi encombrant - mais peut-être que si la pagination est liée au tri alphabétique, cela pourrait bien fonctionner.
  • Seuil LIMITER: Alors ... comptez simplement sur le filtrage? Cela peut être mauvais dans certains cas d'angle dans lesquels l'utilisateur applique un filtre et ne voit rien de B / C Le seuil n'est toujours pas atteint (peut-être qu'il y a un lot de personnes avec le dernier Nommez Johnson, qui est ce que vous avez recherché). De plus, je pense que la capacité de naviguer est importante lorsque vous ne savez pas ce que vous recherchez.

    ---

    Je pense que si j'étais à votre place, j'intrivrerais un clustering des contacts. Je doute que les 1000 contacts soient une grande partie d'un problème de performance (en moins que vous parlez un million!), De sorte que 10000+ est vraiment une contrainte utilisateur: ils ne peuvent tout simplement pas voir 1000 contacts à la fois.

    Je suggérerais d'introduire un clustering, probablement par le nom de famille ou le nom de famille et le prénom. Présentez ensuite l'utilisateur avec un moyen de percer un cluster, mais de replier tous les autres contacts afin qu'ils ne soient pas immédiatement visibles. Quelque chose dans la colère du paradigme Accordien / Rollodex . Cela donne à votre utilisateur l'illusion qu'ils travaillent avec «tous les contacts». Introduisez probablement un nombre minimal pour chaque groupe de sorte que si le cluster soit suffisamment petit, vous ne vous prenez pas la peine de le montrer (c'est-à-dire pourquoi montrer un cluster pour 2 ou 3 ou 5 contacts - indiquez simplement les contacts). Comme les filtres sont appliqués, les clusters s'éloignent.

J'écoutais des performances médiocres lors de l'annexe et de l'organisation d'un grand nombre d'articles d'isotope et c'était parce que j'avais l'ajout d'articles incrémentiellement plutôt que dans un lot. Ce devrait être un choix évident, mais quelque chose que j'avais négligé.

Assurez-vous d'utiliser un tableau ou une liste d'éléments, par opposition à la chargement ou à la suppression individuelle. P>

incomingData=['<div>a</div>','<div>b</div>'];
elements=[];

jQuery.each(incomingData,function(ind,val){
    var element = jQuery(val).get(0);
    //$container.isotope('insert', element); //resource heavy
    elements.push(element); 
});

$container.isotope( 'insert', elements ); //less processing