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. > > >> > > > >
