-
Notifications
You must be signed in to change notification settings - Fork 29
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
Add Panoptes auth to app-root #5459
Conversation
00d42df
to
b8f46f0
Compare
@mcbouslog might be a good person to review the code for notifications and messages. I copied it more-or-less straight from the project app. |
aeee0f3
to
c37ea0b
Compare
I think this is ready for review now. |
6bd43bf
to
feb3d61
Compare
3367e6e
to
4d68293
Compare
Here's a short recording when I have notifications. Screen.Recording.2023-10-18.at.09.38.28.mov |
fad9dbe
to
60748c2
Compare
60748c2
to
1a94a4e
Compare
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 think this is looking good! I'm able to load https://local.zooniverse.org:3000 and see my username signed-in in the ZooHeader. I added a note to the app-root project board to revisit unit tests for notifications, too.
I have a couple of "big picture" question for understanding:
-
This setup uses
useContext
rather than mobx like the older apps in FEM. All app-root components that haveuseContext
will re-render anytime PanoptesAuthContext changes (anything inadminMode
,user
, etc). I don't think that's a bad thing, but is this the same or different re-rendering behavior than using mobx? -
The user fetching functions
usePanoptesUser
andfetchPanoptesUser
look quite a bit different than the same-name functions in app-project. Is the decision to not useswr
directly in the hooks a more robust solution than how it's implemented in app-project?
@@ -0,0 +1,53 @@ | |||
if (process.env.NEWRELIC_LICENSE_KEY) { |
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.
Because this express server is only used for local development, do we need new relic? Just want to think through this server while we have the chance and consider the build bug from app-content-pages too: #5428
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 express server runs on yarn start
too, but we need to test that on Kubernetes.
Your comment reminds me that the live content pages app isn't logging to New Relic either.
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.
Right! I think that's what I'm getting at. The content pages app will probably never use a custom express server in deployment again, so New Relic should not be setup for app-root either. Thoughts?
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.
How do we debug slow pages and Postgres queries without New Relic?
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 mean, content pages should be using New Relic in production too. It should be imported when the Next app loads and starts, at the top of next.config.js
.
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.
Does the debugging via New Relic happen via logging from a production deploy, a local build, or both?
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.
🤔 app-project does have New Relic imported into next.config.js
but app-content-pages does not.
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.
Any environment that has NEWRELIC_LICENSE_KEY
set, according to the code. That’s production and staging deploys.
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.
Looks like they only have examples for the pages router.
https://github.com/newrelic-experimental/newrelic-nextjs-integration
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.
In addition to lack of New Relic + App Router documentation, I strongly suggest that New Relic isn't included in app-root (for now). We don't really know what deployment of this app will look like yet, and I'd prefer to setup logging tools that are used in staging + production envs when we get to that step. I've added it as a to-do in the project board.
Otherwise everything here is looking good!
|
||
const hostnames = { | ||
development: 'local.zooniverse.org', | ||
branch: 'fe-project-branch.preview.zooniverse.org', |
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.
branch: 'fe-project-branch.preview.zooniverse.org', |
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.
This change will crash when APP_ENV
is set to 'branch' but I'm not sure if that's a big deal.
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.
Is branch
included here in anticipation of doing a branch deploy with app-root?
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 think it’s just in all the server setups by default. The content pages app defines it too.
branch: 'fe-project-branch.preview.zooniverse.org', |
/* | ||
Null users crash the ZooHeader component. | ||
Set them to undefined for now. | ||
*/ |
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.
Suggestion to create a Github Issue for this so we can bug-fix in ZooHeader.
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 that it’s a bug in the header. The header has a default set for user
. However, default values are applied to undefined
props in React, not null props, and undefined
isn’t an allowed value in JSON.
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 think the default here should be null, not an empty object. Probably depends on what we expect user
to be when no one is logged in.
user = {}, |
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.
With Server Components, it might even be better to pass a promise that resolves to a user.
https://react.dev/reference/react/use#streaming-data-from-server-to-client
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.
Ah okay, I understand the need to set to undefined
now - thanks!
A couple of quick answers:
|
76f8e6c
to
3bf2629
Compare
I've rewritten Note that |
3bf2629
to
b6dacdd
Compare
2b3291d
to
750b884
Compare
New Relic should be loaded in before the app starts running, so at the top of If you look at the project app, you should see that Looking at the original PR (#926), there's a config file that needs to be added too. |
#1812 has some useful context for why we use custom servers, including links to the original issues. |
This is super helpful thank you! |
I also looked up the latest advice for using New Relic with Next, and it looks like it has changed since we originally set everything up. There's now |
You're right, though, that this won't be needed until we're running the new user pages on Kubernetes. It will be useful, then, to trace how long page builds take and to tune our JS code on the server. |
750b884
to
4e32691
Compare
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 think this PR is fine to merge, but wanted to check-in if any discussion on New Relic needs resolving? It looks like if merged as is, New Relic is setup in server.js
but not used until this app is deployed. At deploy, we'll need to revisit New Relic config if, for example, server.js
can't be used in a deployed version due to issues recently seen in app-content-pages.
None of our Next.js apps are using |
- add the Panoptes auth client, from `panoptes-client`. - add `usePanoptesUser` for SWR-style user fetching. - add an express server to handle HTTPS in local development. - add the panoptes user to both page header and footer.
- add `swr`. - `useUnreadMessages` fetches your unread message count with `useSWR`. - `useUnreadNotifications` fetchs your unread notifications count with `useSWR`.
- persist the current user in local storage. - check admin mode with `useAdminMode`. - add the admin mode toggle to the footer, and the admin mode border to the page.
Add `PageContextProvider`, responsible for: - global page styles. - providing the Zooniverse Grommet theme. - providing Panoptes auth context (user and admin mode.)
- move `fetchPanoptesUser` into a helper. - add explanatory comments. - restore the missing `avatar_src` when getting the user object from a JWT.
- use `useSWR` to fetch the user object from Panoptes. - persist the returned data in local storage. - reset the current Panoptes session when auth changes.
4e32691
to
b90779c
Compare
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.
This was somehow missed in review, but this commit "Add named page headers" added header elements to /about/page.js and /projects/page.js without a parent element. These two pages now throw an error during the app-root build process locally.
Fixed in #5551 |
panoptes-client
.useSWR
hook, from 'swr'.usePanoptesUser
for SWR-style user fetching.useUnreadMessages
) and unread notifications count (useUnreadNotifications
), once you've signed in.Please request review from
@zooniverse/frontend
team or an individual member of that team.Package
How to Review
Either
yarn dev
oryarn start
should run a local HTTPS server on https://local.zooniverse.org:3000.If you have a Panoptes session cookie for
local.zooniverse.org:3000
, you should be logged in when the page loads, and see your username top right.There's no sign-in form yet. If you aren't logged in, you'll need to log in to
local.zooniverse.org:3000
in another tab (eg. with the content pages app), in order to set the session cookie.Admin mode should toggle the top-level admin menu and page border, and persist across page loads.
Once you are logged in, the user object is persisted in local storage for faster sign-in across tabs.
Screen.Recording.2023-10-14.at.12.00.53.mov
Checklist
PR Creator - Please cater the checklist to fit the review needed for your code changes.
PR Reviewer - Use the checklist during your review. Each point should be checkmarked or discussed before PR approval.
General
yarn panic && yarn bootstrap
ordocker-compose up --build
and FEM works as expectedGeneral UX
Example Staging Project: i-fancy-cats
New Feature