-
Notifications
You must be signed in to change notification settings - Fork 14
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
[Issue #2653] Sign in component #3281
base: feature/nextjs-auth
Are you sure you want to change the base?
Conversation
3d6abd3
to
dd80b68
Compare
@@ -44,6 +44,11 @@ locals { | |||
manage_method = "manual" | |||
secret_store_name = "/${var.app_name}/${var.environment}/api-auth-token" | |||
}, | |||
# URL for the API login route. | |||
AUTH_LOGIN_URL = { |
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 isn't secret so it goes next to the NODE_OPTIONS key above
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.
It is the same as the API_URL
right?
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.
@coilysiren Secrets knows how to read from SSM where as the standard env vars are more "constants?" Right? Or is there a way to read from SSM there too?
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.
frontend/src/components/Header.tsx
Outdated
const LoginLink = () => { | ||
return ( | ||
<Link | ||
href={process.env.auth_login_url as string} |
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 works with next dev
where the variable is defined in the env file, but won't work with build && start
when it's coming from SSM. The env var won't be available to the app until run time, and for a client component to pick up directly from process.env
the variable needs to be:
- prefixed with
NEXT_PUBLIC
and - available at build time
I'd recommend reading this in from process.env in the environments file, then prop drilling it down to the header component from the nearest server component. It may work to import directly from the environments file, but I doubt it.
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 wish local Next/React did a better job of highlighting/blocking this anti-pattern.
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.
@doug-s-nava b/c these pages are statically rendered, there isn't a server side place to put the env for the static pages, unless we use wrap them in a suspense boundary. @mdragon that isn't an anti-pattern, it is the rec from next documentation
That could be the way to go. As of this comment, the CDN is rendering the suspense on the search page without a loading state, meaning the header could potentially use suspense without a "flicker."
If we switch to dynamic rendering, then we could just use this pattern as is.
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.
Noting we resolved this, decided to use a route handler for the public client side envars for the time being then will remove that once we can use dynamic routing.
Also if we're not updating the button to a logged in state when user is logged in in this change I think we need a ticket to handle that |
5b3b8af
to
a28c443
Compare
@doug-s-nava this seemed like enough to chew on for a PR and the provider wasn't available when I started. I can do a follow-up for the same ticket now that the user provider is available. |
80f4046
to
99f501f
Compare
ec9bc75
to
9016bbc
Compare
a28c443
to
0179346
Compare
|
||
return ( | ||
<a | ||
{...passHref} |
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 is the easiest way I could think of to disable the login button while it fetches.
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.
And just to make sure I'm keeping all the different tickets straight, Doug has a separate ticket to hide this button behind a feature flag?
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.
yes
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.
what about moving the fetch and state management into this component, and implementing a loading state (which in this case would just hide the link, I guess?)
frontend/src/app/api/env/route.ts
Outdated
return Response.json({ | ||
api_url: environment.API_URL, | ||
auth_login_url: environment.AUTH_LOGIN_URL, | ||
node_env: environment.NODE_ENV, |
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 don't see this being consumed anywhere yet, but per the discussion on the other ticket, should this use the new ENVIRONMENT since NODE_ENV is just prod everywhere except localhost?
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 NODE_ENV
is different than the env we set per environment. I could remove this as it isn't being used.
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 removed it
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.
a couple of nits
SENDY_API_URL= | ||
SENDY_LIST_ID= | ||
|
||
API_URL=http://api.simpler.grants.gov |
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.
🎉
export const dynamic = "force-dynamic"; | ||
|
||
export function GET() { | ||
return Response.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 I misinterpreted the conversation yesterday - I thought that this route would be redirecting the request to the correct API endpoint, rather than returning the url. I know this is temporary so it's probably not a big deal, but that would save us a round trip, and then we can avoid the state management on the client. Does that raise the level complexity too much?
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'd like to keep the same pattern of getting the envar itself and pass to the component which is what we'll be moving to. The redirect also adds additional complexity for the UX, going back to get provide a proper error page etc. This seems like the easiest temporary solution.
frontend/src/components/Header.tsx
Outdated
/> | ||
</div> | ||
<div className="usa-nav__primary margin-top-0 margin-bottom-1 desktop:margin-bottom-5px text-no-wrap desktop:order-last margin-left-auto"> | ||
<div className="usa-nav__primary-item border-0"> | ||
<LoginLink auth_login_url={authLoginUrl} /> |
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.
can we commit to camelCase?
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.
Updated, thanks.
|
||
return ( | ||
<a | ||
{...passHref} |
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.
what about moving the fetch and state management into this component, and implementing a loading state (which in this case would just hide the link, I guess?)
@doug-s-nava want to avoid a loading state for every page request. this way the user just gets the link, and it isn't available if there is some server issue. |
Summary
Fixes #2653
Time to review: 5 mins
Changes proposed
Mobile
Figma
Local
Deskstop
Figma
Local