Commit graph

70 commits

Author SHA1 Message Date
74748acaaf Refactor more of item outfit preview into the Outfit class
This is a cute thing that I think sets us up for other stuff down the
line: move more of the outfit appearance logic into the `Outfit` class!
Now, we set up the item page with a temporary instance of `Outfit`,
then ask for its `visible_layers`.

Still missing restricted-zones logic and such, that's next!
2024-07-01 16:07:25 -07:00
054c809052 Put the new item preview in a Turbo frame
Nice, gotta say, this is a pretty neat way of making things feel more
app-y! There's some missing pieces here about like, loading state etc,
but the vibes are pretty good, and the implementation was dead-easy!
2024-07-01 15:35:58 -07:00
1b000189c4 [WIP] Add species/color picker for simplified item page preview
Still a lot missing here, like choosing the right default for Baby etc
items, and saving the user's preferences. But it's a start!
2024-07-01 15:35:58 -07:00
ea17e76c39 [WIP] Start replacing item page preview with simpler HTML-based version
Just stripping out the big React component, and having Rails output it!

There's a lot of work rn in extracting the Impress 2020 dependency from
the `wardrobe-2020` React app, and I'm just curious to see if we can
simplify it at all by pulling this stuff *way* back to basics, and
deleting the item page part of `wardrobe-2020` altogether.

In this draft, we regress a lot of functionality: it just shows the
item on a Blue Acara, with no ability to change it! I'm gonna play with
putting more of that back in.

I also haven't actually removed any of the item page React code; I just
stopped calling it. That can be a cleanup for another time, once we're
confident in this experiment!
2024-07-01 15:35:58 -07:00
c011e99819 Fix various JS Turbo issues
First one, Turbo reasonably yelled at us in the JS console that we
should put its script tag in the `head` rather than the `body`, because
it re-executes scripts in the `body` and we don't want to spin up Turbo
multiple times!

I also removed some scripts that aren't relevant anymore, fixed a bug
in `outfits/new.js` where failing to load a donation pet would cause
the preview thing to not work when you type (I think this might've
already been an issue?), reworked `item_header.js` to just run once in
the `head`, and split scripts into `:javascripts` (run once in `head`)
vs `:javascripts_body` (run every page load in `body`).
2024-03-13 21:26:22 -07:00
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
5d577db649 Oops, load the data for the bulk item quantity form on the trades page! 2024-01-21 06:42:24 -08:00
507b346c2c Move item lists bulk management form to an openable dialog in the header 2024-01-21 06:20:32 -08:00
e8832f2c36 Move item description into header 2024-01-21 05:07:45 -08:00
e4fb067e45 Remove old trade hangers UI from item page 2024-01-21 04:49:06 -08:00
b9bb697ca1 Add trade counts to item page tab navigation 2024-01-21 04:45:22 -08:00
eb6f196b15 Add tab navigation to get to item trade pages 2024-01-21 04:40:25 -08:00
c6927c2ce8 Add basic styles to trades page
Still not accessible via links, just exists!
2024-01-21 03:38:02 -08:00
a03ae90697 Move more of the trade-fetching logic into the model
It was a bit tricky to figure out the right API for this, since I'm
looking ahead to the possibility of splitting these across multiple
pages with more detail, like we do in DTI 2020.

What I like about this API is that the caller gets to apply, or not
apply, whatever scopes they want to the underlying hanger set (like
`includes` or `order`), without violating the usual syntax by e.g.
passing it as a parameter to a method.
2024-01-21 00:39:20 -08:00
80e158caf7 Remove extra item zones section from item page
This is in the previewer UI now, we can remove this extra one!
2024-01-20 23:59:08 -08:00
4c809a5f5f Put back the show more / show less behavior for item page trades
I guess I deleted this a while ago without really noticing… I think I'd
at some point like to replace this with like, the DTI 2020 improved
table layout thing, but I figured this would be pretty quick to throw
in and make the page not feel like a pain to use lmao
2024-01-19 04:29:43 -08:00
f008dff3f4 Remove duplicates from the list of trades
Oh yeah, a long-standing limitation. Good thing we're better at stuff
now!

This is also probably the real cause of the weird number of slight
discrepancies between main DTI and DTI 2020 when I eyeballed stuff lol

oh, well, that and the missing default-lists. A bit messy!
2024-01-19 01:39:25 -08:00
ebb1be88a1 Lil shout-out for the new active-users list filtering
Just a little message that's even timebomb-scheduled to disappear!
2024-01-19 01:18:24 -08:00
b84942d77c Use CSS grid instead of floats for item page info
I'm planning to mess with this layout a bit, I don't want floats
getting in my way!
2024-01-18 22:16:56 -08:00
e8db9cf729 Use CSS grid for item page header
Just modernizing some stuff, hum dee dum
2024-01-18 22:07:30 -08:00
c6cb61ef38 Remove no-op item.thumbnail.secure_url
There was a time when I used an old proxy server to try to fix mixed
content issues, and I eventually removed it but never took the tendrils
out from the code.

