Inefficient way of showing results in Sortinghat

[canasdiaz]

The Sortinghat UI is not efficient in the way the pages are displayed, maybe because it was designed to show all the pages with all the identities by default. From my point of view, the landing page should not show a single identity in the same way a search engine (like DuckDuckGo or Google) does not show results without requesting a search.

The main issue I found is that when looking for an identity, the search takes X seconds to display all the results in different pages. But if I change from page 1 to page 2, we have to wait for the same amount of time. For big foundations, this involves waiting for around 20 seconds for each petition.

From the usability point of view, and from the performance point of view, I don't see the point in showing all the pages with all the identities the dataset has. As an example, I'm visiting an instance with 700K identities right now. Showing on the landing page 70K pages does not make any sense.

[krishnasingh281]

Hi @canasdiaz!

I'm interested in picking this up as my first contribution. Right now the UI loading all identities by default feels pretty heavy at scale, and a search-first flow seems like it would make the page much faster and easier to use for large instances.

I've been setting this project up locally and was able to reproduce the slow loading when working with bigger datasets, so I have a decent picture of the problem.

I just wanted to ask, before diving in, which direction you'd prefer me to begin with:
• adjust the UI so that identities aren't fetched until the user searches, or

• Investigating the pagination behavior on the backend to understand where the time is being spent.

Quite happy to go down whichever route is more helpful.