Multiple filters at the same time about verto HOT 13 CLOSED

/language/all/tag/[tag] is perfect. Go ahead.

I'll try implementing it

from verto.

On a related note -

I noticed that once you select a language or tag, you can't deselect it unless you return to the homepage. You can change the tag or language you are filtering by, but you can't easily go back to the default behavior of viewing all repositories.

I think it would be nice if it worked like the sort by new/least stars/most stars buttons, where clicking a filter that was already selected returns it to the deselected state. You could also simply add a "Reset Filters" button if that makes more sense when multiple filters are possible.

from verto.

@lucavallin Maybe we can have the language and tag as URL path instead of a query string, https://firstissue.dev/language/JavaScript/tag/good+first+issue. This way the search engine can index them separately and we can have at least 2 filters at the same time. What do you think?

from verto.

/language/all/tag/[tag] is perfect. Go ahead.

from verto.

This was exactly my first thought too while using the site. I think the ability to apply multiple filters will be a great feature. I'll take a look and come up with implementation ideas.

from verto.

@arindampal-0 @dnafication Good feature idea. It would be nice to still have them as pages though, so that search engines can index them separately. If we only have filters in the query string, only the homepage will be indexed.

from verto.

@arindampal-0 That would work!

from verto.

@arindampal-0 That would work!

I'll try it out once, to see if it works or not

from verto.

Hi @arindampal-0 and @lucavallin

Creating a dynamic route like https://firstissue.dev/language/[language]/tag/[tag] would be a good idea, but the only potential issue is the build time. During the build time, Next.js will generate static pages for all possible combinations. Currently, we have 20 languages and close to 300 tags. It generates approximately ~320 pages at the moment, but if we add the dynamic route, it will generate 20 * 300 = 6000 pages. This will significantly increase both the build time and the size of the build. I'm unsure if this is a wise decision, and I'm open to suggestions.

My suggestion is to keep the current URL pattern the same, i.e., https://firstissue.dev/language/[language] and https://firstissue.dev/tag/[tag], and perform filtering on the client side. Search engines will still be able to crawl dedicated pages for languages and tags, and this approach won't increase the build time.

To make sharing easier, we can introduce query parameters to the URL. For example, https://firstissue.dev/language/[language]?tag=[tag] and https://firstissue.dev/tag/[tag]?language=[language]. This will simplify URL sharing and client-side filtering. Let me know what you guys think? I'll write a PR for my suggestion.

from verto.

Hi @arindampal-0 and @lucavallin

Creating a dynamic route like https://firstissue.dev/language/[language]/tag/[tag] would be a good idea, but the only potential issue is the build time. During the build time, Next.js will generate static pages for all possible combinations. Currently, we have 20 languages and close to 300 tags. It generates approximately ~320 pages at the moment, but if we add the dynamic route, it will generate 20 * 300 = 6000 pages. This will significantly increase both the build time and the size of the build. I'm unsure if this is a wise decision, and I'm open to suggestions.

This is definitely true, but the build step will not happen very often, so it might be alright to introduce /language/[language]/tag/[tag]. I may be wrong here if the build happens too often. @lucavallin can you comment on how often the build happens?

My suggestion is to keep the current URL pattern the same, i.e., https://firstissue.dev/language/[language] and https://firstissue.dev/tag/[tag], and perform filtering on the client side. Search engines will still be able to crawl dedicated pages for languages and tags, and this approach won't increase the build time.

To make sharing easier, we can introduce query parameters to the URL. For example, https://firstissue.dev/language/[language]?tag=[tag] and https://firstissue.dev/tag/[tag]?language=[language]. This will simplify URL sharing and client-side filtering. Let me know what you guys think? I'll write a PR for my suggestion.

I think this would create inconsistency, as the same button will lead to different routes, like for tag hacktoberfest, It'd had to go to /tag/hacktoberfest if no language was selected or else it would go to /language/[language]/?tag=hacktoberfest

from verto.

I like the /language/[language]/tag/[tag] approach, as long as /tag/[tag]/language/[language] works too, I guess?
The build happens 3x day, I am not particularly concerned about build times. Size of the build might be more of a concern, given it's a static site (for now).

from verto.

I like the /language/[language]/tag/[tag] approach, as long as /tag/[tag]/language/[language] works too, I guess? The build happens 3x day, I am not particularly concerned about build times. Size of the build might be more of a concern, given it's a static site (for now).

What I was thinking was only to keep /language/[language]/tag/[tag], and to accommodate only tags we can use /language/all/tag/[tag].

I'll try to implement /language/[language]/tag/[tag] normally and then let's see if optimization for size is possible.

from verto.

i will try to implement it

from verto.