Commit graph

1523 commits

Author SHA1 Message Date
4af2719098 [WIP] Use Next.js for outfit page SSR
Hey cool, we can use this API now! I prefer this a lot to my (granted, very cool) HTML injection hacks lol
2021-11-01 23:03:19 -07:00
5b0919f23b [WIP] Use nice outfit image paths 2021-11-01 22:42:23 -07:00
52526c09e8 [WIP] Move redirects to Next config 2021-11-01 22:33:23 -07:00
8dab442929 [WIP] API routes working for Next.js
Things seemed to mostly work at first glance! I haven't tested outfitPageSSR because we'll need to redo it though, and also the outfit image routes aren't working anymore (vercel.json isn't how next.js works)
2021-11-01 22:25:43 -07:00
589c48beda [WIP] Fix eslint for Next.js
Tweaked some of the default Next.js rules, fixed lint-staged for `next lint`, made a few small easy lint fixes. Feels good!

Note that using the `dirs` option in `next.config.js` was causing `lint-staged` to lint _everything_. That's why I edited `yarn lint` to specify the dirs instead: that way, that command will lint all those dirs, but they won't get included in invocations with `--file`.

There are still a few lint errors left after this commit, because our <img> tags aren't working (@next/next/no-img-element). I'll fix those when we figure out what's wrong with images!
2021-11-01 22:07:46 -07:00
567e333f9e [WIP] Run cra-to-next codemod to be on Nextjs
I'm interested in ejecting from Vercel, so I'm trying to get off their proprietary-ish create-react-app + Vercel API thing, and onto Nextjs, which is very similar in shape, but more portable.

I had to disable `craCompat` in `next.config.js` to stop us from crashing on their webpack config, see https://github.com/vercel/next.js/discussions/25858#discussioncomment-1573822

The frontend seems to work at a basic level, but network requests fail, and images don't seem to be working. I'll work on those next!

Note that this commit was forced through despite failing lint checks. We'll need to fix that up too!

Also, after the codemod, I moved `src/pages` to the more canonical location `pages`. Lint tooling seemed surprised to not find a `pages` directory, and I didn't see a config that was making it work correctly in the other location, so I figured it's that Next is willing to check `pages` or `src/pages`? But this is more canonical so yeah!
2021-11-01 21:49:23 -07:00
12d525e3ab Preload next/prev user outfits page
Even in production, scrolling is a bit slow! This will preload the pagination one click ahead.

There is a bit of a perf downside, in that if you click through the pages too fast, you'll trigger _extra_ requests. I think that's a net win though, and I'm not gonna try to get cleverer than this right now.
2021-11-01 19:50:21 -07:00
299561d1e3 Paginate the user outfits page
My main inspiration for doing this is actually our potentially-huge upcoming Vercel bill lol

From inspecting my Honeycomb dashboard, it looks like the main offender for backend CPU time usage is outfit images. And it looks like they come in big spikes, of lots of low usage and then suddenly 1,000 requests in one minute.

My suspicion is that this is from users with many saved outfits loading their outfit page, which previously would show all of them at once.

We do have `loading="lazy"` set, but not all browsers support that yet, and I've had trouble pinning down the exact behavior anyway!

Anyway, paginating makes for a better experience for those huge-list users anyway. We've been meaning to do it, so here we go!

My hope is that this drastically decreases backend CPU hours immediately 🤞 If not, we'll need to investigate in more detail where these outfit image requests are actually coming from!

Note that I added the pagination to the existing `outfits` GraphQL endpoint, rather than creating a new one. I felt comfortable doing this because it requires login anyway, so I'm confident that other clients aren't using it; and because, while this kind of thing often creates a risk of problems with frontend and backend code getting out of sync, I think someone running old frontend code will just see only their first 30 outfits (but no pagination toolbar), and get confused and refresh the page, at which point they'll see all of them. (And I actually _prefer_ that slightly confusing UX, to avoid getting more giant spikes of outfit image requests, lol :p)
2021-11-01 19:33:40 -07:00
33740af5ee Stop passing null value in SpeciesColorPicker
This is a minor change to clear a console warning, and make intended behavior clearer! You're not supposed to pass `null` as a select value, because it's ambiguous about whether you're looking for the first option or to make this an "uncontrolled component".

