-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Badge pages #4389
base: develop
Are you sure you want to change the base?
Badge pages #4389
Conversation
this is the backend needed to support pages to view all the users with a particular badge (i.e. who are all the founders, board members, strong verified people, etc.)
Yes I think that's right. If you are down, pagination would be great! |
Some badges could soon have thousands of users
Currently the workflow for using the local backend with the local frontend is to replace `.env.development` with `.env.localdev` which modifies the git working tree before running `yarn start`. Naturally this must be undone when you commit, which is generally not good development practice and also confusing that this would be necessary if a script that specifies the right environment config file could be used instead. There is an [unfortunate shortcoming](vercel/next.js#25764) in NextJS for environment management, which is that ["non-standard" NODE_ENV](https://nextjs.org/docs/messages/non-standard-node-env) variables are not supported due to possible side effects. Because of this, and the fact that the NODE_ENV is determined from the NextJS command that is run, you cannot actually tell `yarn dev` to use a different environment file than `.env.development` (this must be used!). Fortunately, there is an [environment variable load order](https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables) which we take advantage of here to inject the `.env.localdev` variables before the `.env.development` ones (both files are loaded, but `localdev` ones come first). It's a straightforward workaround, but many wish it didn't have to be this way. I preferred this solution over installing some dependency that isn't really necessary, especially because it follows a NextJS standard.
consolidated hooks for the badges feature
I thought having a clickable chip with a tooltip is a common scenario we might want to make use of later, so I extracted this functionality originally built out in the features/profile/view/Badges file into a ToolChipLink component. The Badge component is then just a wrapper around that where you pass in a Badge resource. This uses a URL scheme for badges at /badges/{id}
These are better user-facing descriptions of the available badges
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The backend looks great to me! I haven't been able to run the frontend locally (my working directory is a mess with the notify v2 stuff). But happy to merge once it passes all the tests, or we can look for someone from frontend to have a quick look as well!
@@ -0,0 +1,44 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how we should go about localizing these. I guess doing this is not a bad idea. Then if we come up with a better way, we can always copy these translations over!
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Designed to look the same as the index page
also added some better styling to the instructions text on the index page
@schradert are you still working on this or is it okay if someone else takes it over? |
Feel free to reassign anything assigned to me @nabramow |
Closes #4318
Backend checklist
autoflake --exclude src/proto -r -i --remove-all-unused-imports src && isort . && black .
inapp/backend
develop
if necessary for linear migration historyWeb frontend checklist
make format
make lint