Commit graph

5 commits

Author SHA1 Message Date
c5bd2695f6 A bit of SSR for the item page
Always been a bit annoyed to have even the item name load in so weird and slow 😅 this fixes it to come in much faster!

This also allows us to SSR the item name in the page title, since we've put it in the GraphQL cache at SSR time!
2022-09-15 03:05:14 -07:00
750ca208f1 [WIP] Migrate item trade pages to Next.js routing
One little tricky thing here was moving the `[itemId].tsx` page into the folder as `index.tsx`! Because we didn't have subpages before but now we do!
2022-09-14 22:56:45 -07:00
17a7e2de81 [WIP] Refactor to renderWithLayout function
Okay, when I saw the recipe in the Next.js docs with `getLayout`, I was like "psh this API is so confusing, this should just be a component"

anyway now we see why it wasn't a component: the _whole point_ of it was to circumvent the usual React diffing algorithm's belief that two different components _can't_ ever share UI. But here we were, making different `layoutComponent`s that were meant to share UI, lol!

Anyway, if you just _return JSX in a function_, the React diffing algorithm never sees that it came from a different place, so it's generous when diffing them. Neat!

But I still changed the recipe's `getLayout` name to `renderWithLayout`, because it just confused me so much at first lol, I thought it was going to like, return a layout function? This is much clearer verbing to me imo
2022-09-14 22:50:56 -07:00
f1cfd1ac8f [WIP] Migrate /items/search to Next.js routing
Okay I actually screwed up the layouts thing a bit! Because right, they need to *share* a LayoutComponent in order to share the UI across the pages. This gets a bit tricky with wanting to change the margin, too. I'll address this with an upcoming refactor!
2022-09-14 22:44:48 -07:00
43ae248e87 Migrate /items/[itemId] to Next routing
The tricky part here was that `returnPartialData` seems to behave differently during SSR. On the page itself, this seems to cause us to always get back at least an empty object, but in SSR we can sometimes get null—which means that a LOT of code that expects the item object to exist while in loading state gets thrown off.

To keep this situation maximally clear, I added a bunch of null handling with `?.` to `ItemPageLayout`. An alternative would have been to check for null and put in an empty object if not, but this feels more resilient and more true to the situation.

The search bar here is a bit tricky, but is pretty straightforwardly adapted from how we did the layouts in App.js. Fingers crossed that it works as smoothly as expected when the search page is migrated too! (Right now typing in there is all messy because it hops over to the fallback route and does its whole separate thing.)
2022-09-14 22:26:59 -07:00