Here, I now provide a fallback value, which is an explicit string for the placeholder option. I made the string very explicit, to aid in debugging if it somehow leaks out from where it's supposed to be! (But I also added gating in the `onChange` event, just to be extra sure.)
2021-11-01 16:19:17 -07:00
21096ef837 Remove incorrect flexAlign prop
Huh. `flexAlign` isn't a real Chakra style prop, because it's not a real CSS style. I wonder if I meant `alignItems`? Anyway, this was getting passed down to the DOM element and triggering a console warning. Removed!
2021-11-01 16:09:56 -07:00
6ce0f59894 Remove stray onChangeHasAnimations prop
This isn't used, so it was getting passed down to the underlying DOM element and triggering a console warning! Remove it.
2021-11-01 16:09:09 -07:00
e4567d04bf Stop requesting bad outfit thumbnails in wardrobe
Oops, our cutesy feature to show an outfit thumbnail sa a placeholder while the rest of the data is loading was making spurious requests!

I put the `skip` in the wrong place 😅

This caused a request to https://outfits.openneo-assets.net/outfits/null/v/NaN/300.png, which would return a 500.

The user wouldn't see anything, because the image wouldn't show because it failed. But it's a mistake, and it's sending extra requests from the client and to the server, and it's a good one to fix!
2021-11-01 16:05:13 -07:00
086ada40f1 Polyfill Promise.any
Resolves Sentry issue IMPRESS-2020-7T
2021-11-01 16:01:05 -07:00
2fb84b0b0f Better handle editUsername when Auth0 update fails
Hmm, right, okay, we *generally* should have all users imported to Auth0, but this can fail if the cron job is behind or Auth0 rejected the data (e.g. user data in a format it doesn't support).

Previously, this would apply the name change in the database, but return Auth0's "The user does not exist." error to the GraphQL client, making it look like the update fully failed.

In this change, we handle that case differently: when the Auth0 update fails with a 404, we proceed but log a warning; and when Auth0 fails with an unexpected error, we roll back the database change in addition to raising the error to the client, to keep the behavior obvious and consistent.
2021-10-21 12:17:12 -07:00
b5865bf699 Fix email search redirect
Oh oops, I missed this path change when I changed the route to `/user/:id/lists`! This caused searching by email to redirect to the homepage, but with a valid URL in the address bar; and refreshing the page would hit the redirect defined in `vercel.json`, redirect to the new route, and load the correct page.

Fixed!
2021-10-21 11:56:55 -07:00
eb2eb241ba Use the first Auth0 connection instead of prompt
Oh right, we have another prompt we need to not prompt for, lol :p

Here, I just assume that there's one database connection on the Auth0 account. If that's not true, the script will error—not because this is a fundamentally unresolvable problem, but because I don't want to write code for configuring a situation that doesn't exist yet :p
2021-10-02 01:01:29 -07:00
357061221f Use env vars for MySQL in export-users-to-auth0
Huh, oops, there are a _few_ reasons the user sync cron job hasn't been running correctly.

I fixed some of the config in prod, but then discovered one more issue: the script prompts for an admin database password, so of _course_ it can't auto-run, lol.

Instead, I've now created a `impress2020-util` account, with just a few permissions (but specifically the `openneo_id.users` permission that I _don't_ give the app!), and added the username and password to the secret .env file, both locally and in prod. (In this case, prod means the Linode VPS, not Vercel, because that's where our cron runs.)
2021-10-02 00:57:39 -07:00
9b856a40b8 Sort /support/petAppearances from newest to oldest 2021-10-01 04:22:53 -07:00
4d4bc289df Update homepage Sep 30 2021-09-30 20:05:56 -07:00
0a5d8f1f74 Add search toolbar to item page
Trickier than it looks, to get the shared UI across pages without disrupting things like focus!
2021-09-30 20:04:50 -07:00
d6654b704b Search icon on homepage is now a link
Like, the little magnifying glass in the "Search all items", you can click it to get taken to the _big_ search page with the autocomplete filters and stuff
2021-09-30 19:31:51 -07:00
6efd542f49 Wire up the Remove button for item lists
Did some stuff in here for parsing the default list ID too. We skipped that when making the new list index page, but now maybe you could reasonably link to the default list? 🤔 not sure it's a huge deal though
2021-09-30 19:26:09 -07:00
b6b99d899f Update @apollo/client
I was hoping this would fix a cache merge ambiguity, but nope :p but hey, good to be on latest!
2021-09-30 18:37:09 -07:00
64db3dd1b7 [WIP] UI for item remove button
It's code for a remove button in item lists! When you click it, you see a "TODO" alert.

Not shipping this change until it's wired up!
2021-09-30 18:12:31 -07:00
818a443dfe Delete /outfit-urls page
We didn't end up using this, we found a way to decrease AWS costs without requiring people to migrate!
2021-09-30 17:32:25 -07:00
2bd573690e Add underline to item list description links
Oops, right, a bit of a CSS oversight! Added now!
2021-09-06 14:08:43 -07:00
315744b4f7 Allow pre tag in lists
I noticed someone using `<pre>` for styling, and thought, sure why not!

I haven't added support for the code block indent thing, and I think that's probably fine?
2021-09-06 14:07:05 -07:00
cc9cd5ef28 Rewrite old closet links to use new syntax
A lot of DTI lists use old URLs to anchor-link between lists! Here, we rewrite those URLs to match what DTI 2020 expects, so that they actually correctly jump you across the page and aren't filtered out!
2021-09-06 14:05:36 -07:00
dfcd9985d4 Await closing Playwright before finish request
I noticed when loading Your Outfits earlier (before I switched it to just use prod images even on dev), that there was a big memory leak slowing down my machine.

My hypothesis is that this is because I wasn't _waiting_ for the resources to tear down before finishing the request, so Vercel terminated the request early, and I further hypothesize that terminating a Playwright session partway through isn't guaranteed to clean up the browser.

Not sure about that! Could have just been that we spun up a lot at once, and a bunch of things went into swap! (But I thought it generally handles requests in serial in the dev server? So that feels unlikely.)

Anyway, I don't feel like extensively testing this again and maybe messing up my computer session again :p Just, when I first wrote this without awaits, I knew that it was a bit risky, but I wanted to _see_ if it was a problem before slowing down individual requests by awaiting. And now, my "it's likely to be a problem" threshold has been reached, lol!

So, I'm not _confident_ this is the best play, I don't know the internals well enough; but it seems like a better side to err on than the other, now that I know more!
2021-09-03 15:43:27 -07:00
9a68bd1355 Use standard image URLs on Your Outfits page
The old URLs were glitchy because we weren't escaping the `layerUrls` param… and this will let us take better advantage of the same shared caching as other stuff!
2021-09-03 15:37:38 -07:00
ae6b012f88 Fail harder when *all* layers fail to load
This was actually being _triggered_ by the fact that the user outfits page doesn't generate great outfit image URLs! It doesn't encode the layerUrls parameter, so now that image URLs sometimes contain `&`, the parameter was being misparsed.

Example:
```
http://localhost:3000/api/outfitImage?size=300&layerUrls=https://impress-2020.openneo.net/api/assetImage?libraryUrl=https%3A%2F%2Fimages.neopets.com%2Fcp%2Fitems%2Fdata%2F000%2F000%2F054%2F54348_cf1cfe10c7%2Fall-background.js&size=300,http://images.neopets.com/cp/bio/data/000/000/041/41572_0450defb29/41572.svg,http://images.neopets.com/cp/bio/data/000/000/041/41570_83582a4a83/41570.svg,http://images.neopets.com/cp/bio/data/000/000/041/41571_7e6c072e12/41571.svg,http://images.neopets.com/cp/bio/data/000/000/041/41582_06159c1e4d/41582.svg,http://images.neopets.com/cp/bio/data/000/000/041/41574_520e661a8a/41574.svg,http://images.neopets.com/cp/bio/data/000/000/041/41573_f4f480ba37/41573.svg,https://impress-asset-images.openneo.net/object/000/000/480/480378/300x300.png?v2-1597211608000
```

would get the following list of layer URLs:
```
["https://impress-2020.openneo.net/api/assetImage?libraryUrl=https://images.neopets.com/cp/items/data/000/000/054/54348_cf1cfe10c7/all-background.js"]
```

Anyway, I'm gonna fix that (probably by just not using this layerUrls param anymore and moving to the new outfit ID + timestamp URLs), but let's also just have clearer error messages instead of just a blank image! That way, if something similar happens again, the client will fall back to alt text, instead of showing a blank image.
2021-09-03 14:55:50 -07:00
42628dffab Merge branch 'main' of https://github.com/matchu/impress-2020 into main 2021-09-03 13:45:04 -07:00
443cf3fc26 Close extra browser instances too
I'm seeing a lot of 500 "Could not load image: undefined" lately, not sure why! Wondering if it's resources staying open too long, idk. This should at least be better than leaving it open!
2021-09-03 13:44:19 -07:00
7e0b3b39e7 Oops, right, 150 is a size too 2021-09-03 13:38:37 -07:00
8f845e7264 Better handle null imageUrl in /api/outfitImage
Oops, right, this is a nullable field! Before this change, a null here would crash the function. Now, it returns a helpful error message!
2021-09-03 13:23:19 -07:00
b8081d98aa Add new layer URLs to valid URL patterns 2021-09-03 13:16:36 -07:00
e5bdff7e23
Merge pull request #4 from matchu/dependabot/npm_and_yarn/immer-9.0.6
Bump immer from 8.0.1 to 9.0.6

I tested the preview deploy a little bit with closet manipulation, seemed fine to me! That's where we do our more complex immer stuff anyway, with sets. Most of what we do with immer is very basic!
2021-09-02 19:30:49 -07:00
ea8791c69d Create a new browser for each assetImage request
Well, holding onto the browser instance seems to be a source of bugs (my previous fix didn't seem to fix it), and I'm not _sure_ what the perf characteristics are, so let's just try a fresh instance each time!

I don't actually know what a browser "instance" in Playwright really is, I'm not sure it even necessarily creates a new process, I just don't know

and I saw some Vercel example code take this approach, which is definitely simpler, and I guess must not be _overtly_ bad perf if it's idiomatic?

So, like, ok, cool, let's see if this stops 500ing us with "Browser closed"! 😅
2021-09-02 19:25:48 -07:00
781034a568 Oops, don't crash if animation image fails
Whoops, `Promise.race` isn't quite what I wanted here. This meant that, if the image promise _fails_ before the movie _succeeds_, the outfit would crash even though it doesn't need to. (And this was happening too often, due to a bug in /api/assetImage!)

Now, we accept whichever _successful_ result loads first, or reject if they _both_ fail.

I tested this by having /api/assetImage always throw, and confirmed that it crashed the outfit before this change, and no longer does after this change!
2021-09-02 19:09:27 -07:00
dependabot[bot]
f5b159b808
Bump immer from 8.0.1 to 9.0.6
Bumps [immer](https://github.com/immerjs/immer) from 8.0.1 to 9.0.6.
- [Release notes](https://github.com/immerjs/immer/releases)
- [Commits](https://github.com/immerjs/immer/compare/v8.0.1...v9.0.6)

---
updated-dependencies:
- dependency-name: immer
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
2021-09-03 01:34:24 +00:00
fc52439387 Reboot assetImage browser when it disappears
Been seeing this in testing in prod, the first few images worked great, but then eventually they all started saying the browser was disconnected.

Here, we add a check to reconnect if it goes missing. This is actually kinda hard to test in dev, because the dev server creates a new process every time the function runs, so fingers crossed!

I also added explicit logic to close the page when we're done with it, I'm worried we crashed the browser by exceeding the RAM limit by leaving pages open. Not sure quite how their model works and whether things eventually get flushed out on their own!
2021-08-19 23:38:25 -07:00
f036890aa1 Use /api/assetImage for all image sizes
We update /api/assetImage to accept size as a parameter (I make it mandatory to push people into HTTP caching happy paths), and we update the GraphQL thing to use it in those cases too!

This also means that, if these images seem to go well, we could swap Classic DTI over to them… I want to turn off those RAM-heavy image converters on the VPS lol
2021-08-19 17:56:09 -07:00
7719ab8c07 Use /api/assetImage for imageUrl
In this change, we start using our new API endpoint for movie image URLs, instead of the Classic DTI image.

This should make the little fade-in phase for certain movies a little bit less jarring (the part where we preload the image before the movie loads), though I suppose that won't necessarily load as fast until it gets into the cache the first time lol. (A good reason to maybe put a more long-lived cache like Fastly in front of this stuff long-term?)

Not doing it for the smaller image sizes yet, I'm a bit worried that I don't 100% know how to teach /api/assetImage to resize without tipping over the function limit…

…oh! I should have the webpage render at different sizes! Yeah that's a great idea lol
2021-08-19 17:40:16 -07:00
adf70dc25f Use chrome-aws-lambda for assetImage
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!
2021-08-19 16:27:22 -07:00
49abb92c03 Use headless chrome in assetImage
Oops, I didn't realize this new package had a headless option! Definitely use it lol, makes dev environment way more chill
2021-08-17 01:44:46 -07:00
c28366772d Polyfill Promise.any for Node v14
Oops, Promise.any was added in Node 15, but prod uses Node 14! Polyfill it!
2021-08-17 01:44:46 -07:00
a1243ad08f Merge branch 'main' of https://github.com/matchu/impress-2020 into main 2021-08-17 01:22:08 -07:00
9ec917e4d3 Use playwright-aws-lambda
So, just using normal playwright was crashing with this error: https://github.com/microsoft/playwright/issues/5862

I didn't understand why everyone was using playwright-core until I read the comments more carefully, and saw that it was because folks were using playwright-aws-lambda, because that's where Vercel functions run. (It has some special compat stuff.)

So I'm figuring that maybe the special case in Vercel's builder that fixes this for playwright-core maybe doesn't apply to normal playwright? But that people don't actually run into that issue in practice, because they're all using playwright-core for playwright-aws-lambda instead?

Idk, let's see how it goes! My hope is that this both fixes the immediate crasher about browsers.json being missing, _and_ fixes a problem we were _gonna_ have down the line about normal playwright not working in an AWS Lambda setting.
2021-08-17 01:01:09 -07:00
f9b4852da1 Handle OFFICIAL_SWF_IS_INCORRECT for pet layers
Marking this glitch on the Yellow Lutari head today, and oops there isn't UI copy for it yet! Added!

Also fixed some bugs in here, like old text about the position of the pose picker relative to the glitch badge, and I noticed while debugging that `layerUsesHTML5` returns a truthy string instead of a boolean which seems error-prone!
2021-08-14 16:46:05 -07:00
ba8e4d8aa7 Trickier disabling honeycomb instrumentation
Hm, okay, so the documented way to not instrument anything doesn't actually stop them from patching Module._load. But this undocumented option sure does! So, woo, let's try it! lol
2021-08-08 00:23:57 -07:00