Ahh, so you want an auto complete text box that fetches from server on the fly using jQuery right? If so, sure +1
On Sun, Dec 16, 2018 at 11:41 AM Deepak Dixit <[email protected]> wrote: > > Pagination widget tries to generate select with a huge number of options so > browser takes too much time to prepare dom and causing unresponsiveness. > > So we can say that the root cause is in the pagination widget that > prepares select option. We need a different pattern rather than select > element for rendering the page (VIEW_INDEX) > > Thanks & Regards > -- > Deepak Dixit > > > > On Sat, Dec 15, 2018 at 7:14 PM Taher Alkhateeb <[email protected]> > wrote: > > > Yeah so what you are describing is a pagination issue right? The root > > cause is pagination, not type of widget being used? I'm a little > > confused by the proposal? > > > > On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas <[email protected]> > > wrote: > > > > > > Hello Taher, > > > > > > The browser becomes unresponsive to a user in this case, as the browser > > is > > > busy in preparing the large '*select*' DOM element(a drop-down with > > around > > > 250,000 options). > > > I found some points related to our discussion here > > > <https://developers.google.com/web/tools/lighthouse/audits/dom-size>. > > > > > > > > > Thanks & Regards, > > > Devanshu Vyas. > > > > > > > > > On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas <[email protected] > > > > > > wrote: > > > > > > > Hello Taher, > > > > > > > > The FTL is trying to render a list(select box) with a large number of > > > > options(around 250,000 in my case) which takes a lot of time and the > > > > browser usually asks to either kill the page or wait for it to load > > > > completely. > > > > > > > > Thanks & Regards, > > > > Devanshu Vyas. > > > > > > > > > > > > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb < > > > > [email protected]> wrote: > > > > > > > >> before proposing the solution we need a diagnosis. What is the strain > > > >> happening on the browser? > > > >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas < > > [email protected]> > > > >> wrote: > > > >> > > > > >> > Hello Guys, > > > >> > > > > >> > Recently, I came across a situation where an entity was taking too > > much > > > >> of > > > >> > a time(browser asked me to either wait or kill) while > > loading/searching > > > >> > results in the Webtools application. The entity had close to 5M > > records, > > > >> > and I checked the server responded timely but the rendering of the > > > >> screen > > > >> > was taking time. > > > >> > When I explored the issue I came across a macro which renders the > > > >> > pagination on the screen, and it had a code block which was causing > > the > > > >> > screen rendering delay. > > > >> > {code} > > > >> > > > > >> > <#assign x=(listSize/viewSize)?ceiling> > > > >> > <#list 1..x as i> > > > >> > <#if i == (viewIndex+1)><option selected="selected" > > > >> > value="<#else><option value="</#if>${i-1}">${i}</option> > > > >> > </#list> > > > >> > > > > >> > {code} > > > >> > This code seems logical enough to me, and what I gather from this is > > > >> that > > > >> > the list will render a select box with 250,000 options. > > > >> > > > > >> > I would like to propose a change in this UI/UX from select box to an > > > >> input > > > >> > text box so a user can navigate to any page, similar to a navigation > > > >> input > > > >> > box in a PDF document reader application. > > > >> > > > > >> > Please let me know your thoughts on this and share some more ideas > > to > > > >> how > > > >> > we can improve/resolve this issue. Looking forward to your replies! > > > >> > > > > >> > > > > >> > > > > >> > Thanks & Regards, > > > >> > Devanshu Vyas. > > > >> > > > > > >
