Still just read-only stuff, but now you can look at all the different poses we have for a species/color!
Soon I'll make the pose/glitched stuff editable :3
Some sizable refactors here to add the ability to specify appearance ID as well as pose… most of the app still doesn't use it, it's mostly just lil extra logic to make it win if it's available!
(The rationale for making it an override, rather than always tracking appearance ID, is that it gets really inconvenient in practice to //wait// on looking up the appearance ID in order to start loading various queries. Species/color/pose is a more intuitive key, and works better and faster when the canonical appearance is what you want!)
similar to the layer zoning tools I just rolled out!
not thrilled about the outfit state hacks here bc of how we cache restrict on the appearance rather than the item, but oh well! this escape hatch is pretty easy and solid, and it's a cleanup for another day
Also did a code split here, now that this file is getting larger, to only load this for support users. I don't actually care about restricting console stuff to support users (I'd honestly rather not), but saving the bytes is worth it I think, since support mode is pretty easy to enter when we need to
This is in support of a caching issue in a hack tool coming next! Without this, the change to ItemAppearance restricted zones would make other ItemAppearance fields go missing (bc our hack tool didn't also specify them), so the query would re-execute over the network to find the missing fields we overwrote with nothingness—which would undo the local hack change.
A dev tool to preview what an item would look like in a different zone!
To use, open the browser console, and type `DTIHackLayerZone(layerId, zoneIdOrName)`, but replace `layerId` with the layer's DTI ID, and `zoneIdOrName` with either the zone ID or its name in quotes.
Previously, we were using a custom-y `id` field to help Apollo cross-reference `petAppearance` queries with the results from bulk `petAppearances` queries. Now, instead, we deprecate `petStateId`, and start using `id` to have the same stable value!
This is in anticipation of pet appearance support tools: a stable ID will make it easier to edit them, esp changing their pose (which would otherwise have changed the ID!)
Previously, we would load all `petAppearances` in `PosePicker`, and use cache keys to instantly find it again as a single `petAppearance` in `OutfitPreview` after switching poses.
In this change, we instead have `PosePicker` explicitly load all 6 poses as separate `petAppearance` queries. This simplifies cache sharing between the two components' queries: Apollo can do it automatically, because they were queried the same way in the first place.
I'm doing this in preparation for changing the `id` field of `PetAppearance`, to become `petStateId`. This will help me build pet appearance support tools, by giving the appearances stable identifiers that won't be affected by editing which pose an appearance is!
Dice reported this, thank you!
My mistake here was that `loadImage` _does_ reject when the image fails to load… but it ends up throwing `undefined`, since I forgot to pass the error along from `onerror` to `reject`!
So we would cancel stuff, but then store `undefined` as our error in state, which our component interprets as no-error.
I tested this by using Firefox DevTools request blocking!
On the homepage, I want to keep the ability to enter invalid species/color pairs, so that you can say "Alien, Aisha" instead of having to pick the Aisha first.
But on the wardrobe page, we were rejecting invalid state changes anyway, so I decided to remove invalid color options from the list. And I added an ability to still switch to any species, and potentially resetting to a basic color automatically to match.
Oops, our loading state logic was eating the error case! I'm not sure exactly where the gap was happening, but I've rewritten the states to be a bit more foolproof, since that first condition was confusing I think.
Ahaha I fucked up a bit! I was indexing into the array of cached zones, instead of looking up by ID. This meant that all zone names were wrong, and some search results weren't loading bc there was no zone data!
I made a fix here, and also added some fallback values, so that if there's an issue in the future we can at least fall back more gracefully than the infinite-spinner case we had here.
In this change, we cache the zones table as part of the JS build process. This keeps the database as our source of truth, while aggressively caching the data at deploy time.
See the new README for some rationale!
I tested this by pulling up dev Honeycomb, and observing that we no longer run db queries to `zones` in the new traces for the wardrobe page. (It's a good thing we did it this way, because I noticed some code in the server that was still loading the zone anyway, and fixed it here!)
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!
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!
One fix was that `position: absolute` stuff was appearing over the drawer, including the item search clear button, oof!
Another fix was for a weird bug(?) in Apollo Client, see comments
Note that there's a bug when switching back to the null case… when I look in the Apollo dev tools, it's definitely getting set in the cache correctly at the right time… but the query isn't updating for some reason? I'm hoping it's an Apollo bug that will fix itself someday with an upgrade!
Optimistic UI seems to just be like, not working… I'm seeing some Google results suggesting maybe just get to v3, which is a bit of upgrade work but might be worth it
Oh oops, Chakra UI Next deprecates usePortal for the popover, so it wasn't escaping properly! Add a Portal component to let it escape the top area again!
I guess if you return a reference to an object that doesn't exist, it registers as null; and you need to provide the `true` here to declare that it _is_ real and should be treated as an _insufficiently_ defined object?
Using the newly extracted OutfitPreview! I'm really happy with how this turned out :3
It also makes the pageload after clicking Start super smooth, no spinner! Thanks Apollo cache!!
Kinda surprised our cache redirect isn't good enough for this, but I guess Apollo can't differentiate between a confident empty list vs an uncertain empty list!
It looks like, in prod, our lambda fn here got optimized away, and I'm guessing it's because it starts with a comment now? I moved the comment down a line, fingers crossed!
