impress/app/views/items
Emi Matchu 6a0afb330b Add warning for "Baby Body Paint" bugs
I *think* what I'm observing is that:

1. The zone restrictions are different between these items.
2. The zone restrictions *change* when reloading the page sometimes. (I
   assume from remodeling?)
3. The items look very buggy on many pets, because many appearances
   seem to expect different zone restrictions than the item actually
   has.

I think what this means is:

1. TNT has finally unbound restricted zones from the item level, and
   allowed different appearances to have different restrictions. Neat!
2. The API still serves it the same way, as a field on the item.

So I think this means we need to update our schema to reflect the fact
that an item's `zones_restrict` field isn't *really* a property of the
item; it's a property of the combination of the item and the current
body ID.

My gut take here is that maybe this means it's time for the Large
Refactor that I've kinda been interested in for a while, but been
avoiding because of Impress 2020 compatibility issues: instead of a
`body_id` field on assets, and having them directly belong to items,
make an `ItemAppearance` record (closer to how 2020's GQL API modeled
it, I was looking ahead to this possibility!) that's keyed on item and
body ID, and assets belong to *that*.

Then, we could move the zones restriction field onto the
`ItemAppearance` record instead. And then it doesn't really matter to
us how TNT models it internally; whatever we saw is what we use.
(Again, I looked ahead to this in the 2020 app, and tried to use the
`restrictedZones` field on `ItemAppearance` when possible—even though
it secretly just reads directly from the `Item`!)

…but that's a pretty big departure from how things are modeled now, and
isn't something we can just throw together—especially coordinating it
across both apps. I was getting close to being able to shut off 2020
from a *front-facing* perspective (but still keeping a lot of the GQL
endpoints open for the wardrobe-2020 frontend), but I don't think we're
very close to being able to try to target turning off 2020's *backend*
as a prereq to this; or at least, if we do, we should expect that to
take a while. (Counting now, there's still 9 GQL queries—not as many as
I expected tbh, but still quite a few.)

So idk how to sequence this! But for now, let's put out a warning, and
start setting expectations.
2024-02-27 18:16:23 -08:00
..
_item.html.haml Move item_link partial caching to a helper rather than the template itself 2013-06-22 16:31:46 -07:00
_item_header.haml Add "first seen" timestamps to item pages 2024-02-20 14:32:45 -08:00
_item_link.html.haml High-level caching for closet lists 2024-02-20 18:43:39 -08:00
index.html.haml Remove newest_items caching from items page 2023-10-23 19:05:04 -07:00
needed.html.haml Update most URLs to use HTTPS 2023-10-25 15:22:57 -07:00
show.html.haml Add warning for "Baby Body Paint" bugs 2024-02-27 18:16:23 -08:00