Oh, right, silly: my previous version of this change still grouped by
zone, then mapped the zones to their labels. This didn't *merge* the
lists of appearances for zones that share the same label; just one of
the zones would win, and the others would disappear.
In this change, I just go upstream and actually group them by label in
the first place, instead of grouping by zone then trying to merge and
transform them.
For example, the "Red Knitted Beanie with Wig" occupies two different
"Hat" zones: one for behind the head, and one for in front. It's not
useful to split them up!
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!
Before this change, the sort order when searching for
"Prismatic Pine: Nostalgic" showed:
- [Added Dec 18, 2024] Prismatic Pine: Nostalgic Christmas Flotsam
- [Added Dec 19, 2024] Prismatic Pine: Nostalgic Christmas Gelert
- [Added Dec 18, 2024] Prismatic Pine: Nostalgic Christmas Bruce
- [Added Dec 17, 2024] Prismatic Pine: Nostalgic Christmas Scorchio
- <more>
This is because the Gelert was created at 11:37 NST on Dec 19, whereas
the Flotsam was created at 18:11 NST on Dec 18—but in UTC, which is how
timestamps are stored in the database, these are both Dec 19, so the
Flotsam was sorting first alphabetically.
In this change, we do a hacky transform from UTC to NST-ish. I didn't
want to set up the deploy process to pull named time zones into MySQL,
and then have this as a potential gotcha for the dev environment
later—so instead, I pretend `-08:00` is a good-enough specification of
NST.
This will sometimes create slightly incorrect sort ordering when it
*is* Daylight Savings, and a record was created around midnight. I'm
okay with that!
When there's an unlabeled style, previously we'd include the placeholder
value "<New?>" in the search dropdown, even though we don't actually
support searching by it.
Now, we don't! I did this in part by just refactoring how we look this
stuff up, with queries that don't load *all* alt styles into memory,
which will help perf a bit as more of them are released.
I ran a bad version of this job yesterday, and set a lot of the new
styles to an incorrect "Prismatic" series name. This will help me fix
them!
There's still styles to manually fix, where TNT decided not to put the
full series name in the item name. (Presumably some of the names were
too long? Or maybe they just forgot?) But this is a better starting
point!
Ahh right, that's part of why I skipped Prismatics: it's no longer true
that the first word of the style is its series name.
In this change, I try to parse out everything before the pet name part
of the style name, and default to skipping it if we can't quite get it
right.
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!
Ruby 3.3.6 has a warning for this, neat! I apparently didn't notice the
`path` option already there at first, and just added a new one.
This change shouldn't affect behavior, it just is clearer and removes a
warning!
A style not being modeled yet is not a big deal, whereas some of those
other warnings actually require manual intervention. I want to make the
list easier to scan for the warn icons!
Fedora upgraded its system Ruby, and I'm on that laptop today, and I
prefer to have prod keep pace rather than use rbenv to keep myself and
prod knowingly on an older version!
Just a wrapper for the barrier/semaphore thing we're doing constantly!
I only applied it in the importer rake tasks for now. There's other
call sites to move over to it, too!
Previously, "Then: Go to unlabeled appearance" would always take you to
the *first* unlabeled appearance in our database.
Now, we go to the *next* unlabeled appearance in the list, relative to
this one.
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).
Sometimes I forget like, what the masc/fem variants of a given pet
actually look like? Some are super obvious about things like eyelashes,
and others use more subtle eye differences.
This is a cheap lil hack to make it easier to open a reference! Ideally
I think it would be neat to like, when you hover over an option, have
it show you the reference variant of that pose? But this is good enough
I think!
If the screen is narrow, many of the bubbles will wrap their text onto
two lines, but "Unconverted" won't. Give it equal height to the rest
anyway, for visual consistency!
We copy the same feature from alt styles, now that the UI is shared via
support form helpers! Easy peasy!
This adds a "Then: Go to unlabeled appearance" checkbox next to the
submit button on the pet appearance edit form. If checked, it takes you
to the first unlabeled appearance in the database, and keeps the box
checked for next time. Slam through 'em!
This helped me debug a thing in the upcoming change! It lets you drop a
`debugger` line into the app, then run `rdbg --attach` in another
terminal to get into a debug session. Neat!
Realizing that, with the keyword argument spread syntax, I don't need
to do merging, I can just. spread at the right place!
My rationale for the ordering here is: if the caller theoretically tried
to override the builder (even though I don't see why), I think we would
want to respect that. Whereas the `class` argument should be overridden
because we're safely *merging* our `.support-form` class into it.
I want to reuse this for unlabeled pet styles is why! (That's been the
immediate motivation for this refactor, but also I do just like that
it'll make support forms easier to build.)
I think helpers are fine for the simpler ones that are basically *just*
wrapper tags, but once it starts getting into `concat`, I think that's
too unfamiliar of a syntax for developers; let's bail into our usual
templating system!
I'm not sure about putting them in `application/support_form` like this.
That's cute for one-offs like `application/hanger_spinner`, because
`render partial: "hanger_spinner"` assumes the `application` view folder
by default, but that doesn't work once it's nested: it looks for a
`views/support_form` folder.
I think maybe it could soon be time to bail from the strict "view
folders belong to controllers" thing, similar to how we did for
`SupportFormHelper`, and add a `components` folder or similar? Idk, not
sure yet!
Ah right, `> label` doesn't work with how Rails will wrap broken labels
and inputs each in a `.field_with_errors` element. Fixed, and added
some basic coloring!
Instead of hand-rolling HTML, this offers helpers like `f.field`, to
help ensure the HTML is consistent, and to keep the templates more
focused on the unique form elements.
Most notable change here is extracting the pose option bubbles into a
`data-type="radio-grid"`, and pulling that into the `.support-form`
CSS. My rationale is that, unlike most fields, this field benefits from
being 100%-width, and I don't want to specify that as an override if I
can avoid it, because that's fragile-y.
Instead, I extract this into a generic type of field that
`.support-form` can use (it feels pretty reusable anyway!), and require
the caller to specify how many columns they want as `--num-columns`.
Specifically, I'm going for a more-vertical layout, cuz I want to bring
PetState over to it, and the weird grid situation wasn't gonna fit the
big pose label radios.
