Zobrazit 1000+ radek v prohlizeci zase neni takovy problem.
podla mojho pozorovania spravania prehliadacov je
jednoducho to zvycajne meratelne dlho renderuje, v nejednom pripade scrollovanie laguje a tak.
Ale som ochotny uznat, ze problem je pri vacsom pocte riadkov, nikdy som si nerobil statistiku.
Otazka je jestli o to uzivatel doopravdy stoji.
samozrejme, ze nestoji
problem je na inej strane: niekedy jednoducho ma uzivatel usecase, ze potrebuje nieco na co programator nepomysel.
(ked programator pomysli, tak samozrejme uzivatel ma k dispozicii lahko pouzitelne spravne filtrovanie a nepotrebuje zobrazovat viac nez povedzme 30 zaznamov)
U strankovani nekde zobrazujete x/y, kde "x" je aktualni stranka a "y" je celkovy pocet stranek. Spocitat to y byva casto velmi narocne na vykon a uzivatele to casto ani nezajima. Projde jen prvnich 3-5 stranek a pak zada jiny dotaz.
svet nie je len nasepkavac v googli
U nekonecneho strankovani si zapamatujete posledni zobrazene ID a to pak pridavate do filtru where clausule:
...
Takze ked chcem vidiet posledny 1000ci prvok, tak mi skusate nahovorit, ze mam byt nadseny, ze budem 19x riesit problem pomaleho scrollovania (kedze zakazdym doplnite 50 zaznamov), kde zakazdym bezi pomaly dotaz na server a do databazy? (bez ohladu na optimalizaciu, rezia je sama o sebe neprijemna)
---
ok, chapem, ze ak je gro vasej prace robenie veci ako nasepkavac, tak rozumiem, ze "nekonecne scrollovanie" je fajn.
Len na zaciatku ste sformulovali ultimatnu myslienku, ze to je vo vseobecnosti jedine spravne riesenie.
Tak ma zaujalo, nakolko prehanate.
Priklad z praxe: mam zoznam o tak 500 prvkoch, vzdy hladam jeden konkretny. Tu by ma asi uzivatelia zabili, keby som im ponukol vami preferovane riesenie.
Zobrazit příspěvky