We probably _should_ figure out how to secure these URLs! But until
then, we may as well simplify the code.
2023-11-11 08:24:08 -08:00
5dcb1dedb4 Add Owls values to the item page
Eyy it's time!! Long-requested, finally here lol
2023-11-03 16:20:02 -07:00
9cc45f0988 Add wardrobe-2020 outfit preview to item pages
Eyyy tasty! There were some issues with conflicting styles with the main app, but I think we got it!

Scoping Chakra's CSS reset was a big deal to not accidentally overwrite the app's own styles lol, and we had to solve a specificity problem for that, thanks Aria for the :where tip!! <3
2023-10-23 19:05:08 -07:00
Matchu
a4a0188b1b Stop caching trade users on item page
Idk this one might actually be a bit of a pain to load? But I'd want to optimize it differently anyway, and there's overhauls we're already planning to do here.
2023-10-23 19:05:04 -07:00
Matchu
44341ba731 Stop caching pet type images on item page
That's easy queries and easy templates!
2023-10-23 19:05:04 -07:00
Matchu
b87492d4ee Stop caching item page contributors
This lets us remove the contribution observer too!
2023-10-23 19:05:04 -07:00
Matchu
ffa73b6b03 Simplify item page rendering
Just removing some caching and the expiration of it! There's still more superfluous(?) caching on the item page to audit, but these seem a bit more sensible about avoiding loading extra data.
2023-10-23 19:05:04 -07:00
Matchu
b11d7a8c9c oh dang, did we just fix most of the mixed content? 2015-08-05 20:11:08 -04:00
6b340f906e Cache trade info on items#show, finally! I think it's the performance culprit. 2013-12-27 14:49:46 -05:00
f07996d762 cache pet images on items#show, in case that's what's being a super-slow jerkface 2013-12-05 15:22:43 -06:00
cc7ac363dd WIP commit for speeding up item show pages 2013-12-05 13:27:56 -06:00
3c127569fe stop caching item preview species images, and fix the bad query instead
Most of the reasoning is documented in the big comment. In short, we tried
to solve the problem with caching, but the caching should hardly be necessary
now that the bottleneck should be fixed. We'll see on production if it
actually solves the whole problem, but I've confirmed in the console that
redefining this function makes random_basic_per_species (as called during
rendering) a ton faster. And this way we keep our randomness, woo!
2013-06-23 22:35:27 -07:00
154bdd5d0d cache item-preview-species on items#show
items#show has been very slow recently, and I think it's because there's a lot
of querying to be done. Another option would have been to attempt to
short-circuit Item#supported_species if not body specific, but that would
still leave us with 1s load times for body specific items, which is not
satisfactory. The short-circuiting might still be worth doing, but probably
not now.

I'm also not sure that this is actually the core performance problem, but
we'll see. It definitely helped on the dev server: items#show took about
200ms on item pages where everything but species images were cached, then
took about 30ms on subsequent loads. Looking like a good candidate.
2013-06-21 19:30:41 -07:00
26ac3782ec move zones to database 2013-01-24 18:26:00 -06:00
70ff4974a3 refactor items.show for hierarchy and twl 2013-01-24 18:23:21 -06:00
ac0490dc1d i18n for items#show (including javascripts/items/show.js) 2013-01-24 18:23:19 -06:00
07f49307f1 a few tweaks to items#show contributors appearance 2012-10-24 22:16:01 -05:00
f56b544963 brought-to-you-by on items#show lists contributors 2012-10-24 22:09:05 -05:00
e9e7d305f0 retire neoitems links, replace with jn items links 2012-10-21 15:57:17 -05:00
412c401c5f better cache items#show 2012-08-10 00:02:11 -04:00
c7c8f3a78e oops. accidentally used trading post url for auctions. fixed 2012-05-23 20:12:17 -04:00
4451800e42 added shop wiz, etc., links to NP item show page 2012-05-23 20:09:35 -04:00
99a7558dd9 update items#show style 2012-03-23 16:48:00 -05:00
44156c5b21 can now have the same item in more than one list 2012-03-23 16:25:10 -05:00
8bf9872fbe stop caching items#show for now due to Your Items module 2011-08-02 00:12:44 -04:00
137aeac8d4 show traders on items#show 2011-07-31 00:19:28 -04:00
358840076c closet lists, round one 2011-07-29 10:52:04 -04:00
e6c419c7e0 give user paths a canonical tag 2011-07-26 18:56:14 -04:00
85af53417b distinguish between owning and wanting an item 2011-07-22 15:35:38 -04:00
e6020a5cfe simplify closeting item 2011-07-15 16:32:05 -04:00