-
Notifications
You must be signed in to change notification settings - Fork 430
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
Allow Turbo Streams with GET via data-turbo-stream
#612
Allow Turbo Streams with GET via data-turbo-stream
#612
Conversation
Turbo Streams are normally supported only for [non-GET requests][0]. However there are cases where Turbo Streams responses to GET requests are useful. This commit adds the ability to use Turbo Streams with specific GET requests by setting `data-turbo-stream="true"` on a form or link. [0]: #52
If this change is accepted I'll also open a PR on https://github.com/hotwired/turbo-site to add it to https://turbo.hotwired.dev/reference/attributes. |
Is the annotation required? What consequences would we have by simply always allowing streams in response to GET? |
If there is existing code that relies on the current behaviour when choosing between stream responses and HTML responses for the same endpoint, then allowing streams in response to Adding this behaviour via an annotation means it's easy for people to use streams with This style of using a Note: edited the above to clarify the scope of this PR. There's some discussion about changing the default behaviour on #621. I think there's value in having that discussion, and we could consider whether it's something we should change in a future major version update. But, in hindsight, having that discussion here is probably distracting from the point of this PR, which is to make it easy to use stream responses with |
Need a PR to document this as well. |
Documentation is in hotwired/turbo-site#103 |
* main: Drive Browser tests with `playwright` (hotwired#609) Allow Turbo Streams w/ GET via `data-turbo-stream` (hotwired#612) Only update history when Turbo visit is renderable (hotwired#601) Support development ChromeDriver version overrides (hotwired#606) Turbo stream source (hotwired#415) Expose Frame load state via `[complete]` attribute (hotwired#487)
* main: Allow frames to scroll smoothly into view (hotwired#607) Export Type declarations for `turbo:` events (hotwired#452) Add .php as a valid isHTML extension (hotwired#629) Add original click event to 'turbo:click' details (hotwired#611) Drive Browser tests with `playwright` (hotwired#609) Allow Turbo Streams w/ GET via `data-turbo-stream` (hotwired#612) Only update history when Turbo visit is renderable (hotwired#601) Support development ChromeDriver version overrides (hotwired#606) Turbo stream source (hotwired#415) Expose Frame load state via `[complete]` attribute (hotwired#487) fix(ie/edge): form.method='delete', raises Invalid argument. (hotwired#586) Do not declare global types/constants (hotwired#524) Defensively create custom turbo elements (hotwired#483) Use `replaceChildren` in StreamActions.update (hotwired#534)
@kevinmcconnell thank you for this. It was merged at an opportune time as I'm looking to implement a "Load More"-style of pagination using Turbo Streams via GET request. On testing though I'm experiencing Turbo not including query params in <div id="posts">
...
</div>
<a href="/posts?page=2" data-turbo-stream="true">
Load More
</a> Will end up sending only I'll take a look to see if this is an easy fix but thought I'd pass it along in case the fix is obvious to you. Currently experiencing this with f5a9dba. Cheers. Update: It looks like there have been significant changes recently that may be impacting this such as #631 and #630 |
@seanabrahams oh good catch! I'm guessing this is because links with I'll try to look into this today if I can. Thanks for letting me know about it. |
@kevinmcconnell this is awesome. Looking forward to using this 👀 |
Some issues I encounteredNot sure if this is the right place to post this but here we go. Decided to update my app and remove UJS altogether. Fetched the latest beta.1 release specifically to try this feature. Couple of things I noticed:
WorkingNot working
Screen.Recording.2022-07-27.at.13.05.30.mov |
Hi @BakiVernes. The requests firing twice is, I think, a separate issue that's being addressed in #645. I've not been able to reproduce your first issue though. I'm using this outside of Turbo Frames here and it's working as expected for me. Could you share a code example that reproduces it? |
I tried this feature with the |
@thibaudgg I'll look into that (hopefully today) and will get back to you. Thanks for letting me know! |
@thibaudgg I've opened #681 to fix this. Hopefully that will fix the issue for you, but let me know if you have any questions or concerns. Thanks again for reporting! |
@kevinmcconnell thanks a lot for the quick fix, I will give it a try next week. 👍🏻 |
What should the default URL behavior be when using Currently, it stays unchanged, I was expecting it to My use case is that I tag my navigation |
Hey @bilogic, did you get any workaround here? |
@luctus no I did not |
@bilogic the behaviour is to load the new content, but not trigger a visit, which matches what you're seeing. It's consistent with Turbo Stream responses over other HTTP methods (like Perhaps we should add the ability to override this with |
Hello @kevinmcconnell, Let's say we have a to-do list. In the index view we will have all the tasks listed, you click on one (with Once the slideover is open, I want to copy the url and share it with my friend, but the url will remain being the one for the index view. Do you think this is not the right use case for this new feature? I may be super lost, tbh. Thanks a lot for your work, anyway! |
https://discuss.hotwired.dev/t/simpler-way-to-think-about-drive-vs-frame-vs-stream/4406 Because hotwire is quite "new", I think this is a good way to think about our use cases. @kevinmcconnell in your case, it seems to be click here, don't change here + change elsewhere (details), then copy and paste (which is not part of hotwire) |
Turbo Streams are normally supported only for non-GET requests. However there are cases where Turbo Streams responses to GET requests are useful.
This commit adds the ability to use Turbo Streams with specific GET requests by setting
data-turbo-stream="true"
on a form or link.