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

Send turbo-action on frame request headers #594

Conversation

jarenas9539
Copy link

@jarenas9539 jarenas9539 commented Feb 23, 2024

Main Purpose

Send Turbo-Action on frame request headers to have a way to know on controller if a Turbo frame is going to realise a "navigation" (not a navigation per se, just a browser URL update. I'll keep mentioning with double quotes for the sake of clarity)

Context

In some cases could be helpful on controllers to know if a frame request is going to update the browser URL when using data-turbo-action on the trigger. Let me explain myself with a real example:

  • Devise have a helper called store_location_for used on controllers to keep track of not logged users navigation and redirect them to the last location after a login/signup.
  • Now suppose we have a page with two turbo-frames, one that is updated by a button with data-turbo-action="advance" and a lazy loaded turbo modal.
  • If user visits the page, clicks the button and open the modal, 3 requests are triggered, I'll call them A, B and C respectively. Then the user use our login button, log himself and the situation happens.
    • If we register all the request paths on controller, the user is redirected to path C, an HTML just with a turbo-frame with the modal info
    • If we avoid to register all turbo-frames using the turbo_frame_request? helper, the user is redirected to A. But B is a valid page and when he clicked the button from A a "navigation" occurred
    • In this case, expected result is being redirected to B. So we want to register A and B requests, and ignore C. But how could we identify if a frame request is causing a "navigation" or not.

That's why I think this change could be useful to differentiate these cases. I understand that turbo-action was meant to be used just to know is pushState on browser history or not, but I think is better than to rely on it instead of using other values or creating a different field.

Changes

  • setting Turbo-Action on request headers along with Turbo-Frame header
  • generating related min.js and source map
  • adding the turbo_frame_with_navigation? helper on FrameRequest (not 100% convinced with the name)

@seanpdoyle
Copy link
Contributor

Is this a duplicate of hotwired/turbo#694?

@jarenas9539
Copy link
Author

Is this a duplicate of hotwired/turbo#694?

@seanpdoyle you're right. I totally missed that one 😞

@seanpdoyle
Copy link
Contributor

Thank you for exploring this on your own! If you're interested, could you share more context to hotwired/turbo#694 explaining your use case and needs?

@jarenas9539
Copy link
Author

Thank you for exploring this on your own! If you're interested, could you share more context to hotwired/turbo#694 explaining your use case and needs?

Thanks. I'll share the context from this one there 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants