Commit graph

142 commits

Author SHA1 Message Date
8a8dd468be Improve handling of image hash pet names on the homepage
Closes #3, by adapting the suggested changes! Thank you!!

We both change how we create pet name preview jobs, by catching the `@`
case early; and we better handle symbols in pet names when showing the
thank you message, by parsing the query string more correctly.

Co-Authored-By: Steve C <diceroll123@gmail.com>
2024-09-09 18:25:56 -07:00
903fb19d5c Remove some unused code from outfits/new.js
This whole file could probably be made a LOT smaller and simpler but
hey, I'm not in the mood lol!
2024-09-09 18:11:03 -07:00
0e314482f7 Set Prettier default to tabs instead of spaces, run on all JS
I haven't been running Prettier consistently on things in this project.
Now, it's quick-runnable, and I've got it on everything!

Also, I just think tabs are the right default for this kind of thing,
and I'm glad to get to switch over to it! (In `package.json`.)
2024-09-09 16:11:48 -07:00
71ffb7f1be Add the slide-out "Customize more" label back to item preview button
I skipped this for a bit because I couldn't think of a simple way to
adapt this behavior to a web component + vanilla CSS setting, but then
I thought of CSS variables, and sat down and cranked this out!
2024-09-09 13:05:42 -07:00
27774d908f Better error handling for item page preview HTTP error
If something goes wrong, like the site goes down or has an intermittent
error, try a full pageload. That way, we're both retrying, and in a way
that gives the user more control and visibility into what's going on,
and what they can potentially do about it. (e.g. if there's a useful
error message, they will see it!)
2024-09-08 13:36:30 -07:00
c9f2d660bc Handle crash on new item page when SWF asset has no image available 2024-09-06 17:57:18 -07:00
d69c37089e Fix bug where item preview loading indicator sometimes doesn't delay
The loading indicator *should* fade in after two seconds, to avoid a
flash of a loading indicator when the page loads quickly - but in some
circumstances it wouldn't delay:

1. Visit an item page. (It delays correctly the first time!)
2. Click "Infinite Closet", then click a link to another item page.
3. The loading indicator appears immediately, because this time the
   web component JS is already loaded, so the `outfit-layer` elements
   enter `:state(loading)` *immediately*. The element starts at
   `opacity: 1`, and the delay doesn't matter, because it was never at
   anything else.

In this change, we have the `outfit-viewer` web component take on a
`:state(after-first-frame)`, after a `setTimeout(0)` resolves. That
enables the loading state CSS to *never* apply on the first frame, but
then sometimes kick in on the *second* frame, so that the element is
correctly perceived as "transitioning" from hidden to visible, and the
two-second delay will apply.
2024-09-06 12:13:10 -07:00
4d5b583432 Remove some unnecessary console messages for new outfit viewer
For static image layers, this was *always* logging that we failed to
send the frame a "pause" message. Which, like, of course!

It makes sense to log the notable circumstance where we send a message
we *expect* to arrive, but the frame isn't loaded yet. But if there's
just no frame, ignore it and don't bother to say so.
2024-09-05 17:37:16 -07:00
2e48376c5a Auto-submit the species color picker on change, for new item previews 2024-09-05 17:34:54 -07:00
4c44f8d6a4 Fix species face picker going inert again after Turbo frame load
Here, I remember the trick I learned when building the outfit viewer:
web components are great for making sure stuff stays initialized well
in a Turbo environment!

The problem was, after submitting the form and getting a new preview
loaded via Turbo, the part where we remove `inert` would get undone.
Additionally, this script only loads *once* per session, so if you
Turbo-nav to a different item then that part of the page never ran.

