Feature request: list of wallets filters saved in URL

[konopkja]

Is your feature request related to a problem? Please describe.

Our list of wallets offers a lot of filters to narrow down the huge list of products. Some users during user testing requested ability to send others a tailored filtered list view. This request has also appeared in user surveys further confirming potential need.

Currently we do not save switched on filters in URL.

Feature request:
Add filter parameters to URL so that the website and its users can link to a specific view of wallets. This can be used also in how to guides and other content on ethereum.org to improve UX.

Describe the solution you'd like

• Every triggered filter should be added as a parameter to URL so that we can link to the filtered view.

Describe alternatives you've considered

If too difficult, consider at least adding personas to URL

Additional context

No response

Would you like to work on this issue?

• Yes
• No

[bhargavkakadiya]

@konopkja I would like to take a crack at this one as well!

[konopkja]

Thank you so much! Assigned you the task.

[wackerow]

@konopkja This will likely result in lengthy URLs for this page. Did you want current filters to be always visible in the URL (in sync to the page)? Or do you just want the option for a link to load filters once and then hide the URL data, and another option to "copy filters" which will generate the longer URL?

Also a side note, we should just make sure to double check that having these query params doesn't affect any Matomo metrics by splitting data over "different pages"

[konopkja]

@konopkja This will likely result in lengthy URLs for this page. Did you want current filters to be always visible in the URL (in sync to the page)? Or do you just want the option for a link to load filters once and then hide the URL data, and another option to "copy filters" which will generate the longer URL?

Also a side note, we should just make sure to double check that having these query params doesn't affect any Matomo metrics by splitting data over "different pages"

long urls are not a concern for me, do not see any issue with that

matomo tracking - yes could that be prevented? @wackerow

[konopkja]

@bhargavkakadiya how is it going? need any assistance with this issue?

[wackerow]

@konopkja I can take a look into Matomo stuff... do our existing hash links (header links for example) cause any issues at the moment for you?

As for the long URLs... doesn't really bother me either, but I think if we added all the "false" booleans it would likely make the URL really awkwardly long to share. As long as we just leave those off (if not present, assume false) I think it would be just fine.

[bhargavkakadiya]

@wackerow @konopkja
I haven't really started on this yet, was onto multi select persona Issue. Will be looking at this now onwards
I will keep this in mind to include only true booleans in URL, and; is there any specific way/ standard we implement this ? Any example from the project would be great!
Thank You

[wackerow]

Might be worth peaking at the Simulator component (/src/components/Simulator/index.tsx):

  // Track pathID
  const pathId = getValidPathId(router.query.sim as string)

We do something similar here where the query param is actually what is being used to track the state, instead of useState (since the query param values will stick around on page re-paints/renders, similar to useState)

---

On an aside, put up #12842 which aims to fix any related issues with any Matomo logging and the use of query params.

[github-actions]

This issue is stale because it has been open 30 days with no activity.