Improve schema viewer user experience

[CarolineDenis]

Fixes #1831

[melton-jason]

Is #2080 and/or #2815 within the scope of this Pull Request, or will they be added at a later date?

[melton-jason]

Looks great, and supports using Find (CTRL + F) to quickly go to any field in the database!

While not important, would it also be possible to include a button above the Accession Table button in the sidebar to redirect to the user to the very top of the Schema Viewer? Currently the quickest way to back to the list of every table when you are anywhere else on the page is to click on Accession and then scroll up.

[grantfitzsimmons]

Nice work!

@melton-jason, a jump to the start button would be nice but how often will that be necessary?

[melton-jason]

Nice work!

@melton-jason, a jump to the start button would be nice but how often will that be necessary?

Not that necessary. Not necessary enough to keep this from production.

[grantfitzsimmons]

Screen.Recording.2023-01-15.at.5.51.17.PM.mov

Unfortunately the first item I select after loading into the schema viewer is not properly highlighted.

[grantfitzsimmons]

Unfortunately the first item I select after loading into the schema viewer is not properly highlighted.

[maxpatiiuk]

Unfortunately the first item I select after loading into the schema viewer is not properly highlighted.

Can you elaborate on what you mean by this / provide a video?

It works for me, albeit very laggy:

Screen.Recording.2023-01-16.at.08.31.21.mov

[maxpatiiuk]

Running a profiler shows that the performance issue is caused just by the sheer number of elements on the page, rather than by react:

Thus, the only way to reduce this is to not render as many elements on the page. Solutions:

1. Allow temporary hiding hidden tables from the list
2. Add an alternative view that only displays several tables at once
3. Most satisfactory and most complicated: use a virtual rendering library that only actually renders a subset of the list on the screen. This would also require us to provide custom search functionality as Ctrl+F doesn't work when elements are not rendered on the screen.
4. Don't do anything and just accept the bad performance

[grantfitzsimmons]

Can you elaborate on what you mean by this / provide a video?

#2816 (comment)

[maxpatiiuk]

Can you elaborate on what you mean by this / provide a video?

#2816 (comment)

Sorry! I missed it

[grantfitzsimmons]

When I’m on a data entry form, Specify uses ~500-600MB of memory – the schema viewer takes 1GB and clicking on a button spikes to using 25-35% of my CPU

The schema print-out uses 100MB of memory and 0.6% of my CPU when I jump to a table

[maxpatiiuk]

yeah, it displays 41,000 cells so that's about what I would expect

the printout page is static and does not use react (in the schema viewer there is a react component for each cell, and they all take memory)

See #2816 (comment) for potential solutions

[grantfitzsimmons]

It is up to the team to decide if we should implement a new solution to make this work without consuming a lot of memory. I would argue that it is not often used or referenced, making it a low priority to optimize.

[maxpatiiuk]

Let's push this as is before it gets too big.
#1831 mentions 3 more improvements (which are smaller) and can be implemented in the future.

[maxpatiiuk]

👍

Edit: didn't know GitHub allows leaving reviews on merged pull requests. Neat!