Hotwire Discussion

Turbo-rails 0.5.3 form validation errors

#1

Hi everyone,

So I started playing around with turbo, faced the issue of the form validation errors and saw that it was addressed by turbo-rails 0.5.3. I upgraded the gem, ran rails turbo:install again and tried to implement it, but don’t know what I do wrong. The “new.html.erb” is rendered without full page reload, but the whole page content is replaced instead of just the frame.

I don’t have any issue when the form is submitted without errors. The new book is appended to the index, the form is reset without a full page reload and everything works, fine, I can submit again, etc. But when form validation fails, I expect to have the content of the ‘create_book’ frame to be replaced by the error div (illustration purpose) and have the rest of the page remain the same. Instead, I end up with just the error div, without the rest of the page (and without page reload). The 422 response is shown below. What am I missing ?

Code sample below:

image
image1096×1578 230 KB

Thank you very much !

PS: If you want to take a look, I played around a bit and made a full datatable with search, filter, inline cell edition, etc. (missing form validation for now though :p). Very glad to be able to do this with limited JS. Heroku so 30sec load time. https://hotwire-datatable.herokuapp.com/

#2

Greate example. Is very fast. It is available to check on an open GitHub repo?

#3

There you go https://github.com/jsagl/hotwire-datatable

I wouldn’t look too hard at the CSS though, I’m more of a backend dev :sweat_smile:

2 Likes
#4

Ok, I found out why it was not working, but don’t understand why.

I replaced in index.html.erb
<%= turbo_frame_tag 'create_book', src: new_book_path, target: '_top' %>
by
<%= turbo_frame_tag 'create_book', src: new_book_path %>

and voilà, it works. So if anybody as insights as to why it did not work / can explain what exactly is ‘target’ / how ‘target’ exactly works, I’d be happy to hear about it.

Thank you

#5

target="_top" is an attribute used on Turboframes that forces a full page visit as opposed to just the frame being replaced. You can read about it in the Turbo reference.

3 Likes
#6

I’ve run into the same situation where the whole page content is replaced instead of just the frame.

I’m guessing that with the new 4xx/5xx error handling, Turbo Drive replaces the body with the response.

If we respond with a specific Frame, the whole body will be replaced, not just the frame.

Is anyone able to confirm if this is correct and intentional?

#7

I don’t think this is intentional. As I mentioned, I managed to replace only the frame on a 422 response by removing the target: _top attribute. Are you sure you are using the latest version of turbo / of the gem ? Do you want to share your code ?

#8

You’re right. I believe the behaviour I was experiencing had to do with how I was submitting my form. I was submitting the form in my stimulus controller with Turbo.navigator.submitForm().

When I try a different approach using a hidden submit button which I click() in my stimulus controller, the frame is replaced with the new frame as desired and expected.

#9

Yes, I read somewhere that you need to submit foms using ‘click’. Using submit() won’t work.

#10

Thanks for confirming. Please do share the source if you ever remember where you read that.

#11

Found it :slight_smile: https://github.com/hotwired/stimulus/issues/92

1 Like