-
Notifications
You must be signed in to change notification settings - Fork 25
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
Upgrade the public app to Next v10 and new architectural patterns #1087
Conversation
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.
@jaredcwhite just a few comments, more quality improvements than nextjs update, overall looks good! 👍
es: spanishTranslations, | ||
zh: chineseTranslations, | ||
vi: vietnameseTranslations, | ||
} as Record<string, any> |
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.
Here we can use language enum as a type.
@@ -24,7 +24,9 @@ const LanguageNav = ({ items }: LanguageNavProps) => { | |||
{items?.map((item) => ( | |||
<li | |||
key={item.prefix} | |||
onClick={() => changeLanguage(item.prefix)} | |||
onClick={() => { | |||
void router.push(router.asPath, router.asPath, { locale: item.prefix || "en" }) |
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.
Also, language enum would be helpful :)
Thanks @dominikx96 for the feedback. I'm a little fuzzy on what we would use a language enum for. The keys are coming from the Next.js config which comes from an ENV var, and any deployment with different vars would need code changed manually. Can you explain your thinking further? Thanks! |
I just realized I totally forgot to update the listings page! On it… |
Also need to refactor out the use of the |
So…this is most definitely going to be a breaking change 🚨 to ui-components, requiring an update of all Next apps. Not a problem per se, but we'd obviously need to be aware for the housingbayarea branches. A package version bump there will need the whole Next v10.1 upgrade migrated over. |
ui-components is now website framework-agnostic
@@ -1,8 +1,9 @@ | |||
import React from "react" | |||
import Head from "next/head" | |||
import { MetaTags, PageHeader, SiteAlert, t } from "@bloom-housing/ui-components" |
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.
Why was MetaTags removed from ui-components?
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.
MetaTags was using the next/head
dependency, so in order to remove Next from the component package we'll need to handle anything in the HTML <head>
through Next in the site folders.
@@ -205,13 +205,12 @@ export default class ApplicationConductor { | |||
} | |||
|
|||
routeTo(url: string) { | |||
void Router.push(url).then(() => window.scrollTo(0, 0)) |
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 was the point of the scrollTo logic before?
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 was going to a new page but not scrolling up to the top of the page by default. But in Next v10 they added that functionality automatically (sort of bonkers it wasn't there from the get-go).
sassLoaderOptions: { | ||
additionalData: tailwindVars, | ||
}, | ||
// exportPathMap adapted from https://github.com/zeit/next.js/blob/canary/examples/with-static-export/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.
Is all of this automatically generated 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.
Yep, that's the beauty of the updated system. No routing information needed in the config file whatsoever! 🤩
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.
@jaredcwhite will we be able to hide
routes that we don't want live yet?
<LocalizedLink href="/listings" className="navbar-item"> | ||
{t("nav.listings")} | ||
</LocalizedLink> | ||
<Link href="/listings"> |
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.
Feels a little weird to see a with a href
wrapping an a
tag without one, but I don't necessarily have a suggestion
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.
That's just how Next's link component works — although because I had to add a special LinkComponent
wrapper for pushing into the NavigationContext
for the components layer, it's possible we might decide to use LinkComponent
ourselves too. But that'd be a "non-standard" pattern as far as Next is concerned.
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.
Here's the doc for reference: https://nextjs.org/docs/api-reference/next/link, though it doesn't seem like it's necessary since it's not done below on lines 74 and 75.
Could you provide some additional context in the PR description / an overview of what was done here? |
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.
Hey @jaredcwhite ,
Again, this looks good overall. Added a couple more comments, for things we may want to do in the future.
return nowTime > moment(listing.applicationDueDate) | ||
}) | ||
} catch (error) { | ||
console.error(error) |
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.
Here's another general question that I don't think we want to solve here (if there's anything to change). Can we incorporate an error boundary, so that we don't have to have these individual try catches, and we can let errors bubble up to a single handler? That would help with logging in general.
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.
Yeah, I feel like there could be (and should be, if not already) some kind of best practice Next recommends for handling errors across an application. I'll look into it further.
</ListingDetails> | ||
</article> | ||
) | ||
} |
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 feels like it could be broken up into smaller components to be used by this. Not saying we need to do that now, there's just a lot going on in this file.
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.
Agreed.
@jaredcwhite when I tried to open one of existing listings I see an error: |
@dominikx96 Hmm, as far as I can tell there's no case where the |
@jaredcwhite I removed node_modules, re-installed and checked again, works as expected! 👍 |
* Updated next packages * Updated next config file * Refactored application entry point and created translation file * Updated pages structure to use dynamic next ID * Added LinkComponent and updated _app component * Updated internal links to the partners pages * Updated hh-member form to show address fields only if they are defined * Cleanup * Added unique useSWR keys * Updated keys to use endpoint naming Co-authored-by: dominikx96 <[email protected]>
@jaredcwhite , @dominikx96 and @software-project , is there any reason why the translation header patch #1244 can't be started with a branch of this after the merge conflicts are addressed? |
@seanmalbert Yeah I'm not planning to enhance any additional functionality at this point, just trying to this PR to feature parity with master so it's mergeable. |
Going to work through the testing issues now. |
Deploy Preview for clever-edison-cd22c1 ready! Built with commit 3abd0dc https://deploy-preview-1087--clever-edison-cd22c1.netlify.app |
All right – other than a couple of failing CircleCI tests which seem to be related to frontend/backend API connection (not sure how to resolve), we seem to be in good shape! Both public and partners building on Netlify, ui-components tests pass. |
@jaredcwhite I noticed this issue few times using commands from the main |
} | ||
// Legacy use only, deprecated | ||
const LocalizedLink = (props: PropsWithChildren<LinkProps>) => { | ||
const { LinkComponent } = useContext(NavigationContext) |
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.
Very nice :)
@seanmalbert and I tried to iterate a bit on why Cypress is failing on CircleCI. Sean verified he's able to get all the tests to pass locally. I suspect at this point it has something to do with the backend not being loaded yet when the |
Part of the work for #1081
Cypress test issue on CircleCI: see #1087 (comment)