-
-
Notifications
You must be signed in to change notification settings - Fork 367
Update Form example #100
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
Update Form example #100
Conversation
Without specifying the action, Turbo redirect the full page to /. name="product_new" is not necessary in this specific example, it however may help newcomer to understand they can have separate route for this action (even if not recommended by the Symfony Form docs). Not sure if it is a bug in turbo or me doing wrong, adding this fixes it.
Hey @pierrejoye - thanks for this… and moving it from the split ;). I’m not familiar with this specific bad behavior with a blank action. Does the form submit to the wrong url for you? You mentioned it redirected - was that after a successful form submit, or did it redirect after an unsuccessful form submit to the wrong page? EDIT: oh, is your form in a turbo-frame? Indeed, in that case, with no action, it’s very easy to end up with that form on a url that doesn’t match the form submit. And then, the form submits to the wrong (current) url. We should specify the action more consistently to avoid this problem. The question is, as a general recommendation, whether we should show the action being passed when creating the form in PHP or via form_row() in Twig. I kind of prefer the latter, but I don’t have a strong reason. Cheers! |
src/Turbo/README.md
Outdated
@@ -176,6 +180,17 @@ $builder | |||
] | |||
]); | |||
``` | |||
> **NOTE Turbo ^7.0.0-beta.5:** | |||
> If Turbo ^7.0.0-beta.5 or lower (may be still valid with future version), there is a bug with turbo-frame and form submit. F.e., a link to add a product will work the 1st time, the frame will have the new product form, on submit, the frame will be updated using the products listing. At this point the new link won't work anymore. This is cache issue in Turbo. To avoid it add a ramdom value as get parameter, microtime(true) will make it unique for one client: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should verify, but I think this is fixed on beta 7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weaverryan yes, I will test master or latest release later today. For the time, may I suggest to keep the note? Took some time to dig the issues reports and the turbo code :) I wish noone to have to do it ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I confirmed, beta.7 works as expected.
Yes, it is in a turbo-frame, it refreshes the full page at /, not the current one. Is it the expected behaviors? Reading the turbo doc, I was not expecting this as they mentioned they will follow the server redirect and update the frame. I am still discovering and taking notes of the parts I had to dig in :)
You are fully correct. I also think the examples should show the best practices, to avoid to fall into this kind of trap. :) |
Thanks @pierrejoye! |
Without specifying the action, Turbo redirect the full page to /.
name="product_new" is not necessary in this specific example, it however may help newcomer to understand they can have separate route for this action (even if not recommended by the Symfony Form docs).
Not sure if it is a bug in turbo or me doing wrong, adding this fixes it.