Oops, of course, we weren't actually taking proper advantage of the dataloader here! The queries got over-complicated, but more importantly, subsequent requests to the same loader would re-submit the query!
I noticed it in the SearchPanel operation, in this Honeycomb trace:
https://ui.honeycomb.io/openneo/datasets/dress-to-impress--2020-/trace/aMuhsTjQFZY
We got bit by the "can't run anything after the response finishes" thing
so I'm just forcing the response to wait for Honeycomb submit to finish
I hope this isn't like, just awful for perf lol. but puts to honeycomb seem fast?
An even better resolution mode for "Dyeworks Pink: Peaceful Tree Garland", which doesn't leave any big chunks or holes, and instead takes all the leaves and gives them chunky outlines 😅
The "Dyeworks Pink: Peaceful Tree Garland" was a tricky case, with animated falling leaves…
we decided that having transparency in the main pet area, and some incorrect transparent holes in the trees, was a better conflict resolution for this one
Probably would be good to manually upload a Totally Good version, but like, this flag is probably good to have
Hey wow this was not so hard, just set some global styles, removed some hardcoded colors, and walked through the remaining hardcoded colors to pick a dark mode variant :) neat!!
oops another thing I missed in the refactor! I wasn't providing the selected pose to the hook, so it wasn't styling any of the poses as selected. Now it does again!
Oops, I removed some fields from the pose object, so the aria-label for the options were coming out as "undefined and undefined"!
Now they come out correct!
I tried to get the alignment juuust right in Chrome and Firefox, but Dice's computer was still including a 1px sliver of border.
In this change, I'm adding 1px of extra padding between the border and the Flash area. I figure that, if the screenshots are incorrectly aligned by 1px, that's no big deal and I'm okay accepting that slightly-incorrect upload rather than having folks not be able to use the tool!
I skipped this in the past runs because I had a hard time getting consistency from the results… but they seem to be behaving now?
It really seemed like there were some races on certain query orders… maybe there still is, but my more-reliable connection today is making them resolve in a more consistent order?
Anyway if I see goofs again, I'll consider adding a snapshot matcher that isn't picky about query order 🤔
I figure we can get even better messages than "Access denied" in case this happens again!
Also, I need a new deployment to trigger the new env vars, so why not make it count? :)
My hypothesis is that this missing `await` is causing prod Vercel to cut off the request before the async upload finishes. Omitting this `await` was a mistake, so I'm just adding it right in!
I also add logging for the success case. That way, if this isn't actually a fix, I can at least watch the logs and confirm whether the app thinks it's getting to here.
This happened in an earlier change too, I forget where, but there's some compiler bug that causes comments placed in this kind of spot to yield this error in production, but not in dev:
https://reactjs.org/docs/error-decoder.html/?invariant=152&args
Oh well, moved the comment!
On mobile, it was pretty annoying that you had to show the controls by tapping the preview area to simulate a hover—because it could also click the underlying elements, and do bad stuff!
Here, I add a click capture to prevent the clicks from going down if the controls aren't visible. And I add a toggle, so that you can dismiss the controls, like how YouTube feels :)
Huh, weird how we seem to need preventDefault for buttons, but stopPropagation for links? idk, in any case, the Remove button was doing that thing where it clicks Remove but also bubbles up to the container and clicks it too :p
This was a surprisingly big win! Item is heavier than it looks, because it has like 6 Chakra components, which aren't expensive but aren't _cheap_ in a re-rendered list that needs to be fast, you know?
And it's even more important on search, where there's a lot of items on the page. (we should virtualize it too but that's a thing for another day)
I noticed that item wear/unwear is slow on mobile, because we re-render the whole app tree, and my laptop handles that super fine, but my few-years-old fun takes ~300ms, which is very noticeable.
There's some hacks we could do to get faster feedback, but first I'm diving into the render tree to find the unnecessary renders and stop 'em! That should help build perf across the board, rather than in just one spot, and hopefully be less of a weird sore spot :)
The button section was capable of flex-shrinking, and having those wrap pretty much always looks bad imo. Here, we get more precise about the areas and their flex rules, including only letting the name area grow/shrink. (If the screen is too small for the name to wrap further, the panel area container gains a horizontal scrollbar, which feels like a really good compromise imo)
I think it's more helpful to auto-switch: if you're using the species/color picker for pet compatibility, that's probably what you want! And it's all buffered behind the Save Changes button anyway, so nbd to play a bit fast and loose!
oof, got "too many connections" from mysql, this is probably gonna be a scaling issue in time… for now, stop requesting a pool of 5, even on dev lolol, and just go with a single connection per instance