Instead, we use web components to remove the attributes on mount, then
again if they're ever reapplied by Idiomorph.
2024-09-03 17:07:53 -07:00
a184c75575 Handle noscript for the new species face picker
We mark the options as `inert` and `aria-hidden` while the JS is still
loading—and if the `noscript` tag tells us it's never coming, it covers
up the picker with a brief explainer!
2024-09-03 13:46:55 -07:00
c06c297174 Extremely lo-fi new species face picker for simplified item previews
The basics are working great! There's a few known missing things though:
- Add reasonable noscript behavior
- Disable options where there's no valid appearance
- Lay it out actually _good_, instead of just images dumped there
2024-09-03 13:30:12 -07:00
5cbab5a766 Merge branch 'main' into simpler-item-previews 2024-08-31 12:50:56 -07:00
af8dd42830 Add better support for hashed pet names
Closes #2, after making some tweaks to the PR to fit how JS templating
works here. Thanks @dice!!

I had to move `petThumbnailUrl` out of the closure, because this script
does a cute thing of having separate variable scopes for the separate
areas of the page—but this is used by two of them. Arguably it could
make sense to like, put this all in one larger shared IIFE closure that
wraps both of them, to preserve some of this code's intention of
avoiding adding to the global namespace on this page, but like.
*It's fine.*

Co-Authored-By: Steve C <diceroll123@gmail.com>
2024-08-31 12:07:52 -07:00
8ad0025e32 A few more comments and code style refactors for item previews 2024-08-30 17:09:39 -07:00
20202b5cd9 Potentially improve loading state in new item page preview
I thiiiink I've seen the status of a movie `<outfit-layer>` sometimes
be `loading` even when it's clearly already loaded and running. I
haven't been able to track down where and how that happens exactly, so
this is me acting on a hunch: that maybe the
I-would-have-thought-very-unlikely event that the iframe finishes
loading before the `<outfit-layer>` connects with its children maybe
happens more often than one might think!

In this change, we set up the iframe to receive `requestStatus`
messages, which it responds to with the status immediately. And we send
one of these when the `<outfit-layer>` first discovers the iframe.

Fingers crossed!
2024-07-08 16:44:22 -07:00
b03fee8c7e Save playing state to a cookie for the new item page preview 2024-07-08 16:27:38 -07:00
1aba4f405e Add hacky play/pause toggle to new item page preview
This doesn't do a good job maintaining state across morphs, but hey
it's Working At All in terms of wiring, and that's good!!

Also need to style up the toggle as a cute button instead of a visible
checkbox and the words "Play/pause"!
2024-07-08 13:43:28 -07:00
7688caebe1 Handle iframe outright failing to load in new item page preview
This is a nice extra error handler to have, but note that it *won't*
catch the case where the iframe successfully loads but the page returns
a bad status code. In this case, we'll just show the loading state
forever.
2024-07-08 10:44:01 -07:00
d18f43d769 Fix a bug transitioning between two loading states in item page preview 2024-07-07 21:52:38 -07:00
57c08b5646 Use "morphing" for smoother item page preview changes
The most notable thing here is that we keep the movie iframes running!
So if you're trying different pets for an animated item, the animation
keeps going while the new pet layers load alongside it.

This is also nice for like, the species/color picker form, so we're not
taking away input elements from people who depend on e.g. keyboard
focus.
2024-07-03 21:52:43 -07:00
97e6c39402 Load movies in iframe for new item page preview
Hey hey, it's working! Still stuff to add like pause/play, but yeah!
2024-07-03 20:29:04 -07:00
5b2062754d swf_assets/show action to embed a canvas movie in a sandboxed iframe
Not using this on the item page preview yet, but we will!

I like this approach over e.g. a web component specifically for the
sandboxing: while I don't exactly *distrust* JS that we're loading from
Neopets.com, I don't like the idea of *any* part of the site that
executes arbitrary JS unsafely at runtime, even if we theoretically
trust where it theoretically came from. I don't want any failure
upstream to have effects on us!

