Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wip: adjustment reason edit with turbo-frame link and turbo template with no index #6045

Closed
wants to merge 3 commits into from

Conversation

chaimann
Copy link

Summary

This is a draft PR to collect feedback on the proposed solution. If it looks good, I'll make changes to other routes that open modals in admin.

This addresses #6014 (comment) as a potential solution to the index table being loaded on visiting a route rendered within a modal.

  • removes the parts that load data in controller and render a table inside edit component
  • adds links to table cells with data-turbo-frame ids
  • on link click navigates turbo-frame to provided route, rendering only a turbo-frame tag (with layout: false)
  • adds an easy way to set "turbo" actions within a controller, which upon registering will make sure that given actions cannot be performed in a non-turbo-frame request (where Turbo-Frame header is not set), and instead be redirected to index
image image

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

The following are not always needed:

  • 📖 I have updated the README to account for my changes.
  • 📑 I have documented new code with YARD.
  • 🛣️ I have opened a PR to update the guides.
  • ✅ I have added automated tests to cover my changes.
  • 📸 I have attached screenshots to demo visual changes.

Copy link
Member

@tvdeyen tvdeyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this very much! I only would like us to still be able to render the new/edit routes.

There seems to be a syntax error, that's why the specs are still failing.

@@ -64,8 +64,13 @@
end

describe "GET /edit" do
it "renders the edit template with a 200 OK status" do
it "redirects when the request is not Turbo-Frame" do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we want that these routes still accessible in ie. new tabs or tests w/o javascript.

@tvdeyen
Copy link
Member

tvdeyen commented Dec 20, 2024

Test failures fixed in #6048

@tvdeyen
Copy link
Member

tvdeyen commented Dec 20, 2024

@chaimann I addressed my feedback in #6046 and cherry picked your commits. If you don't mind I would like to continue on that PR. Thanks again for building the foundation of it.

@chaimann
Copy link
Author

@tvdeyen no worries, glad I could help!
I've also been thinking about the ways how to correctly render the edit modal on edit_path visit, and came up with an idea of eagerly loading specific frame, which allows us to render only "index" component to "activate" the turbo-frame that will load a modal for our record (since we already have the empty turbo-frames rendered on index pages). With this approach there is a TurboFrame component that allows modifying its src before the frame is rendered. Maybe it could be helpful for you in your PR as well

The only downside with it is that browser will make two GET requests to /:id/edit route - one fires when we visit /:id/edit (e.g. when opening the link in a new tab), and the second one fires as soon as the page is loaded but this time it's a turbo-frame request that eager loads our modal.

Also, with dedicated edit route there are few issues that I found:

  • clicking outside modal won't close the modal
  • X does not close the modal as well
  • upon update the modal is not closed either

I'm sure, though, that these could be fixed easily

@tvdeyen
Copy link
Member

tvdeyen commented Dec 20, 2024

Also, with dedicated edit route there are few issues that I found:

  • clicking outside modal won't close the modal
  • X does not close the modal as well
  • upon update the modal is not closed either

I'm sure, though, that these could be fixed easily

I cannot reproduce those in #6046
Have you checked that one out yet?

@chaimann
Copy link
Author

@tvdeyen nope, haven't checked it yet. Just double checked in my branch, the X does not close the modal as well is not reproducible now but the other two are still there. Not sure yet what causes them though

@tvdeyen
Copy link
Member

tvdeyen commented Dec 20, 2024

@tvdeyen nope, haven't checked it yet. Just double checked in my branch, the X does not close the modal as well is not reproducible now but the other two are still there. Not sure yet what causes them though

Can you check out my branch and verify if this is still the case for you? It is not for me locally and not in tests (they are all passing). I would prefer to continue the conversation as a review of #6046 as I updated a lot more components already.

Thanks for all the great feedback. This really helps to fix the issues with the new admin

@chaimann
Copy link
Author

perfect, let's proceed in #6046

@chaimann
Copy link
Author

closing in favour of #6046

@chaimann chaimann closed this Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants