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

27 lines
839 B
Text
Raw Normal View History

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
Add analytics.openneo.net tags Self-hosted Plausible instance! I have need of usage numbers again, after a good few years of just not using it; but I don't want to send the data to Google, and I enjoy self-hosting things, so here we have it!
2023-12-04 22:42:13 -08:00
= render 'static/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"}
Render wardrobe-2020 fullscreen Tada! No more layout!
2023-08-10 18:19:03 -07:00
%body
#wardrobe-2020-root
Copy permalink