Error messages and display in Ruby on Rails - Performance & Optimization

Performance: Error messages and display

MEDIUM IMPACT

This affects page load speed and interaction responsiveness by how error messages are rendered and updated in the UI.

Displaying form validation errors after user input

Ruby on Rails

Render error messages inline next to each input field using small containers that update only changed parts.

<%= form_with model: @user do |f| %>
  <div>
    <%= f.label :email %>
    <%= f.text_field :email %>
    <% if @user.errors[:email].any? %>
      <span class="error-message" role="alert"><%= @user.errors[:email].first %></span>
    <% end %>
  </div>
<% end %>

Updating small inline error spans triggers minimal layout recalculations and avoids large container reflows.

📈 Performance GainTriggers only localized reflow and repaint, improving interaction responsiveness (INP).

Displaying form validation errors after user input

Ruby on Rails

In the view, render all error messages inside a large container that is hidden by default and shown by toggling CSS display, causing full reflow.

<% if @user.errors.any? %>
  <div id="error_explanation" style="display:block;">
    <h2><%= pluralize(@user.errors.count, "error") %> prohibited this user from being saved:</h2>
    <ul>
      <% @user.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
    </ul>
  </div>
<% end %>

Toggling display on a large container triggers a full reflow and repaint, blocking interaction and causing layout shifts.

📉 Performance CostTriggers 1 full reflow and repaint on error display, blocking interaction for ~50ms on average forms.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Toggling large error container visibility	Modifies one large container node	1 full reflow triggered	High paint cost due to large area	[X] Bad
Inline error message updates next to inputs	Modifies small inline nodes	Localized reflow only	Low paint cost	[OK] Good

Rendering Pipeline

When error messages are displayed, the browser recalculates styles and layout for affected elements, then repaints and composites the changes. Large container toggles cause more extensive recalculations.

→Style Calculation

→Layout

→Paint

→Composite

⚠️ BottleneckLayout stage is most expensive when large containers are shown or hidden.

Core Web Vital Affected

INP

This affects page load speed and interaction responsiveness by how error messages are rendered and updated in the UI.

Optimization Tips

1Render error messages inline next to inputs to minimize layout recalculations.

2Avoid toggling large containers for error display to reduce reflows and repaints.

3Use ARIA roles like role="alert" on error messages for accessibility without extra layout cost.

Performance Quiz - 3 Questions

Which pattern reduces layout shifts when showing form error messages?

A Reload the entire page to show errors

B Update small inline error elements next to inputs

C Toggle visibility of a large error container wrapping all messages

D Use alert() popup for errors

DevTools: Performance

How to check: Record a performance profile while triggering error messages. Look for Layout and Paint events after error display.

What to look for: Long Layout times and large Paint areas indicate inefficient error rendering.

Practice

1. In Rails, which method provides a list of user-friendly error messages for a model's validation errors?

easy

A. @model.errors.count

B. @model.errors.details

C. @model.errors.keys

D. @model.errors.full_messages

Solution

1. Step 1: Understand error message methods

   @model.errors.full_messages returns an array of readable error strings, while others return metadata or counts.

2. Step 2: Identify user-friendly output

   Only full_messages gives clear, complete error messages suitable for display.

3. Final Answer:

   @model.errors.full_messages -> Option D

4. Quick Check:

   Error messages = full_messages [OK]

Hint: Use full_messages for readable error text [OK]

Common Mistakes:

• Using errors.details which gives error codes, not messages
• Using errors.keys which lists fields, not messages
• Using errors.count which returns number, not messages

2. Which of the following is the correct way to display error messages for a @user model in a Rails view?

easy

A. <%= @user.errors.full_messages.each do |msg| %> <%= msg %> <% end %>

B. <% @user.errors.full_messages.each do |msg| %> <%= msg %> <% end %>

C. <%= @user.errors.full_messages.map { |msg| content_tag(:p, msg) } %>

D. <% @user.errors.full_messages.map { |msg| content_tag(:p, msg) } %>

Solution

1. Step 1: Understand ERB tags for iteration

   <% %> runs Ruby code without output; <%= %> outputs the result. For loops, use <% %>.

2. Step 2: Identify correct syntax for displaying messages

   <% @user.errors.full_messages.each do |msg| %>

   <%= msg %>

   <% end %> correctly uses <% %> to loop and <%= %> inside to output each message.

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   Loop with <% %>, output with <%= %> [OK]

Hint: Use <% %> for loops, <%= %> for output inside loops [OK]

Common Mistakes:

• Using <%= %> for loops causing unwanted output
• Using map without outputting results
• Mixing output and code tags incorrectly

3. Given this Rails code in a view:

<ul>
  <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
  <% end %>
</ul>

What will be the output if @post.errors.full_messages contains ["Title can't be blank", "Content is too short"]?

medium

A. Title can't be blankContent is too short

B. Title can't be blankContent is too short

C. Title can't be blankContent is too short

D. No output because of syntax error

Solution

1. Step 1: Understand the loop output

   The code loops over each error message and wraps it in
2. tags inside a <ul>.

3. Step 2: Match output to HTML structure

   The output will be a <ul> list with two
4. items showing each error message.

5. Final Answer:

   <ul><li>Title can't be blank</li><li>Content is too short</li></ul> -> Option A

6. Quick Check:

   Loop creates list items inside ul [OK]

Hint: Errors inside <li> tags within <ul> show as list [OK]

Common Mistakes:

• Forgetting <ul> tags causing invalid HTML
• Not using <li> tags for each message
• Confusing output with plain text

4. You wrote this code to display errors:

<%= @article.errors.full_messages.each do |msg| %>
  <p><%= msg %></p>
<% end %>

But no errors show up in the browser. What is the problem?

medium

A. The <code><p>s

B. You must call to_s on each message before displaying

C. Using <code><%= %>s

D. The errors array is empty, so nothing shows

Solution

1. Step 1: Check ERB tag usage for loops

   Using <%= %>each, which is the original array, not the loop content.

2. Step 2: Correct loop tag usage

   Use <% %> for loops to run code without output, then use <%= %> inside for each message.

3. Final Answer:

   Using <%= %> for the loop causes output of the array, not the messages -> Option C

4. Quick Check:

   Use <% %> for loops, not <%= %> [OK]

Hint: Use <% %> for loops, <%= %> for output inside loops [OK]

Common Mistakes:

• Using <%= %> for loops causing wrong output
• Assuming errors are empty without checking
• Misunderstanding HTML tag usage inside loops

5. You want to display error messages only if there are any errors on the @comment model. Which is the best way to do this in a Rails view?

hard

A. <% if @comment.errors.any? %>
<div role='alert' aria-live='assertive'>
<ul>
<% @comment.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

B. <div>
<ul>
<% @comment.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>

C. <% if @comment.errors.count > 0 %>
<p>Errors found</p>
<% end %>

D. <% unless @comment.errors.empty? %>
<p>Please fix errors</p>
<% end %>

Solution

1. Step 1: Check for errors presence

   Use errors.any? to check if there are any errors to display.

2. Step 2: Display errors accessibly

   Wrap errors in a div with role='alert' and aria-live='assertive' for screen readers to announce changes.

3. Step 3: Loop and show messages

   Use full_messages inside a ul with li for each error message.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Check errors.any? and use accessible alert div [OK]

Hint: Use errors.any? and role='alert' div for accessible errors [OK]

Common Mistakes:

• Not checking if errors exist before displaying
• Missing accessibility roles for error containers
• Displaying generic messages without details