Commit graph

69 commits

Author SHA1 Message Date
81c6a4a023 Add outfit name to Shopping List page title
Just some extra flair! I had considered something like this before, but
felt it didn't flow well with the old title.
2024-07-09 13:19:23 -07:00
d7eb490ac0 Use a shopping bag icon for the "Shopping List" button
Shopping bag with check! Heck yeah!
2024-07-09 13:14:22 -07:00
c96b726a61 Rebrand the "Item Getting Guide" as "Shopping List"
Two reasons for this new title:
1. The pitch for "Get these items!" is weaker, now that we're not
   getting the power-user integrations we'd planned around.
2. I literally only just thought of it now!
2024-07-09 13:04:22 -07:00
63abfa51f7 Redesign "Get these items!" button to use a cart icon instead
This helps it fit in the kinda crunchy horizontal space a lot better!
2024-05-31 17:38:25 -07:00
72c739ca0f Improve layout for "Get these items!" and "Save" buttons in editor
Make them the same size, add spacing between them, and also put the
"Get these items!" on the right, because the list is right-aligned and
the Save button has dynamic width (the save vs saving vs saved states),
so this makes things a lot more consistent and stable!
2024-05-28 17:32:18 -07:00
f84e340899 Add link to Item Getting Guide from outfit editor (behind secret link)
You can now go to `/outfits/new?features=get-these-items` to start
seeing the "Get These Items!" button in the outfit editor!

I haven't tested it a ton yet, but yeah here it is!
2024-05-28 17:06:23 -07:00
a749b331f1 Fix multi-word search in outfit editor
Oops, prior to this commit, searching for "white peach" would return
nothing, whereas now it correctly returns the "Dyeworks White: Just
Peachy Filter", like if you search in the Infinite Closet!

This solution is a bit hacky, wrote some more in the comments about how
to maybe do this better!
2024-05-06 15:08:37 -07:00
460235e7cf Fix some eslint errors
Huh, I guess my desktop workstation doesn't have this commit hook set
up. Now that I'm using my Mac again, it's catching some things I
missed!
2024-05-02 12:18:51 -07:00
0ed4e8f216 Add "Baby Body Paint" warning to Known Glitches badge in-app, too
I previously added a warning to the item page, and thought about doing
one here but was sicky and misjudged the complexity and forgot you
don't need to hook into the `knownGlitches` API field to do it! Easy
peasy for a hacky little bug message!
2024-02-27 19:22:08 -08:00
4f069a5742 Remove the GQL-based useSearchResults, everyone is on it now!
The main *intended* user-facing effect of this is that "Items you own"
and "Items you want" filters should work in wardrobe-2020 now!

It is also possible that I messed something up and that this might
break unrelated searches somehow! We'll find out!! 😅
2024-02-27 16:49:52 -08:00
66c1e14dd0 Add item search results to Apollo cache, use in finding item conflicts
This makes clicking on search results in the new mode actually work! It
correctly adds it to the outfit, and removes other items.

The thing that's behaving strangely is that, when you add the item, we
visually remove all items until we can finish a fresh network request
for what they should all look like. This probably means that the cache
lookup for `useOutfitAppearance` is not as satisfied with what we cache
here as `findItemConflicts` is? Something to investigate!
2024-02-27 12:19:07 -08:00
752bee3c39 Use MajorErrorMessage for search result errors
It'd be nice to customize the message a bit, but this should be rare
and I'd prefer the simplicity of just going with the default text.

I ran into this when I made a mistake in how I process the return value
of search results, so React Query caught and raised the error via
React, as intended! And I was annoyed that it wasn't logged anywhere,
so that's my motivation for this change—but also, the old message is
pretty meh and has some layout problems anyway.
2024-02-27 12:03:23 -08:00
a8cbce0864 Start working on new item search in wardrobe-2020!
For now, I'm doing it with a secret feature flag, since I want to be
committing but it isn't all quite working yet!

Search works right, and the appearance data is getting returned, but I
don't have the Apollo Cache integrations yet, which we rely on more
than I remembered!

Also, alt styles will crash it for now!
2024-02-25 14:46:27 -08:00
a3dcaa0f0e Add useItemSearch for wardrobe app, but don't use it yet!
Adding new functionality to the item search JSON endpoint, and adding
an adapter layer to match the GQL format!

