I had stopped paying attention to `vercel.json`, because part of my intent is to perhaps move off Vercel, but right… we're still on there for now, and we still want our API functions to run!
Okay cool, this one worked! We use this special Chrome package with AWS Lambda support, and then we use normal Playright in dev, and then we exclude `playwright` from the deployment (even though it got auto-detected by `require("playwright")`) to just barely sneak in under the 50MB limit for this function. Phew!
The preview deploys for this seem to be, actually working? So that's exciting!
This is because it's the terminology I'm using elsewhere ("Items" and "Closet" are too overloaded in the UI), and because I want to start putting specific lists at like `/user/:userId/lists/:listId`!
I also create a redirect from the old URL, and also from the DTI Classic variant of the URL
I was accidentally serving images _without_ `updatedAt` with the long-term cache headers, but only in prod, not in dev
I think this is probably because I made a mistake in my Vercel route config, by including an `$updatedAt` parameter that doesn't actually exist in this case.
I'm guessing the Vercel dev server has different behavior for my mistake than the prod server. I'm guessing the dev server makes it an empty string, and the prod server makes it the literal string `$updatedAt`. Oops!
I hope this fixes it!
Gonna have the /outfit-urls page start returning these instead, for feature parity with before
I might change the strategy on this at some point, like have it get `updatedAt` and redirect instead of generating the image. But this is simpler for now (and the Vercel cache doesn't seem to be as aggressive as I want anyway), and I can change it later!
This is mostly for decoupling's sake: I want pretty outfit URLs that aren't dependent on the `/api/outfitImage` path structure, so that we can serve them as ~permanent pretty URLs that don't actually indicate where or how the image is stored.
Right, the routes are a bit confusing, `/outfits/new` matches `/outfits/:id`, but shouldn't.
I fix this at the routing level, by creating a more specific `/outfits/new` route that matches first, and just serves `index.html` right from the CDN.
To check that it's exact, I check for either a `?` or the end-of-string after `new`. That way, `/outfits/newish` correctly redirects to the SSR. (This doesn't actually matter a lot, because outfit IDs are only ever numbers and therefore can't start with "new"? But I figure, better to have an unambiguous semantic, then leave random things relying on outfit ID format assumptions.)
Meta tags are a bit tricky in apps built with `create-react-app`! While some bots like Google are able to render the full page when crawling, not all bots are. Most will just see the empty-ish index.html that would normally load up the application.
But we want outfit sharing to work! And be cool! And use our new outfit thumbnails!
In this change, we add a new server-side rendering API route to handle `/outfits/:id`.
It's very weak server-side rendering: it just loads index.html, and makes a few small tweaks inside the `<head>` tag. But it should be enough for sharing to work in clients that support the basics of Open Graph, which I think most major providers respect! (I know Twitter has their own tags, but it also respects the basics of OG, so let's see whether there's anything we end up _wanting_ to tweak or not!)
I've been getting more Sentry errors about JS chunk errors after deploys, and finally looked into it!
Turns out that, our try/catch handling was working great, and the page was reloading correctly for users as expected. But in these scenarios we would _also_ throw and log two uncaught errors!
The first is that, because we're a single-page app, unrecognized routes fall back to the index.html by default (to power our custom client-side routes, like /outfits/123 etc). So this meant that missing JS files, which _should_ be returning a 404, were instead returning 200 OK and an HTML file, which failed to parse. (And running the script isn't included in the catchable part of the `import` promise!)
Now, in our `vercel.json` config, we catch those paths specifically and 404 them. (The exact choice of path is important: on dev, all these routes run _before_ the dev server, which is responsible for serving the static files - but dev doesn't include hashes in the JS file names, so this 404 route only matches built prod JS files, not local dev JS files.)
The second is that we failed to return anything to `@loadable/component` in the error case, so it would try to render `undefined` as if it were a component class. Now, we return a trivial component class that returns null!
