Errors on a form field helper change the layout

A thing that caused me some friction a while back was that the form fields and label helpers end up wrapped separately with a div.field_with_errors.

This changes the layout and can break certain style with flexbox if the label and field are not sibling element.

Shouldn’t the error just be a css class on the field or the parent div.field ? I do so through ActionView::Base.field_error_proc in an initializer, but modifying the class in this proc is less than trivial.

People seems to either use nokogiri or they do it through a text search like this:

Both feels like an inefficient way to go about it instead of changing the field before it is rendered to text. It would be nice if the proc was instead a hook that could allow us to change the parameters of the field before it is rendered.

Also, I can’t find field_error_proc in the Rails api doc. So is it even public api? I imagine not.

1 Like

I used to hassle with this a lot, and made some custom templates to wrap each label/input pair with a div that could get the error class applied to it instead of each element. But lately I have been using the bootstrap_form gem, which wraps each pair in a <div class="form-group"> and puts the errors there as well.

Walter

Think this works well with some front end frameworks (eg. Bootstrap) and badly with some others(eg. Bulma). When it works, it feels magically transparent. But when it doesn’t, figuring it out is seriously irritating.

1 Like

Another issue I have with ActionView::Base.field_error_proc is that, being effectively a global variable, I can’t have a different setting from within an engine.

For example, within my admin engine, I want field errors to be rendered a certain way (and in fact I do that within my own form builder rather than relying on field_error_proc). However if the main application has set a custom field_error_proc then all bets are off.

I have a very fragile solution in place which is to reset field_error_proc before rendering the admin form. However of course that is not thread-safe. Due to the way the tag classes are intertwined in ActionView, the only other solution I can see is to subclass every single Tag class, which is not something I particularly want to do. I’d love some more ideas here if anyone has any.

Ideally I’d love to see this functionality pushed onto the FormBuilder object so it can be overridden in a subclass, but I’m not sure if that can be done in a way that’s backwards compatible.

You can find it at Configuring Rails Applications — Ruby on Rails Guides so I believe the intention is for it to be a public API.

2 Likes