Comments (13)
/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]
andhttps://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]
andhttps://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.
Related Issues (20)
- Implement search with Algolia HOT 5
- Move tests out of data directory
- Address pagespeed results. HOT 4
- Linkedin link broken. HOT 1
- Suggestion: add tag for documentation needs HOT 3
- Store and read data from a database instead of a JSON file HOT 12
- Let users register HOT 4
- Fix favicons HOT 3
- Search repos by multiple tags HOT 4
- Implement / fix user pages
- Enhancing Button Styles for an Attractive Look
- Add animation to SortPicker Component
- Fix the data/get.ts link in the README.md HOT 1
- Add an Issue template
- Update the "Your First Code Contribution" section of the README.md file HOT 1
- Update the "Improving The Documentation" section of the README.md file HOT 1
- Update the "Commit Messages" section of the README.md file
- Update the "Join The Project Team" section of the README.md file HOT 2
- Update all dependencies to the latest version HOT 3
- Check SEO
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from verto.