Convert 'contact', 'team', and 'whoami' to app router; partially convert '404' [#134]

[genehack]

Description of proposed changes

This converts the global/shared layout and navigation bits, the /contact, /team, and /whoami pages (including login state display in that page and the global nav), and the general outline of the 404/not-found page over to using the App Router. The 404 page has been changed to provide a link to the root page, rather than loading the (as-yet-unported) <Splash> component.

This also required converting all styled-components usage in those parts over to either regular CSS, or to CSS Modules, depending on the scope of the usage. In general, I have tried to keep things scoped either very tightly (i.e., in specific CSS Modules imported into a single component) or put them in a global CSS file that is imported in the root layout.

I have elected to migrate components to /static-site/components as they are converted over for use with App Router; that felt like the cleanest option. I also elected to put page content directly into the app/*/pages.tsx files, rather than propagating the "page content is actually under static-site/src/pages/*.jsx" pattern, reasoning that this reduces the number of moving parts and makes it more clear where the content is relative to the the URL it is displayed at.

To be explicit: when this conversion work is done, I expect the contents of /static-site to be:

README.md
app/
components/
content/        ; maybe unify 
data/           ; these two?
next-env.d.ts
next.config.mjs
public/
static/         ; maybe unify with data?
tsconfig.json
types.d.ts
vendored/

Related issue(s)

#1052
#134

Checklist

• Checks pass
• Check if changes affect the resource index JSON revision

[tsibley]

Comparison via flicker:

[genehack]

Is that level of whitespace variation worth trying to nail down, IyourO?

[tsibley]

Maybe not? Though if I were doing the work I'd probably still try. It also might have more impact on mobile viewports? Would be good to check. The logo position change seems like it'll have more impact when navigating between a page like the contact page and an Auspice page.

[genehack]

Maybe not? Though if I were doing the work I'd probably still try.

Oh believe me, there has been some previous effort in this direction, I assure you.

On first blush, I think I would push further effort getting the header alignment perfect to after adding the login/user tracking bit, as I suspect some of the delta is due to that.

It also might have more impact on mobile viewports? Would be good to check. The logo position change seems like it'll have more impact when navigating between a page like the contact page and an Auspice page.

Yeah, fair; I haven't done a lot of checking around mobile viewport sizes.

[genehack]

BTW, what browser is this, and do you happen to remember the rough viewport size?

[genehack]

BTW, what browser is this, and do you happen to remember the rough viewport size?

@tsibley this was a question for you, about that comparison GIF — I'm having trouble reproducing some of the differences visible there with Firefox v131 on macOS.

[tsibley]

BTW, what browser is this, and do you happen to remember the rough viewport size?

Firefox 113.0.2 on Linux (specifically 113.0.2+build1-0ubuntu0.18.04.1) with a viewport that's as wide as you see in the full size image (minus the red border).

[joverlee521]

I really like the direction this is heading, thank you for simplifying the styling ❤️

[genehack]

If folks want to take another look at this, I've addressed the feedback about the basic layout (I think! 🤞 ) and also finished the /team page port.

Heroku seems to be having some deployment issues at the moment; when a review app finally builds, I'll link a preview.

Next stage: dealing with the user context.

[victorlin]

Reviewed all the contents of converted pages. Will continue reviewing styles next week.

[joverlee521]

I didn't look through the styling changes too closely but just compared the updated pages to prod. I like that the /whoami page's layout matches the rest of the site now 👍

I think the move away from styled-components should make it easier to remove UserContext/UserDataWrapper completely and just fetch the current user data server side.

[genehack]

(Not sure why I can't quote reply this one comment, but...)

My biggest concern is the lack of clarity around where the duplicates are.

I guess I don't see this as a huge issue, because when all this work is done, all the duplicates will be gone, as all the "old" components will be removed/replaced — more specifically, static-site/pages and static-site/src will no longer be present.

If the work is introducing multiple duplicates where there is currently only a single copy, I would consider that a bug/mis-implementation — but I don't think that's the case.

The only way to do this without having some transient duplication would be to convert the entire static-site directory at once, and even then, you'd have to decide between the equally unpalatable options of "have some commits where the site is broken" and "have some commits that are far too large and change multiple things at once due to shared component usage". Compared to those two options, I think having some duplication present in the tree in some commits is the least bad option.

[victorlin]

(Not sure why I can't quote reply this one comment, but...)

Oh I replied to an existing thread so you have to go back to the thread to add a comment. GitHub UI doesn't do a great job of showing this... copying back to the thread: #1032 (comment)