dice/impress
1
0
Fork 0
forked from OpenNeo/impress
Code Pull requests Activity
impress/app/views/outfits/edit.html.haml

30 lines
880 B
Text
Raw Permalink Normal View History

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
- turbo_page_requires_reload
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
- if @outfit
Oops, fix silly bug on /outfits/new I just plum forgot to put the title under `- if outfit`, oops!!
2023-10-24 19:10:05 -07:00
- title(@outfit.name || t('.default_outfit_name'))
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
- open_graph type: 'openneo-impress:outfit', title: yield(:title),
url: outfit_url(@outfit)
- if @outfit.image?
- open_graph image: absolute_url(@outfit.image.url)
Render wardrobe-2020 fullscreen Tada! No more layout!
2023-08-10 18:19:03 -07:00
!!! 5
%html
%head
%meta{charset: 'utf-8'}
Add viewport meta tag to wardrobe page Oops, this was causing the page to render in a weird zoomed-out way on mobile! Note that, for most of the site, we intentionally haven't added this tag yet because most of our pages aren't especially responsively-designed; so we _want_ the device's best attempt to work with that, rather than trying to enforce something.
2023-10-12 14:39:37 -07:00
%meta{name: 'viewport', content: 'width=device-width, initial-scale=1'}
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
%title
- if content_for? :title
= yield :title
| #{t 'app_name'}
Render wardrobe-2020 fullscreen Tada! No more layout!
2023-08-10 18:19:03 -07:00
%link{href: image_path('favicon.png'), rel: 'icon'}
Fix typography on wardrobe 2020 page Add the green body color back in, and add the Delicious font!
2023-08-10 20:09:30 -07:00
= stylesheet_link_tag 'fonts'
Render wardrobe-2020 fullscreen Tada! No more layout!
2023-08-10 18:19:03 -07:00
= javascript_include_tag 'wardrobe-2020-page', defer: true
Move partials in views/static to views/application I think this is the more canonical place for stuff like this these days! It's nice to be able to just say the short name when calling `render`. Here's the answer I looked up about it: https://stackoverflow.com/a/9892081/107415 My immediate motivation is that I'm looking at creating more About pages, and thinking about where to put them; I think maybe we trash the `StaticController`, move these partials out to here, and move terms into a new `AboutController`?
2024-03-10 18:47:33 -07:00
= render 'analytics'
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
= open_graph_tags
Use the main app for outfit saving, not impress-2020 This came in a few parts! 1. Add meta tags to let us know we're logged in. 2. Install React Query, which has the data-loading sensibilities I like about Apollo without the GraphQL that has honestly been a drag. 3. Replace the outfit-loading and outfit-saving calls with API calls to the main app. 4. Update the main app's API calls to use our more flexible data constructs like "pose". Would've loved to do this more incrementally, but it's hard to! You can't split out outfit-loading and outfit-saving, or auth from any of that, or the state gets all out-of-sorts. Still, this is a good nugget we've pulled out all-in-all, and one that people have been asking for! Can maybe look to logged-in item search soon too, for own/want data?
2023-11-02 13:50:33 -07:00
= csrf_meta_tags
Add support_staff flag to user record; they can use Support tools A little architecture trick here! DTI 2020 authorizes support staff requests by means of a secret token, instead of user account stuff. And our support tools still all call DTI 2020 APIs. So here, we bridge the gap: we copy DTI 2020's support secret to this app's environment variables (I needed to update `deploy/files/production.env` and run `bin/deploy:setup` for this!), then users with the new `support_secret` flag have it added to their HTML documents in the meta tags. Then, the JS reads the meta tag. I also fixed an issue in the `deploy/setup.yml` playbook, where I had temporarily commented some stuff out to skip steps one time, and forgot to uncomment them after oops lol!
2024-01-29 04:21:19 -08:00
= impress_2020_meta_tags
Use the main app for outfit saving, not impress-2020 This came in a few parts! 1. Add meta tags to let us know we're logged in. 2. Install React Query, which has the data-loading sensibilities I like about Apollo without the GraphQL that has honestly been a drag. 3. Replace the outfit-loading and outfit-saving calls with API calls to the main app. 4. Update the main app's API calls to use our more flexible data constructs like "pose". Would've loved to do this more incrementally, but it's hard to! You can't split out outfit-loading and outfit-saving, or auth from any of that, or the state gets all out-of-sorts. Still, this is a good nugget we've pulled out all-in-all, and one that people have been asking for! Can maybe look to logged-in item search soon too, for own/want data?
2023-11-02 13:50:33 -07:00
%meta{name: 'dti-current-user-id', content: user_signed_in? ? current_user.id : "null"}
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
= yield :head
Render wardrobe-2020 fullscreen Tada! No more layout!
2023-08-10 18:19:03 -07:00
%body
#wardrobe-2020-root
Copy permalink