Hopefully this will be pretty drop-in-able, we'll see!
2024-02-25 12:06:32 -08:00
9ed3c4ff96 Add Alt Styles reference page link to the Alt Styles picker
Clearing the way to be able to delete the announcement banner, which is
currently the only link!

I feel like there's room to redo the site layout to find a place to
more properly link to this from, but I don't have one yet! And this is
enough of a niche reference that I think this is good enough?
2024-02-25 10:44:00 -08:00
258b360ff2 Oops, fix infinite autosaving loop!
A bit of a hack, because the thing triggering it was also a bit of a
hack? I feel like there's something we gotta do with refactoring how
our multiple concepts of state are managed… but in any case! This seems
to keep basic outfit-loading working, while no longer getting us
trapped in autosave loops!

Here's how I reproduced the bug:
1. Open a saved outfit.
2. Set the browser devtools to apply a latency of 5sec to all requests.
3. Add an item to the outfit, and wait for the autosave to start.
4. While it still says "Saving", remove the item again.
5. Watch how, when the first autosave request comes in, the item is
   re-applied to the outfit, then autosave gets stuck looping forever.

The issue was that, when an outfit finishes saving, the change in
outfit data was triggering this effect in `useOutfitState` that was
*meant* to *initialize* local state from the saved outfit, not to keep
them in sync all the time. (In general, when saved outfit data comes
back from the server, we don't want to use it to "fix" local outfit
state in the case of discrepancies, because the most common source of
discrepancy will be the user having made further changes!)

But anyway, one thing I didn't realize is that we *were* depending on
this hacky hook to do more than I thought: it was responsible for
syncing `id` and `appearanceId` to the local state after saving the
outfit. So, I replaced the `rename` action dispatch here with a new
action that explicitly sets all fields the server is responsible for!
2024-02-25 10:37:08 -08:00
3ab6d1e3ae Oops, add some more wiring for pet state ID for saved outfits
There's an infinite loop happening in prod that I can't reproduce on
dev, but this missing piece feels like it could be related.
2024-02-08 10:15:31 -08:00
a4ca9ae522 Make the Alt Styles list less tall on large screens
On the small-screen layout, the popover goes down and covers the item
list, which isn't a big deal in context; so I want it to be basically
as tall as it can be without being unwieldy, to give more info.

But on the large-screen layout, it doesn't take long at all for the
popover to start intersecting the pet preview, because it *has* to go
up and cover the pet preview. So, I'm much more reserved about how much
vertical space I'm willing to give it!

(I also considered sending the popover off to the *right* of the button,
to cover the item list, but it felt *way* too weird imo! Especially in
the expressions case.)
2024-02-01 07:34:39 -08:00
f7fdf4e44c Don't show a glitch message for Alt Style items being Incompatible
The intent of this glitch message was that, when UC or Invisible pets
hide an item because of a zones-restrict thing, it would still show up
in the items panel as fitting a certain zone, whereas it should have
been in the "Incompatible" section and having none of its zones applied.

But the previously implementation would like, show this message even for
items that _were_ correctly marked as Incompatible? And that the server
returned no layers for, because it doesn't fit this body type to begin
with? (e.g. put a Grarrl hat on a Grarrl, then switch to Acara, and the
Grarrl hat is marked Incompatible—but would also show this confusing
message; or similarly with switching to Alt Styles)

So, when the server just returned no layers for this item to begin with,
don't show this message!
2024-02-01 07:13:04 -08:00
c13c6e7bd8 Remove the isLazy focus-management hack from PosePicker
Now that we're tracking tab state ourselves, it's pretty easy to just
pass the `initialFocusRef` to the right place instead of to both!

This helps switching between the tabs feel a lot smoother, because we
don't have to re-render and fade-in all the poses again.
2024-02-01 06:53:32 -08:00
00bc9c3bf7 Use hourglass icon for Retired UCs
The sunglasses communicated too much legitimacy lmao
2024-02-01 06:48:40 -08:00
e2d8a86f79 Add a warning that UCs are retired now
I'm keeping it in the same place for now rather than trying to fold it
into Styles, because I think that's net-less-confusing (since Styles
work pretty differently, e.g. different color requirements), and
certainly less work either way lol!
2024-02-01 06:43:14 -08:00
3a76dbb368 Show Alt Styles to all users in the outfit editor!
I think we're ready, turning off the Support-only gate!
2024-02-01 06:01:04 -08:00
453d6783c4 Move the style and state params earlier in the outfit URL
Idk I just think it's nice for them to be next to pose and such!
2024-02-01 06:00:39 -08:00
c60e222faa Add Alt Style support to outfit saving
Pretty straightforward, just add the field to the record, and wire it
all up! I'm glad this seemed to work out pretty well all-in-all 😅
2024-02-01 05:55:19 -08:00
b06149cf22 Make the "Incompatible" explainer more specific for Alt Styles
For Alt Style outfits, it's useful to call special attention to the Alt
Style feature as the likely cause of incompatibilities.

