Sort displayed features based on bookmark query

[KyleJu]

A follow-up for #764, sort the features in the overview page based on the bookmark query order.

• Given that the number of features should be < 20, the sorting is implemented on the frontend
• Again given the number, the algorithm for finding a feature is brute force
• Only support id and name at the moment
• If there are features missing after sorting, revert to the default order

[jcscottiii]

Thanks for this PR and I like the unit tests file you added.

One thing to note: You should rebase your code because you will need to set is_ordered on the newest query. Otherwise, CI for this PR will fail in the merge queue.

We need to handle this edge case:

• Given a user narrows their page down to only showing 10 results (via https://webstatus.dev/?num=10)
• They click on the bookmark
• They are navigated to https://webstatus.dev/?q=id%3Aanchor-positioning+OR+id%3Acontainer-queries+OR+id%3Ahas+OR+id%3Anesting+OR+id%3Aview-transitions+OR+id%3Asubgrid+OR+id%3Agrid+OR+name%3Ascrollbar+OR+id%3Ascroll-driven-animations+OR+id%3Ascope&num=10

That will render 10 items even though we should render 12. But the sorting will be incorrect because the backend only sends the first 10 according to its sorting logic.

We should have a way to reset the number of values loaded from the backend to a number that makes sense.

Easiest way to do that would be handle it during the rendering of the bookmark url

webstatus.dev/frontend/src/static/js/components/webstatus-sidebar-menu.ts

Lines 228 to 235 in 3acfef5

	renderBookmark(bookmark: Bookmark, index: number): TemplateResult {
	const bookmarkId = `bookmark${index}`;
	const currentLocation = this.getLocation();
	const currentURL = new URL(currentLocation.href);
	const bookmarkUrl = formatOverviewPageUrl(currentURL, {
	q: bookmark.query,
	start: 0,
	});

Additionally, when someone clicks on the CSS bookmark, we still indicate that the baseline column is being sorted. But that is not the case when using this custom sort.

We should also add a test that asserts that the actual bookmarks with is_ordered = true in DEFAULT_BOOKMARKS can work. The test queries in frontend/src/static/js/components/test/webstatus-overview-table.test.ts are good for getting the basic and edge cases but we should make sure that our actual CSS bookmark will work as expected. This can come as another unit test.

[KyleJu]

Thanks for this PR and I like the unit tests file you added.

One thing to note: You should rebase your code because you will need to set is_ordered on the newest query. Otherwise, CI for this PR will fail in the merge queue.

We need to handle this edge case:

• Given a user narrows their page down to only showing 10 results (via https://webstatus.dev/?num=10)
• They click on the bookmark
• They are navigated to https://webstatus.dev/?q=id%3Aanchor-positioning+OR+id%3Acontainer-queries+OR+id%3Ahas+OR+id%3Anesting+OR+id%3Aview-transitions+OR+id%3Asubgrid+OR+id%3Agrid+OR+name%3Ascrollbar+OR+id%3Ascroll-driven-animations+OR+id%3Ascope&num=10

That will render 10 items even though we should render 12. But the sorting will be incorrect because the backend only sends the first 10 according to its sorting logic.

We should have a way to reset the number of values loaded from the backend to a number that makes sense.

Easiest way to do that would be handle it during the rendering of the bookmark url

webstatus.dev/frontend/src/static/js/components/webstatus-sidebar-menu.ts

Lines 228 to 235 in 3acfef5

	renderBookmark(bookmark: Bookmark, index: number): TemplateResult {
	const bookmarkId = `bookmark${index}`;
	const currentLocation = this.getLocation();
	const currentURL = new URL(currentLocation.href);
	const bookmarkUrl = formatOverviewPageUrl(currentURL, {
	q: bookmark.query,
	start: 0,
	});

Additionally, when someone clicks on the CSS bookmark, we still indicate that the baseline column is being sorted. But that is not the case when using this custom sort.

We should also add a test that asserts that the actual bookmarks with is_ordered = true in DEFAULT_BOOKMARKS can work. The test queries in frontend/src/static/js/components/test/webstatus-overview-table.test.ts are good for getting the basic and edge cases but we should make sure that our actual CSS bookmark will work as expected. This can come as another unit test.

There are three things to address in this comment:

1. An edge case when the num param in present
2. UI indicator for sorting
3. A test case for real bookmark value.

Let me address the third item in this PR and send out a follow-up PR for the first two items, for the ease of review.

[KyleJu]

Note to myself: rebase my code before merge

[jcscottiii]

LGTM.

An addition to one of the future PRs: Move bookmark out of constants.ts and into its own bookmark.ts file in utils. With that, you either:

1. Move findFeaturesFromAtom and reorderByQueryTerms there as exported functions and leave Bookmark as an interface that also lives in the same bookmark.ts file.
2. Turn the bookmark interface into class and add findFeaturesFromAtom (private) and reorderByQueryTerms (exported) as methods in that class.

In either case, you will want to throw an error when the length does not match and then the code here will do the toast show.

This will keep this component strictly about rendering and any complex logic will be pulled out.

[KyleJu]

1. Move findFeaturesFromAtom and reorderByQueryTerms there as exported functions and leave Bookmark as an interface that also lives in the same bookmark.ts file.

Filed #1001 for this follow-up