Site Switcher: Improve perceived performance by rendering 50 sites at a time, but include hidden sites

[danielbachhuber]

When a user has hundreds of sites, simply rendering all of the sites in <SiteSelector /> can be quite slow.

Fortunately, it's unlikely a user would scroll the entire list to find their site (they would search instead). As such, we can improve perceived performance by only displaying 50 sites at a time.

Additionally, with our 'Magic' sort mode default (#68173), we can remove the concept of 'Hidden' sites from the Site Switcher too.

It might make sense to coordinate this work with #68043.

Note that we are NOT paginating on the back-end, but rather just slicing the sites array directly in the front-end

From pdKhl6-GX-p2

Related https://github.com/Automattic/wp-calypso/issues/67580

Done is:

• If a user has more than 50 visible sites, only the first 50 sites are initially rendered.
• Searching continues to search across all sites, not just the 50 displayed sites. However, only the first 50 sites are displayed when searching too.
• If the user somehow ends up at the bottom of their 50 site list, they see a message that they can access all of their sites on the Sites page.
• The Site Selector continues to work as expected in /marketing/tools and other contexts.

[zaguiini]

This can be done in several ways:

Virtualizing

Use something like https://github.com/bvaughn/react-window https://virtuoso.dev to only render the items that fit in a specified height, essentially using a recycled list view (mobile developers are used to this concept).

The benefit is that it simplifies the implementation a bit as we don't need to slice the array and implement pagination at all. The downside is that virtualization is useless if we don't have height constraints (i.e. a sites page that displays only the sites list such as https://wordpress.com/marketing).

Load more button

Slice the array and include a "Load more" button at the bottom if there are more records. This would require pagination and the user actively clicking a button to see more, even though they are already scrolling and would definitely like to see more results.

Also, it would keep the previous records at the top, so if the user loads all items, they would face the exact same problem (degraded performance) unless the previous records are removed once more records are loaded.

This means we would need a "Load less" button at the top if the user wants to see "previous" records, effectively adding them back to the top of the list.

It could potentially be tricky to implement.

Infinite scrolling

Finally, the infinite scrolling solution is basically the same as the load more button one, with the difference being the absence of the button as the scroll-to-top/bottom intent alone is enough to load more or fewer records. This is as little bit trickier to implement as we would need to track the scroll position and fire the events accordingly, but then it's less effort for the user.

[danielbachhuber]

This can be done in several ways:

Give these options, maybe the easiest way is a simple "Previous | Next" pagination at the bottom of the list?

[wojtekn]

@danielbachhuber @zaguiini what do you think about making it simple, always displaying up to fifty records in Site Switcher and relying on the search or Sites Management Page to access the remaining sites?

[danielbachhuber]

what do you think about making it simple, always displaying up to fifty records in Site Switcher and relying on the search or Sites Management Page to access the remaining sites?

@wojtekn I'm open to it! I don't think we need a complex technical solution if we can solve it with some other UX.

[zaguiini]

@danielbachhuber @zaguiini what do you think about making it simple, always displaying up to fifty records in Site Switcher and relying on the search or Sites Management Page to access the remaining sites?

Works for me 👍 I think we need a copy saying that the results displayed are just a subset and if the user wants to see the whole list, please open SMD.

[danielbachhuber]

Great! I've updated the issue description accordingly.