Prednastavenie Select fieldu s lazy datami v SPA appke

[schwantner.peter]

Ahojte, neviem si rady s nasledujucim problemom.

Pouzivame v SPA appke klasicky select field, ktoremu viete nastavit value s ID objektu, a sadu objektov, a na zaklade predaneho ID vie prednastavit prave nastaveny objekt. Mame to tak aj pri editacii property na objekte, kliknete na editovat, dotiahne si cez ajax mnozinu objektov ktore ma uzivatel na vyber, a podla aktualneho ID predstavy aktualny objekt.

Problem nastava ked tych dat je strasne vela, doimplementovali sme filter a paging s infinity scroll. To nam funguje pekne, pri hladani polozky koru chcete zvolit, sa vam na pozadi paguju nove zaznamy a pridavaju do mnoziny v selecte, alebo viete zacat v selecte pisat a zaznamy sa serverovo odfiltruju.

Neviem vsak, ako pri takomto selecte, prednastavovat objekty, predstavte si ze niekto ma na sebe nastavenu polozku z poslednej page, klikne editovat, a zobrazi sa mu modal, v ktorom je select, a v nom by mal vidiet aktualne zvoleny objekt, no mal by aj vediet scrollovat nizsie a vybrat si z inych. Lenze ja podla ID neviem aku page mu mam dotiahnut, takze riesenim by mohlo byt dotahovat zaznamy, az kym sa v nich nebude nachadzat prave nastavene ID, co pri desat-tisicoch zaznamoch neni optimalne. Viete poradit ako sa taketo veci bezne riesia, alebo ako by ste to riesili vy? Dakujem.

[Reklama]

[Filip Jirsák]

Dává to pocházení po stránkách vůbec pro uživatele smysl? Když může mít seznam desítky tisíc záznamů, asi v tom nebude uživatel něco hledat očima, ne? Může tedy dávat smysl i zobrazit uživateli jenom ten jeden vybraný záznam a spolu s ním ty vstupy pro filtrování – a teprve když něco zadá, vypsat mu ty záznamy, které odpovídají podmínce. Plus aktuální hodnotu – tu by bylo dobré v seznamu zachovat vždy.

Další věc je, že je nevhodné používat stránkování typu ,,strana 7 po 20 záznamech". Z pohledu uživatele to nedává žádný smysl. Lepší je najít způsob stránkování, který dává smysl i z pohledu uživatele – třeba podle počátečních písmen. Ale pokud máte desítky tisíc záznamů, nepomůže ani to. Každopádně je lepší i interně řešit stránkování jako ,,začni na položce X a vypiš jich 20". Pak ani nevadí, že nevíte, na které stránce je to vaše ID – prostě zobrazíte stránku, na které je (pokud stránky nedávají žádný smysl, pak je rozumné zobrazit takovou stránku, kde ta položka bude uprostřed). Bez ohledu na to, že by se na takovou stránku uživatel nedostal, kdyby roloval od začátku. Takže třeba kdybyste zobrazoval čísla 1–100 po 10 na stránce – když budete potřebovat zobrazit položku 27, zobrazíte záznamy 23–32. Když se uživatel bude pohybovat nahoru, donačtete 13–22, pak 3–12 a nakonec 1–2. Je tedy potřeba mít backendovou službu, která neposkytuje ,,data pro stránku 3", ale která poskytuje ,,stránku začínající X" (případně ,,stránku, která má uprostřed X").

[schwantner.peter]

Dává to pocházení po stránkách vůbec pro uživatele smysl? Když může mít seznam desítky tisíc záznamů, asi v tom nebude uživatel něco hledat očima, ne? Může tedy dávat smysl i zobrazit uživateli jenom ten jeden vybraný záznam a spolu s ním ty vstupy pro filtrování – a teprve když něco zadá, vypsat mu ty záznamy, které odpovídají podmínce. Plus aktuální hodnotu – tu by bylo dobré v seznamu zachovat vždy.

Další věc je, že je nevhodné používat stránkování typu ,,strana 7 po 20 záznamech". Z pohledu uživatele to nedává žádný smysl. Lepší je najít způsob stránkování, který dává smysl i z pohledu uživatele – třeba podle počátečních písmen. Ale pokud máte desítky tisíc záznamů, nepomůže ani to. Každopádně je lepší i interně řešit stránkování jako ,,začni na položce X a vypiš jich 20". Pak ani nevadí, že nevíte, na které stránce je to vaše ID – prostě zobrazíte stránku, na které je (pokud stránky nedávají žádný smysl, pak je rozumné zobrazit takovou stránku, kde ta položka bude uprostřed). Bez ohledu na to, že by se na takovou stránku uživatel nedostal, kdyby roloval od začátku. Takže třeba kdybyste zobrazoval čísla 1–100 po 10 na stránce – když budete potřebovat zobrazit položku 27, zobrazíte záznamy 23–32. Když se uživatel bude pohybovat nahoru, donačtete 13–22, pak 3–12 a nakonec 1–2. Je tedy potřeba mít backendovou službu, která neposkytuje ,,data pro stránku 3", ale která poskytuje ,,stránku začínající X" (případně ,,stránku, která má uprostřed X").

Ono sa to komplikuje aj v tom, ze ak mu zobrazim polozky 13-22, tak by musel v tom selectitku scrollovat s lazy loadingom hore aj dole, co sa mi tiez velmi nepaci, ale mozno je to len moj subjektivny nazor.

[Filip Jirsák]

Ono sa to komplikuje aj v tom, ze ak mu zobrazim polozky 13-22, tak by musel v tom selectitku scrollovat s lazy loadingom hore aj dole, co sa mi tiez velmi nepaci, ale mozno je to len moj subjektivny nazor.

Podle mne první otázka, kterou je potřeba vyřešit je – jaký má uživatel důvod v seznamu desítek tisíc položek skrolovat? Nemůžeme mu nabídnout něco, aby to dělat nemusel? Pokud mu to nabídneme, má zůstat možnost tam skrolovat? Nebo nebude omezená na skrolování v jednotkách položek (tím pádem není nutné řešit lazy loading)?

[k1k1n]

Já to tedy dělám tak, jak píše Filip Jirsák. Vyhledávám podle filtru a pokud je položek tolik, že se nevejdou na jednu stránku (třeba 20, ale spíš míň), tak zobrazím prvních 20 a info, ať upřesní filtr. Stránkování v selectu mi přijde hrozně neergonomické a infinity scroll jako úplné šílenství (proč, když stejně nevím, kde zhruba leží to co hledám, a pokud to vím, tak je lepší to napsat, než tam scrolovat)

[Reklama]

[fos4]

Pokud je položek v selectu více nebo nevím či si nejsem jist, že by tam ta položka byla (jako tvůj případ) tak tu hodnotu dám jako hned první <option> v selectu a oddělím to prázdným <option disabled=""> a pak následují ostatní data..