Handling form errors with Rails automatically?

[excid3]

When you submit a form that has errors, Rails normally renders the new action again with the form and the errors. With Turbolinks as it is setup right now, the redirects are handled nicely, but this piece requires you to build your own create.js.erb response to render the errors.

Would it make sense to add something into Turbolinks / turbolinks-rails that if you submitted a non-GET request and it returned an HTML response that it would take the URL of the request and navigate to that but render the HTML that was returned from the server?

[kevinhughes27]

I solved this by modifying $.rails.ajax like so:

$.rails.ajax = (options) ->
  op = $.ajax(options)

  op.done (response) ->
    unless response.substring(0, 10) == 'Turbolinks'
      Turbolinks.clearCache()
      document.documentElement.innerHTML = response
      Turbolinks.dispatch("turbolinks:load")
      window.scroll(0,0)

[fernandes]

@excid3

Just improving (and providing an alternative to @kevinhughes27 's answer), this is how I handle form errors in TL

I add a data-behavior="turbolinks-form" on forms I want to be handled using my JS, and then add this file under app/assets/javascripts/support/form_bindings.js

formBindings = function() {
  $('[data-behavior="turbolinks-form"').on("ajax:success", function(e, data, status, xhr) {
    return;
  }).on("ajax:error", function(e, xhr, status, error) {
    form_id = "#" + this.id;
    $(form_id).html($(form_id, xhr.responseText).html());
    return;
  });
};

$(document).on('turbolinks:load', formBindings);

the main idea is once its return a HTML rendering a form with the same id that posted, just replaces the HTML. the concept behind was to:

1. use data behaviors to separate code / data
2. bind only specific form
3. replace using id lookups and html function

so, here is my suggestion 😉

ps: after posting I re read your question, not sure if it answers yours, so I'm gonna leave it here mostly as an answer to Handling form errors with Rails automatically? then to your proper question heheh

[gregblass]

I think where I lost @sstephenson is here:

"In response to an XHR submit on the server, return JavaScript that performs a Turbolinks.visit to be evaluated by the browser."

An example would help me there, in the case where the record is saved and in the case where there are form validation errors?

EDIT: This is what I'm doing so far for the success using Turbolinks and Materialize toasts:

In my controller:

format.js {
  flash[:toast] = 'Created record successfully.'
  render :create
}

In create.js.erb:

Turbolinks.visit("<%= success_path %>");

In my _flash.html.erb partial:

<% flash.each do |type, message| %>
  <% if type == "toast" %>
    <script id="toast">
      $(function() {
        Materialize.toast('<%= message %>', 3000);
      });
    </script>
  <% elsif type == "success" %>
    ...
  <% elsif type == "alert" %>
    ... 
  <% end %>
<% end %>

EDIT 2: For validation failures, I was able to just make a new.js.erb that replaces the main part of the page with the form rendered after the object has errors on it. Not too hard and it works!

[packagethief]

Would it make sense to add something into Turbolinks / turbolinks-rails that if you submitted a non-GET request and it returned an HTML response that it would take the URL of the request and navigate to that but render the HTML that was returned from the server?

We intend to explore expanding Turbolinks to support XHR form submission in the future, so I think this is something we can consider at that time. Until then, I don't think Turbolinks should make (more) assumptions about how you might be responding to non-Turbolinks XHR requests.

Assuming you're using jQuery via Rails' UJS adapter (assumptions!), the following pattern should work well for validation errors. In create.js.erb:

<% if @message.valid? %>
  Turbolinks.clearCache()
  Turbolinks.visit("<%= message_path(@message) %>", { action: "replace" })
<% else %>
  $("form").replaceWith("<%=j render "form" %>")
<% end %>

Ensure you exclude such form-containing pages from Turbolinks' preview cache to prevent any validation errors from being displayed during a preview on the next visit.

[nerdcave]

Is there a way to just pass an HTML page string to Turbolinks and have it do the processing? I think that would really help in cases like this. I dug through the source and couldn't find a way that worked.
For example:

ajax.done (response) ->
  Turbolinks.clearCache()
  Turbolinks.render(response) #something like this exist?

Similar to @kevinhughes27's suggestion, but I think it would make more sense to pass off the DOM processing to Turbolinks to ensure some consistency in app behavior (events get dispatched properly, etc). Any way to do this?

[kevinhughes27]

Turbolinks3 used to have this as Turbolinks.replace - maybe its possible to bring back this method but not the partial replace aspects of it?

[gregblass]

I have no affiliation with GoRails or @excid3, and I'm not trying to cross any boundaries here on that front, but the screencast he did on this is very helpful and explains the code @kevinhughes27 posted in more detail. IMO its a great solution - I have implemented it myself in production.

[FloLinn]

@kevinhughes27 @acapro
you can also avoid the blinking by only replacing a part of the page.
In my project, I only replace the form object
$("form").html($("form", response).html())

[gregblass]

One issue I've found with @kevinhughes27 's modifying $rails.ajax is that then it messes up any other ajax request (like when I just want to load a partial via ajax with a standard format.js / action.js.erb file).

So it looks like I may be handling each form on a case by case basis because of that. Unless I can figure out a way to do it the other way around - that is, include something in my one off ajax requests to not fire that code off.

[gregblass]

Here's my current design pattern I've been using in my production apps:

In the controller, on a form error:

render partial: "form", status: 422

Then I use this app wide:

$(document).on("ajax:error", "form", function(e, data, status, xhr) {
  $(this).replaceWith(data.responseText);
  Turbolinks.dispatch("turbolinks:load");
  $(".field_with_errors input:first").focus();
});

And of course make all forms remote. This works great for me.

[woahdae]

@sstephenson why was this closed without comment? I was quite surprised that turbolinks 5 gets you almost out the gate with 100% CRUD coverage, except this one case you have to figure out yourself. It should still be open for discussion, no? Or (wrongly, IMO) declare "wontfix"?

[woahdae]

@gregblass Really nice solution, consider the following a "yes and."

While not good enough yet as a patch to turbolinks (I'm sure the project has its own way of parsing the body already), I think the following is more idiomatic. The whole point of turbolinks is to just code "normal" Rails, turn on turbolinks, and have everything "just work" but faster. So:

In your controller, nothing changes except currently the 422 status (Turbolinks could do that for you, like they do with the custom redirect_to):

render "edit", status: 422

Then the javascript becomes something very similar to what Turbolinks does. Again, I'm sure the project authors would do this better, but I don't feel like digging in since it's not clear there'd be any interest.

$(document).on("ajax:error", 'body', function(e, data, status, xhr) {
  $(this).html(
    data.responseText.match(
      /<body[^>]*>((.|[\n\r])*)<\/body>/im
    )[0]
  );
  Turbolinks.dispatch("turbolinks:load");

  // This is application-dependent, but a nice touch.
  $(".has-error input:first").focus();
});

Two reasons I like this approach:

1. I had no idea Turbolinks had this issue, and with NO other changes to my code (just the status: 422 bit and the JS) everything works. Personally, I use the 'form' template for just the form fields, and let 'new' and 'edit' pass in their own form objects and draw their own buttons. I could pull these in to 'form,' but that'd be coupling the organization of your views to a technical gotcha with Turbolinks.
2. It's not just the form that matters, for example I have flash message handling in the layout. With the proposed technique, the flash messages still work just fine. Sure, I could change the flash messages to be handled with JS too, but same point as before. It's supposed to "just work."

Why does this issue exist, and (again) why was it closed? Is there some edge-case reason why this must break convention over configuration?