Split front end into one page per category #1762
Conversation
- Present 'downloads', 'version', etc as pages - Don't show any badges on the index page, just links to categories. - Tweak search so we can search all badges from the index page, but without rendering every badge as soon as we press a key.
Merge the remains of 'miscellaneous' and 'longer miscellaneous' into a single 'Other' catgeory There is probably a bit more categorisation we can usefully do here, but I think this is a good start.
chris48s
added
frontend
Generated by 🚫 dangerJS |
| </tr> | ||
| ); | ||
| } | ||
| return null; |
There was a problem hiding this comment.
This makes the search more efficient because it only loads the badges matching our query (instead of hiding the ones that aren't relevant), but in isolation, this still background loads a load of badges when the user types one key (just because a lot of examples match the query), so elsewhere I've also restricted the search on the home page so that it only starts searching after the user enters 2 or more characters.
For the category-level search I haven't restricted it because we've already loaded all the badges in that category before we start searching.
resolve conflicts
pages/index.js
Outdated
| <div>Search term must have 2 or more characters</div> | ||
| ); | ||
| } else { | ||
| return(<BadgeExamples |
There was a problem hiding this comment.
Would it be worth adding a ~500ms delay here?
It may help reduce the amount of badges loaded.
something like:
var searchTimeout = 0;
...
clearTimeout(searchTimeout);
searchTimeout = setTimeout(runSearch, 500);
|
Deployed to heroku, Do you think it would also be useful to still have a way for people to view all the available badges? |
this will reduce the number of badges loaded while typing
Thanks. These are excellent sugestions - I've added both of them in 5351c4a and 5070f6d.
Hrm. This works locally for me. Does this reproduce if you check the code out locally? I'm not missing routing code because we are using My suspicion is that there may be a server restart or page build step missing from the end of the heroku deploy, but I'm not sure what the staging deploy script looks like.
I think rendering all badges on one page provides poor user experience as well as bad performance and it is an approach that just doesn't scale as we add more integrations. At the moment I'm 👎 on retaining a single "render all badges" page on balance, but I'm open to more feedback on the issue (esp from users as well as maintainers). What do you think is the main advantage of keeping it? |
Haven't had the chance to test it out locally yet, and not quite sure how heroku handles it all, but if it's working locally i'm sure we can sort it out on the server end.
Not sure really, mainly just to display all available services (not on initial load, separate page). |
I'm not sure how we could produce this with the data structure we've got right now. Currently we do have the ability to attach some number of arbitary 'keywords', but for the moment we don't have a reliable meta-property on the examples data structure that identifies a badge as belonging to a 'service'. This is actually one of the other things I was thinking about while I was re-organising this: At the moment we've chosen to organise this into a hierarchy of categories and examples, like this:
but another equally valid way to think of it would be:
One makes sense to some people and the other makes sense to others. It would be useful if we could support both. I think it would be beneficial to improve discoverability by re-organising the data structure so that its more like a flat structure with 'tags' (so a badge can appear under multiple headings) instead of a hierarchy. Then we could make more use of tags for browsing as well as searching. I think that is probably a larger chunk of work. It also probably needs a bit more thought about design. I'm not sure what the homepage would look like in that scenario once we've got a very large number of tags or headings. |
|
Yeah, that makes sense. For the front end maybe we could move it to a table? (possibly in another PR later)Group By Category:
Group By Service:
Or maybe something more like this: Group By Category:
Group By Service:
For this PR i guess it's best just to split the front end up, and work on the other parts later. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I think we still need a |
|
Woohoo, this is awesome! I'll take it for a spin sometime in the next few days. |
|
Sorted. Added the missing |
|
side note: I've moved |
|
When I click the sections at https://shields-staging-pr-1762.herokuapp.com/ I navigate to a page like https://shields-staging-pr-1762.herokuapp.com/examples/build which is an error page. Any idea what's causing that? |
No :( As noted in #1762 (comment) I don't know why this works locally but not on the staging server. I don't know enough about how the staging deploy is done to understand the difference/try and debug it. If you check this out locally, does it work for you on your local copy? |
|
Ah, I see… There's an overview of the problem here: https://github.com/zeit/next.js/wiki/Deploying-a-Next.js-app-into-GitHub-Pages And a solution here, though it's a bit messy, and also designed for react-router, not next's router: https://github.com/rafrex/react-github-pages And finally, a good discussion around a feature request: isaacs/github#408. I'm not sure where that leaves us. I don't want to invest in a solution for Next, since we're wanting to replace it. We could switch to Gatsby or CRA before addressing this, though it would create conflicts with this. Alternatively we could try to manage this on a single page using Added: Come to think of it, |
|
Cheers for the additional info. Before thinking about a solution, I'm confused about why we need to work around a limitation of GH Pages if we're deployed on Heroku (in staging) or a VPS (in prod). What's the additional bit of info I'm missing there? |
|
Ah, good question. In prod, the servers are on the VPS. That's the This is why The servers ( The Heroku and Zeit builds use a different mechanism to accomplish the same thing. The build script runs at deploy time, and creates a static copy of the build in |
|
OK. Having digested this, some thoughts.. Is there a way I can run the code locally so that it replicates the way it runs in staging - how can I reproduce this locally? The whole 'override the 404 page so it does a client side redirect' fudge is not a great solution. I'd like to avoid doing that. I think ideally I'd like a solution which allows us to give someone a link to the page listing all the version badges (or whatever). I've been assuming that this will take the form Considering this slightly more widely, it would be useful if we could support having more than one page on the site. For example, if you think about issue #1787 we might want to solve that by adding a page which shows all the named logos. In general this would be a useful problem to solve. It looks like this is going to be a problem with any front-end solution that uses a router so if we're looking to swap out next for something else, it is worth thinking about this issue in evaluating alternatives. |
I'm not sure you can get the exact behavior. You could run a plain HTTP server on the build, like
Agreed, it's bananas. If we stay with Github Pages, the hash is the way to go, probably something like If we want to keep the I don't know if there is a way to tell Next to use hash routing. I'd be surprised if there were… it's very opinionated. |
|
@chris48s What do you think about cherry-picking the category and badge-example changes into another PR? We could get that merged while we think about how to handle the rest. |
|
Yeah - that sounds like a good idea. Re-categorising the badges is useful even if we continue with the single-page layout and it is cumbersome to resolve merge conflicts on I'll have a look at splitting this into two smaller PRs tomorrow or Tuesday. |
|
Oh gosh, never say "resolve #1762". I didn't mean to close this. Sorry! |
Following on from conversation in #1700 I've split the site up into a number of smaller pages with fewer badges on each page.
There's 2 chunks of work going on here:
Mechanics:
Data:
Would be great to get some feedback on this.
Hopefully I don't end up resolving too many merge conflicts on
all-badge-examples.js🤞