Sites dashboard - remove default filter and dummy column hack

[Addison-Stavlo]

Related to # #93815

Proposed Changes

• Removes the default filter of "all sites" when loading the dashboard. Instead it loads with no filters selected unless the query params are present.
• Removes the dummy column we used for filtering by status. This was originally added due to design input to hide the filtering dropdown in the status column header, which has since changed significantly with the upgraded version of dataViews.

(more 🟥 than 🟩 , 🥳 )

BEFORE: When the page is loaded the 'all sites' filter is active, even after reloaded after resetting the filters.

AFTER: The page loads with no filters applied if there are no filter is set (such as through url query params).

The above shows a standard filter - when the page is loaded, the filter bar is empty. The user must select to add the filter from the status column header or from the filter icon next to the search input. Once cleared, the filter bar disappears.

We also have the option to use a primary filter, but this seems less fitting (below). In this case, when the page is loaded the filter bar is present with the 'status' item regardless of there being no filter set. Clearing filters does not remove this and it is always present:

(currently not used for this PR)

Why are these changes being made?

• Its confusing and redundant that the filter is shown active when nothing is being filtered out.
• There is no longer a need for the dummy column hack.

Testing Instructions

• Run this PR.
• Go to the sites dashboard with no query params.
• There should be no filter set.
• Test applying filters for the 'status' column, verify they work as expected in the list and add a query param to the URL.
• Reload with a filter set (query param in url), verify the state does not change.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-118475

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-118475&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-118475&env=a8c-for-agencies

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~46 bytes removed 📉 [gzipped])

name                parsed_size           gzip_size
staging-site             -226 B  (-0.0%)      -46 B  (-0.0%)
sites-dashboard          -226 B  (-0.0%)      -46 B  (-0.0%)
site-monitoring          -226 B  (-0.0%)      -46 B  (-0.0%)
site-logs                -226 B  (-0.0%)      -46 B  (-0.0%)
hosting-features         -226 B  (-0.0%)      -46 B  (-0.0%)
hosting                  -226 B  (-0.0%)      -46 B  (-0.0%)
github-deployments       -226 B  (-0.0%)      -46 B  (-0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[DustyReagan]

It's working as advertised!