Commit graph

24 commits

Author SHA1 Message Date
e6200df49d Speed up dev server by skipping persisted queries 2021-02-07 00:18:01 -08:00
81117218a3 Only wait for auth on queries that need it
I switched from my `_NoAuthRequired` opname hack, to a more robust `context` argument, and it's opt-in!

This should make queries without user data faster by default. We'll need to remember to specify this in order to get user data, but it shouldn't be something we'd like, ship without remembering—the feature just won't work until we do!
2021-01-21 14:57:21 -08:00
6e33132881 Load homepage faster for logged-in users
When building the code to await auth before sending _any_ GraphQL queries, I didn't realize that auth might be kinda slow. So, I've added a hack to let me mark queries with no user-specific data to skip auth, and applied that to the main queries on the homepage.

I think this is a hint that we might want to change our strategy - e.g. to flip it to hackily mark that auth _is_ required, or to create wrappers or option-builder helpers for logged-in queries, etc.

I also notice that SSR would have resolved this particular case...
2021-01-18 07:15:00 -08:00
102a29fefd show outfit name faster, instead of "Untitled Outfit"
That'll still show up when the outfit is still loading, but this lets us use the Apollo cache to show the name instantly if you're clicking through a link from Your Outfits
2021-01-05 06:39:12 +00:00
7c9313f4a6 support tool to edit usernames 2020-11-18 07:42:40 -08:00
3ecdd265c2 smarter cache lookups for "do we own/want this?" 2020-09-12 22:39:38 -07:00
bf2660cbd4 show a basic item preview on the new item page 2020-09-12 17:56:31 -07:00
88862f9ce7 simplify petAppearance cache lookup, remove hacks
I think I got all up in my head about direct queries for this one, because of a previous implementation I had in mind, and I forgot that I could just query species and color from the cache by reference without breaking out of the API provided to the cache function!

I also learned in here that I _can_ look up things from the root by doing `readField("allSpecies", {__ref: "ROOT_QUERY"})`, which I struggled to figure out my previous time. I couldn't figure out how to read an uncached field with arguments (I couldn't quite figure out how to build a proper FieldNode, and passing the string form seemed to provide `null` to the `species` cache field reader), but it's probably doable!
2020-09-05 16:37:17 -07:00
Matchu
70d3b06742 basic items page, with user permissioning :)
(the permissioning happens on the backend in the prev change! but yeah we send the auth token in the headers, so the backend knows who you are and whether to show you private data)

(also it is just owned items not in any list!)
2020-09-04 05:59:35 -07:00
0088c3f193 first draft of search zones
It doesn't affect the actual query yet, and it looks bad! But it exists!
2020-09-01 18:59:05 -07:00
eab1b99052 use cache restore instead of field defs for Zone
This is just an implementation thing, but I realized we can just insert the Zone data into the initial Apollo cache, instead of doing weird field definitions

I _do_ still want the @client tags in the queries though, to tell them not to make server requests at all
2020-09-01 18:02:59 -07:00
3a6e3fac8e add isCommonlyUsedByItems to Zone
This is in preparation for hiding bio zone restrictions but showing item zone restrictions!

I also refactor the build-cached-data script substantially, to run GraphQL against the server instead of a custom query.
2020-09-01 01:16:30 -07:00
856d8586e4 cache item data when switching standard colors
Previously, when changing a pet's color, we would refresh the items panel and send a new network request for the item appearances, even though they're all the same. This is because item appearance data is queried by species/color, for ease of specification.

But! Item appearances are //cached// by body ID. So, if this is a standard color, it's not hard to look in the cache for the standard color's body ID!

Now, most color changes are faster and don't flicker the item panel anymore. We do still refresh the panel and send the requests for color changes that _do_ matter though, like standard <-> mutant!
2020-08-31 18:25:42 -07:00
05e5c5ad3e add petAppearanceById client caching
If we already got this PetAppearance, now `petAppearanceById` knows how to serve it from the client cache instead making a network request!
2020-08-29 13:23:41 -07:00
a58db2dcd1 add restricted zones to item support UI
Honestly kinda embarrased I forgot this!
2020-08-27 23:09:53 -07:00
b3aa82cc66 enable Apollo dev tools in production
I'm doing this to see if I can give Chips a cute way to hack into local data :p
2020-08-27 21:44:54 -07:00
bf21716db0 simplify PetAppearance client-side caching
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!
2020-08-27 21:26:24 -07:00
f6c228b17e lol fix cached zone names
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.
2020-08-19 18:01:20 -07:00
47d22ad25c Build cached zones, stop querying on server
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!)
2020-08-19 17:50:05 -07:00
7f8401ff4b fix apollo client 3 initial item load bug
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?
2020-07-31 23:21:34 -07:00
8211444d67 apollo client 3 initial upgrade
Some bugs remaining… outfit items don't show up at first, and item search and scrolling seems _very_ weird, wearing is broken too…
2020-07-31 23:10:34 -07:00
Matt Dunn-Rankin
75a0fe2e8c refactor e/gp pairs to pose enum 2020-05-23 12:47:06 -07:00
Matt Dunn-Rankin
e9a490feca oops, we broke cacheRedirects, so item adds broke! 2020-05-19 15:14:12 -07:00
Matt Dunn-Rankin
9c8a48a325 http caching for all color/species requests 2020-05-14 15:51:08 -07:00