(Incompatibilities previously were most often caused by choosing a
species-specific item, then switching to another species. We generally
make it hard to enter this state, by hiding incompatible items during
search.)
2024-02-01 05:43:33 -08:00
f30213697a Clarify item compatibility in the Alt Styles explanation text
Just a lil hint that many items won't fit, in case it's a surprise to
folks!
2024-02-01 05:40:16 -08:00
cd136aa6a5 Make species/color picker smaller on small screens, to fit pose picker
Now that the pose picker button can have text content too, things were
getting pretty cramped horizontally on smaller screens! Now we use the
`sm` size when it's small-time.
2024-02-01 05:31:34 -08:00
09846a4516 Make pose picker button easier to see on light backgrounds 2024-02-01 05:26:26 -08:00
fc71f5b5a5 Filter by Alt Style in item search and item appearance API calls
I'm not planning to port full Alt Style support over to the 2020
frontend, I really am winding that down, but adding a couple lil API
parameters are *by far* the easiest way to get Alt Styles working in
the main app because of how it calls the 2020 API. So here we are, just
using new parameters for DTI 2020 that I'm gonna deploy to impress-2020
first!
2024-02-01 04:58:30 -08:00
578528f468 Better handling for items in different zones with the same name
Specifically, I was looking at the new "Stormy Cloud Kacheek" items,
and was surprised to find that, in the outfit editor, they all get
grouped under "Markings" (and therefore the UI treats them as
mutually-exclusive via hidden radio button and only bolds one at a
time), but they aren't actually conflicting because they occupy
different zones named "Markings".

In this change, we make the zone groups actually just be *by zone*
rather than jumbling all of the zones with the same label together; but
in most cases, we still keep the same simplified display. In the case
of the "Stormy Cloud Kacheek" items though, we now get a few groups:
`Glasses`, `Markings (#6)`, and `Markings (#16)`. Glasses is chosen
by coincidence because it's the first zone label for that item
alphabetically (even though that item also occupies a third "Markings"
zone), and then the other two know to disambiguate from each other.

There's an opportunity here to cheat things further, like to
*intentionally* select items like "Glasses" that are less ambiguous
when possible. I'm not aware of enough other cases like this for that
to really matter, though, so I'm just leaving it as-is!

I tested this a *bit* on other outfits, and everything looked fine at
a glance, so I'm just moving forward—but I'll make an announcement to
ask people to help take a look!
2024-02-01 03:14:00 -08:00
ab8c9f6242 Oops, remove alt style when switching species
This wasn't causing big problems because we made resilient little
choices in a lot of little places… but it's confusing as a potential
state, and the Styles chooser wasn't selecting the "Default" option
after you switch—which is what tipped us off!
2024-01-30 07:21:14 -08:00
c2de6f7167 Display alt styles in outfit editor when selected
Yay it works(*)! But two major missing pieces:

- Outfit saving doesn't persist it at all
- Item compatibility is unaffected: items will still appear in search
  and in the preview, even when they don't fit anymore.
2024-01-30 07:01:03 -08:00
3ebbfc4967 Move alt style state into the outfit state
This still doesn't _do_ anything, except that you can see the URL
change when you switch between styles. Just a step forward is all!
2024-01-30 06:21:32 -08:00
741d52175b Open the pose picker to Styles if there's an Alt Style applied 2024-01-30 06:04:35 -08:00
8e5939e408 Show alt style name in the pose picker button when selected
To help with space, I'm just showing the word "Nostalgic" (or "???" if
it's from a series we don't recognize, this is hardcoded by ID), and
trusting that from context it will be obvious that it's the "Nostalgic
Faerie" case or whatever. (Moreover, in both the button and the select
we're omitting the species name, by similar reasoning!)

