search

mskilab-org / case-report

Genomic case report
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Delay when switching tabs #7

Open shihabdider opened 3 weeks ago

shihabdider commented 3 weeks ago

Describe the bug When the user switches from one tab to another (especially a tab that has a lot of components to render) there is a delay in loading that tab.

To Reproduce Click on a tab. Then click on the Pan-Genome View tab.

Expected behavior Clicking on any tab should immediately switch to that tab. Any components which need to be rendered and hydrated with data should do so afterwards, with indications to the user of their loading state (e.g a progress bar).

xanthopoulakis commented 3 weeks ago

This may need some further thinking here; normally components are loading asynchrnonously, under the hood, but as JS is single threaded, showing the actual graphics on the screen may occupy the execution thread; so, while the data is indeed in browser memory, populating the UI elements may after all take some time.

There is of course margin for performance improvement, but let's stay focused on which tab rendering causes the delay and what be done about it

shihabdider commented 3 weeks ago

It seems to be the pan-genome tab in particular (though all the tabs have this slight delay).

But I think I'm misunderstanding your comment. My understanding is that the hydration of the components will take time since there is a large amount of data being loaded, but that shouldn't (and doesn't as far as I can tell) halt the loading of their container components.

The loading sequence I'm suggesting is something like this: user clicks on tab -> switch to tab -> render placeholder components for those components that are still mounting -> render a loading wheel for those components that are still hydrating with data -> component with data fully loaded.

In this sequence, mounting empty placeholder components should be very fast and not halt the switching of the tab. My suspicion is that the delay comes from attempting to mount the full components (likely from cache). Ultimately, this is low priority as the delay is not substantial. Still, it represents a code smell that should be investigated at some point.