Use links instead of buttons for header search type switcher

[obulat]

Fixes

Fixes #1130 by @obulat

Note: This PR works for adding links that retain common filter query parameters, but for correctly handling the search type specific query parameters it is dependent on #1040 (it needs an action that is only available in that PR). Since these two PRs are interdependent, it is best to approve and merge them together, or add TODO into another PR once one of them is merged.

Description

This PR makes the search type switcher use VLink when used in the header, and keep the current button status when used in the homepage searchbar.
This makes the header links more semantic (and also sets the aria-current="page" for the link to currently selected search type), and simplifies the search type handling.
It also fixes the e2e tests that are failing in #1040, and are currently disabled.

Testing Instructions

Run the app using pnpm dev, search for something from the homepage.

Switching search type from the homepage search bar should work as usual, and should not redirect to another page, because it's not using an <a> link.

Selecting a search type from the header should redirect you, as usual, and update the url path. You can see in the devtools that the search type switcher is using <a> links.

Currently, the link will only retain the filter query parameters that are common for all search types (license, license types, search by creator).
After the search store change is merged, You should also see that the query in those links retains the filter parameters that that type can use, and removes the parameters that are not appropriate. For example, if on the image page you check the 'jpg' file type filter and 'cc0' license filter, the link to 'all_content' type should only contain 'cc0' in the parameter, and discard the 'jpg' parameter.

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[zackkrida]

Like I mentioned earlier, I think a name that indicates the internal component behavior is better than one that refers to the external context. placement might be better as useLinks or some better name.

[zackkrida]

This works really well! I made some optional suggestions to code style but otherwise lgtm.

[sarayourfriend]

LGTM!

I wrote a comment last week and then forgot to submit this review, sorry! Zack mentioned something similar and probably better, just using a specific prop name instead of something contextual! Easier to test in Storybook that way as well 🙂 Kudos Zack!

[sarayourfriend]

This props like these I always wonder whether continue to drill them down or switching to using provide/inject would make more sense. I guess this is probably easier to test. It also crosses my mind "at what point does one decide to turn the enum into a boolean" in this case. For example, why pass the boolean here instead of passing placement directly which can then be evaluated by the component?

I don't have good answers for these though 😛

[obulat]

Thank you for this comment, @sarayourfriend ! I have also thought about replacing props drilling with provide/inject, but decided against it for one single prop.