Bonjour,

Un autre soucis avec ng-repeat, c cool avec les petites données mais, quand on à un gros retour de requete avec une énorme quantité de données.
si je prends data in datas, avec plus de 1000 objets dans datas
Même en faisant un scroll infini, le ng-repeat doit toujours se "balader" avec un monstrueux sac à dos.
lol
même en faisant un scroll infini, les données se cumules dans datas pour ne pas supprimer les données déjà affichées.
ng-repeat ne peux pas afficher les données au fur et à mesure sans les stocker stupidement dans la variable ????????
Modifié par quice (19 Jan 2015 - 20:05)
Pourquoi, une fois les données dans le DOM, ng-repeat recommence pas à 0 (lors d'un ajout de données) sans grossir la variable ???
les données sont ajoutés dans le DOM, on les oublis, point !
pas très optimisé leur truc

et au pire si le gars veut quand même garder tout le stock de 2 milliards de datas, mettre une option qui le permette.

Et après on s'etonne que les navigateur bouffent trop de mémoire, normal, avec une pareille inepcie en dev LOL, bonjour le poids de la variable
Modifié par quice (19 Jan 2015 - 20:04)
Je ne comprends pas ton soucis.

On pourrait comparer ça avec PHP, tu vas faire une requete SQL sans LIMIT (service chez Angular), et tu stockes la totalité dans une variable (variable scope chez Angular), mais tu n'affiches que 10 résultats via un for() ?

Ou, tu fais ta requete SQL avec un LIMIT 10, et tu stockes uniquement le résultat dans ta variable PHP, et si tu veux les 10 résultats suivants, tu refais une requete SQL.

Et bien pour Angular, c'est strictement la même chose, évidemment ça limite les interactions, néanmoins, le fait que Angular puisse gérer le tri, les filtres, la recherche facilement ne signifie pas pour autant que tu dois l'utiliser pour des données très importantes.

Tu pourras constater ici https://builtwith.angularjs.org/ que même avec de très grosse data, ça marche toujours très bien.
non, c'est pas du tout la même chose,
dan le ng-repeat, par exemple "a in b", tu vas stocker 10 données dans b, le ng-repeat va les afficher.
les 10 suivant vont être ajouté à b, donc b va en avoir 20 etc....
Au bout de 100 ajouts, b va contenir 1000 données, pour rien.
ng-repeat devrait afficher 10 données, une fois affichées, vider b afin de recevoir les 10 suivant, au bout de 100 appels, b aura toujours 10 données maximum.
de cette façon, b n'aura jamais un poids monstrueux et le navigateur reste légé en mémoire.
Si jamais b est vidé et remplacé par les 10 nouvelles données, les données affichées sont supprimées puisque plus contenues dans b et donc le ng-repeat.
Pour combler cette lacune, il faut faire de la pagination, ce qui permet d'avoir b = le nombre de données souhaités par page.
En scroll infini, b = le nombre de données permanentes = poids de la variable monstrueux et qui va croissant...
On part du principe que le contexte est le scroll infini.

Donc tu trouves dérangeant d'avoir 1000 lignes json, mais tu trouves normal d'avoir 1000 bloc div (ou autre) ?

Essai en pure HTML, d'y mettre 1000 lignes dans un fichier (les mêmes que Angular doit générer), en static, et dis moi si tu trouves que ta page est fluide (sans mettre le moindre bout de JS) ?
Modifié par kenor (19 Jan 2015 - 22:04)
Les 1000 div sont "indispensables" à l'affichage, les 1000 données permanentes, non.
Le problème c'est qu'actuellement, non seulement on aura les 1000 div mais les 1000 données en mémoire alors qu'on aurait pû avoir un seul des deux
Modifié par quice (19 Jan 2015 - 22:48)
Je ne vois pas comment 1000 divs peuvent être indispensable, tu peux expliquer le contexte exacte ?
Ben, si il y a 1000 articles à afficher (exemple), les 1000 divs (en scroll infini) doivent être présents.
Par contre dans la variable b, c'est complètement inutile et aberrant.

tu vas par exemple sur un site de vignettes comme celui ci
http://space-pics.tumblr.com/archive
en scroll infini on va très loin, et il y en a, ils sont énormes
alors en ng-repeat, non seulement on affiche mais on garde en variable (!)
Modifié par quice (19 Jan 2015 - 22:57)
Hum, à en croire la source de l'exemple que tu me donnes, il utilise la même méthode que tu décris (sauf qu'ils utilisent Backbone, un autre FW JS (ou plutôt bibliothèque)), mais dans l'absolu, il stocke les données en json et le DOM. Tout comme Angular.

Sauf qu'ils semblent faire comme je te l'indique, il masque les éléments du début (plus affiché) et les réaffiche quand tu reviens (scroll longtemps vers le bas, puis rescroll vers le haut, puis re vers le bas, tu verras qu'ils réaffichent les images à la volée, pour garder la fluidité de ta page).