Note that this _still_ doesn't actually apply the style to the outfit
whatsoever; this is all just local state as we're continuing to play
with UI concepts. Actually applying it is probably next though! (Though
there's a couple more UI things I want to do, like some affordances to
clarify that a Style is applied and that Expression changes won't work.)
2024-01-30 05:55:19 -08:00
33bcabab83 Overhaul pose picker button to have text now, for all users
This one isn't reserved just for Support users! I think this button
stands out a lot more with the text, and I want people to be able to
discover it!
2024-01-30 05:38:19 -08:00
4025dcd968 Oops, fix crash on unknown pose case
Right, I was playing with the paintbrush but didn't end up using it!
Let's uhh go with the smile as the default, I guess?
2024-01-30 05:06:26 -08:00
bc77c261fb Set initial focus when opening the PosePicker to the Styles tab
Later on I'll want to control the picker to open to Styles if a style
is selected, or to Expressions if not.
2024-01-29 09:17:09 -08:00
bdfa3aad0b Oops, fix bug in alt styles query loading state
Oh right, React Query's API is slightly different, fixed! (Previously,
this would cause the PosePicker to show before all the data was ready,
so alt styles would sometimes pop in after the popover was already
open.)
2024-01-29 09:10:26 -08:00
8f934e83b8 Move Expressions/Styles tab to the top/bottom depending on placement
On small screens, the PosePicker opens down, and we put the tabs on the
top, to be near the button.

On large screens, the PosePicker opens up, and we put the tabs on the
bottom, to be near the button.

Previously, we always set `placement="bottom-end"`, which on small
screens behaved as written, and on large screens there would not be
space to open downward so it would open upward instead.

Now, we set the placement explicitly based on a media breakpoint, and
we change the `flexDirection` of the tabs container on the same media
breakpoint.
2024-01-29 09:09:09 -08:00
49158b2c54 Make the new pose picker button text support-only
I'm playing with using text to call more attention to this button, but
I'm not altogether pleased with the design yet. I'll leave it there for
me and Support users, but hide it for most people until we've got a
more complete concept.
2024-01-29 08:45:22 -08:00
207c65f209 Link to the Styling Chamber 2024-01-29 05:36:48 -08:00
433a14104f Hide the WIP Styles UI behind support staff flag
That way, I can stop being on a branch and be working on main, and
deploy stuff to preview live, without having to share it with everyone
just yet! (This was the motivation for finally adding Support tooling
to main DTI lol!)
2024-01-29 04:36:48 -08:00
514c99fb42 Add WIP styles tab to the pose picker
It shows the styles! You can select between them, but it currently does
nothing, womp womp!
2024-01-29 04:26:40 -08:00
e2ab8bbc9c Start adding Styles UI to pose picker
Add the tab UI, though the styles aren't in it yet; and add text label
to help make the whole UI more discoverable.
2024-01-29 04:26:40 -08:00
57beca1b3c Refactor PosePicker a bit
Just extracting some things to make the main function body leaner so
it's easier to add the alt styles stuff.
2024-01-29 04:26:40 -08:00
32f5d6d4a0 Show the PosePicker, even if there are no standard poses labeled
This is because I'm gonna put alt styles in here too, and I figure it's
reasonable to just explain what's going on.
2024-01-29 04:26:40 -08:00
4fff8d88f2 Add support_staff flag to user record; they can use Support tools
A little architecture trick here! DTI 2020 authorizes support staff
requests by means of a secret token, instead of user account stuff. And
our support tools still all call DTI 2020 APIs.

So here, we bridge the gap: we copy DTI 2020's support secret to this
app's environment variables (I needed to update
`deploy/files/production.env` and run `bin/deploy:setup` for this!),
then users with the new `support_secret` flag have it added to their
HTML documents in the meta tags. Then, the JS reads the meta tag.

I also fixed an issue in the `deploy/setup.yml` playbook, where I had
temporarily commented some stuff out to skip steps one time, and forgot
to uncomment them after oops lol!
2024-01-29 04:21:19 -08:00
6763e9454e Optionally use local instance of impress-2020 during development
To activate this, I created a `.env.development` file in my project
root, with the following content:

```env
IMPRESS_2020_ORIGIN=http://localhost:4000
```

Then, I started impress-2020 with `yarn dev --port=4000`.

Now, the app loads from there, hooray!! It even fixes that obnoxious
pet state ID bug that happens when you run against the production db lol
2024-01-28 07:00:29 -08:00