I copied basically all of the JS from a related project
`impress-media-server` that I had spun up at one point, to investigate
similar embed techniques. Easy peasy drop-in-squeezy!
2024-07-03 19:50:41 -07:00
e9145251a9 Refactor outfit-layer component to use internal state API, not attrs
Oh right okay, attributes like `status="loading"` are more of an API
for the caller, whereas the internal state API is where you wanna put
things that are meant to be used in CSS selectors and stuff.
2024-07-02 22:34:51 -07:00
3c415e9cd3 Refactor item page outfit-layer to use Web Components
Instead of doing all this listening to Turbo events etc to know when
outfit layers might have changed, making it a custom element and wiring
in the behavior to its actual lifecycle makes it always Just Work!
2024-07-02 22:24:26 -07:00
1cbcb5bcd6 Add trade warning to closet list form
Just a lil blurb to make sure it's clear that NC sales and stuff are
forbidden! I imagine the people doing it know this, but I want to make
sure we're being explicit, in case there's any element of
miscommunication.
2024-04-16 16:53:30 -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
684dcb53ba Add Turbo to speed up the app, and set up for missing UJS features
Oh right, we don't have Rails UJS going on anymore, which is what
handled the confirmation prompts for deleting lists. Turbo is the more
standard modern solution to that, and should speed up certain
pageloads, so let's do it!

Here I install the `turbo-rails` gem, then run `rails turbo:install` to
install the `@hotwired/turbo-rails` npm package. Then I move
`application.js` that's run all on pages but the outfit editor into our
section of JS that gets run through the bundler, and add Turbo to it.

I had to fix a couple tricky things:

1. The outfit editor page doesn't play nice with being swapped into the
   document, so I make it require a full page reload instead.
2. Prefetching the Sign In link can cause the wrong `return_to` address
   to be written to the `session`. (It's a GET request that does, ever
   so slightly, take its own actions, oops!) As a simple hacky answer,
   we disallow prefetching on that link.

Haven't fixed up the UJS stuff for confirm prompts to use Turbo yet,
that's next!
2024-03-13 13:43:48 -07:00
1a1615e0ad Oops, fix regression of editor features on item lists page
I changed the type of this tag without realizing the JS references it
by both class and `div`!

I think at the time this was a perf suggestion for jQuery, because the
best way to query by class name was to query by tag first then filter?
It's possible our jQuery still does this, but I don't imagine it's very
relevant today, so I'll just remove that for better guarding against
similar bugs in the future instead.
2024-02-22 15:52:40 -08:00
583f3c712f High-level caching for closet lists
Okay, so I still don't know why rendering is just so slow (though
migrating away from item translations did help!), but I can at least
cache entire closet lists as a basic measure.

That way, the first user to see the latest version of a closet list
will still need just as much time to load it… but *only* the ones that
have changed since last time (rather than always the full page), and
then subsequent users get to reuse it too!

Should help a lot for high-traffic lists, which incidentally are likely
to be the big ones belonging to highly active traders!

One big change we needed to make was to extract the `user-owns` and
`user-wants` classes (which we use for trade matches for *the user
viewing the list right now*) out of the cached HTML, and apply them
after with Javascript instead. I always dislike moving stuff to JS, but
the wins here seem. truly very very good, all things considered!
2024-02-20 18:43:39 -08:00
13b92b30d0 Replace old stickUp dependency with position: sticky
From an era when we didn't have that! Now we do!

