Note that these queries are a bit slow. I don't think these new subpages will be accessed anywhere near often enough for their ~2sec query time to be a big deal. But if we start getting into trouble with it (e.g. someone starts slamming us for fun), we can look into how how cache these values over time.
Just a small visual cleanup because I happened to click on item trades
today! We don't need to repeat "This Week" a million times. Just output
it for the first row, then hide it for the following. (We still include
it in screen reader output for semantic clarity; this is just a visual
cleanup.)
Sigh, the "Valentine Plushie" series is messing with me again! It
doesn't follow the previously established pattern of the names being
"<series> <color> <species>", because in this case the base color is
considered "Valentine".
Okay, well! In this change we add `full_name` as an explicit database
field, and set the previous full name value as a fallback. (We also
extract the generic fallback logic into `ApplicationRecord`, to help us
express it more concisely.)
We also tweak `adjective_name` to be able to shorten custom `full_name`
values, too. That way, in the outfit editor, the Styles options show
correct values like "Cherub Plushie" for the "Cherub Plushie Acara".
I also make some changes in the outfit editor to better accommodate the
longer series names, to try to better handle long words but also to
just only use the first word of the series main name anyway. (Currently,
all series main names are one word, except "Valentine Plushie" becomes
"Valentine".)
Instead of offering a form to request a different format, we just
render both in the HTML, and use CSS to swap between the two. Love to
see the `:has` filter come through for us!
Oh oops, Firefox is a bit stricter about interpreting custom elements
as inline elements by default instead of block elements. This messes up
the positioning relative to the container. Fixed!
I've known there are bugs in the SVGs pretty often, because they're not
very well attended-to—I noticed pretty quick that the Marble Eyrie, for
example, has its Body asset saved correctly in PNG, but its SVG is just
another copy of the head, oops!
I think SVG is still a nice default for this UI, but I added a little
form to switch to PNG, to give us a debugging method and escape hatch
if it starts to get weird.
This washes out the colors a bit more than necessary on lighter pets,
but helps a lot on darker pets. It really kinda pushes everything other
than the lineart all the way to white, which tbh is a pretty neat
sketch-like effect.
I couldn't find a library for this functionality that didn't require
jQuery, and I don't want to be adding *more* jQuery requirements. So, I
decided to throw together my own!
The `<magic-magnifier>` component copies its contents into a "lens"
element, then uses basic JS to track mouse position, then uses CSS to
move the lens and its contents into a helpful position.
One thing I noticed here is that the zoom is a bit crunchy because
we're using PNG images, and it's hard to zoom in even further than we
already are. I might try switching this UI to use the SVG images by
default instead?
When you hover the row for a layer in the table, it highlights the
corresponding layer in the outfit viewer. And when you click anywhere
in the row, it opens the first link (usually the PNG image).