Dress to Impress, a big fancy Neopets customization tool!
Emi Matchu
6a0afb330b
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. |
||
|---|---|---|
| .devcontainer | ||
| .husky | ||
| app | ||
| bin | ||
| config | ||
| db | ||
| deploy | ||
| lib | ||
| public | ||
| test | ||
| vendor | ||
| .eslintrc.json | ||
| .gitignore | ||
| .ruby-version | ||
| .yarnrc.yml | ||
| config.ru | ||
| falcon.rb | ||
| Gemfile | ||
| Gemfile.lock | ||
| LICENSE.md | ||
| package.json | ||
| Procfile.dev | ||
| Rakefile | ||
| README.md | ||
| yarn.lock | ||
Dress to Impress
Oh! We've been revitalizing the Rails app! Fun!
There'll be more to say about it here soon :3