(My motivation is that I'm trying to add new JS to this page and errors
in stickUp are crashing the page early, womp womp!)
2024-02-20 18:33:23 -08:00
7efe795edb Move JS library files into a new lib folder
Just sorting things a bit cleaner!
2024-02-18 20:40:16 -08:00
1e11db93cc Delete unused modeling.js.jsx file
I think I cleared this from the outfits/new template a while ago, but
never cleaned up this file, because I was too anxious that I was
correctly identifying all its call sites. But now I'm more confident!
2024-02-18 20:38:15 -08:00
df4ea967c6 Remove now-unnecessary polyfill for the placeholder attribute
Long unnecessary, in fact!
2024-02-18 20:36:45 -08:00
95ff69ee9a Run Prettier on some of our JS assets
The motivation is that I'm about to change one of them to remove a
reference to an old placeholder library, so I want that change to be
clear!
2024-02-18 20:34:55 -08:00
0d23412fba Merge pet_query.js into its only call site 2024-02-18 20:32:24 -08:00
496b517e74 Delete unused Javascript libraries
At least, they seem unused to me on a quick audit! The scriptaculous
stuff has long been replaced by jQuery UI equivalents. (Wow, so many
generations of libraries! lol)
2024-02-18 20:30:08 -08:00
82be7fe301 Move most fundraising files into a Fundraising module
Mostly this is just me testing out what it would look like to
modularize the app more… I've noticed that some concerns, like
fundraising, are just not relevant to most of the app, and being able
to lock them away inside subfolders feels like it'll help tidy up
long folder lists.

Notably, I haven't touched the models case yet, because I worry that
might be a bit more complex, whereas everything else seems pretty
well-isolated? We'll try it out!
2024-02-18 20:12:14 -08:00
b28459c1cf Oops, fix silly bug keeping the bulk list form open all the time
Lol I forgot to interpolate the `value` variable into the cookie and
just always set it to open lmao
2024-01-23 04:40:05 -08:00
0c615043f2 Persist item user lists form open/closed state across pageloads
Using good ol'-fashioned cookies! The JS sets it, and then Rails reads
it on pageload. That way, there's no flash of content for it to load in
after JS loads.
2024-01-23 04:30:23 -08:00
0011fdf76a Move user bulk lists form into a toggleable form, not a dialog
My intent is to next add behavior to save this state across pageloads,
for power users to not have to always reopen it!
2024-01-23 04:20:03 -08:00
507b346c2c Move item lists bulk management form to an openable dialog in the header 2024-01-21 06:20:32 -08:00
f93944d401 Oops, fix the pet preview on the homepage
Oh right, I forgot we use the `pet_types#show` endpoint there! Welcome
back lol!
2023-11-11 16:12:38 -08:00
3243a0fdd9 Remove unused Javascript utility libraries
Some of these just didn't have call sites anymore; the HTML5 shim still
did, but that URL is literally broken now lmao. Goodbye!
2023-10-25 16:24:50 -07:00
22e3f4240a Update most URLs to use HTTPS
I noticed we didn't have the little lock icon in the browser, and yeah
huh there's a lot of `http://` still floating around! Let's fix that!
2023-10-25 15:22:57 -07:00
5ba711a413 Delete outfits/show page, point to the editor instead
Now, like in DTI 2020, opening an outfit will go straight to the editor.

I'm not 100% on whether this is actually like. the superior behavior?
But I think it's good enough, and it's what the wardrobe-2020 code
expects, so let's just roll with it for now!
2023-10-24 18:02:18 -07:00
2e152735c5 Stop referencing Neopia, just do modeling inline
I hope this doesn't cause problems! But yeah, with Puma doing threading, and maybe switching to Falcon someday to get even better concurrency properties, I feel like this will probably be fine?

And it makes the UX a loootttt better, to be back in the world where all these forms just work, whew.
2023-10-23 19:05:10 -07:00
de245f96f3 Delete some unused public/assets files
Just cleaning up a bit! I'm sure there's more to remove, these were just some clear candidates: old wardrobe code, and stuff in `public` that I just fully don't recognize and don't think is doing anything? (We'll find out if something crashes though lol!)
2023-10-23 19:05:09 -07:00
4f5db2c0f0 Remove analytics placeholder code
Ehh, I don't use analytics anyway. If I do later, maybe I'll add our private Plausible code to here or something!
2023-10-23 19:05:09 -07:00
a8ee091f98 Delete unused Pledgie files
This was back when we used a third-party campaign tool! Haven't run this code in ages!
2023-10-23 19:05:05 -07:00