Form helpers (form_with) in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output HTML of this form_with helper?

Consider this Rails view code:

form_with(model: @post, local: true) do |form|
  concat form.label :title
  concat form.text_field :title
  concat form.submit 'Save'
end

What HTML does this generate if @post is a new record?

Ruby on Rails

form_with(model: @post, local: true) do |form|
  concat form.label :title
  concat form.text_field :title
  concat form.submit 'Save'
end

A

<form action="/posts" method="post">
  <label for="post_title">Title</label>
  <input type="text" name="post[title]" id="post_title" />
  <input type="submit" value="Save" />
</form>

B

<form action="/posts/1" method="post">
  <label for="post_title">Title</label>
  <input type="text" name="post[title]" id="post_title" />
  <input type="submit" value="Save" />
</form>

C

<form action="/posts" method="get">
  <label for="post_title">Title</label>
  <input type="text" name="post[title]" id="post_title" />
  <input type="submit" value="Save" />
</form>

D

<form action="/posts/1" method="patch">
  <label for="post_title">Title</label>
  <input type="text" name="post[title]" id="post_title" />
  <input type="submit" value="Save" />
</form>

💡 Hint

Think about what URL and HTTP method Rails uses for new records with form_with.

When @post is a new record, Rails generates a form that submits to the collection path (e.g., /posts) using POST method to create a new resource.

❓ state_output

intermediate

What is the value of the hidden input generated by form_with for an existing record?

Given this code snippet:

form_with(model: @post, local: true) do |form|
  concat form.hidden_field :id
end

If @post.id is 42, what is the value attribute of the hidden input?

Ruby on Rails

form_with(model: @post, local: true) do |form|
  concat form.hidden_field :id
end

A <input type="hidden" name="post[id]" id="post_id" value="" />

B <input type="hidden" name="post[id]" id="post_id" value="42" />

C <input type="hidden" name="post[id]" id="post_id" value="0" />

D <input type="hidden" name="post[id]" id="post_id" />

💡 Hint

Hidden fields reflect the model's attribute values.

The hidden field for :id will have the value of the model's id attribute, which is 42 here.

📝 Syntax

advanced

Which form_with syntax correctly disables remote AJAX submission?

You want to create a form that submits synchronously (not via AJAX). Which option correctly disables remote submission?

A form_with(model: @user, remote: false) do |form| ... end

B form_with(model: @user, submit_via_ajax: false) do |form| ... end

C form_with(model: @user, ajax: false) do |form| ... end

D form_with(model: @user, local: true) do |form| ... end

💡 Hint

Check the official Rails option for disabling remote forms.

The correct option to disable remote AJAX submission is local: true. The remote option is deprecated.

🔧 Debug

advanced

Why does this form_with raise an error?

Given this code:

form_with(url: posts_path, method: :post) do |form|
  concat form.text_field :title
  concat form.submit
end

Why does this raise an error?

Ruby on Rails

form_with(url: posts_path, method: :post) do |form|
  concat form.text_field :title
  concat form.submit
end

A Because <code>form.text_field</code> requires a model object to infer the field name.

B Because <code>method: :post</code> is invalid; it should be a string.

C Because <code>form.submit</code> must have a label argument.

D Because <code>url</code> option cannot be used with <code>form_with</code>.

💡 Hint

Think about what form.text_field needs to generate the input name.

When using form_with with a URL instead of a model, form helpers like text_field need an object or name to generate proper input names. Without a model or scope, it raises an error.

🧠 Conceptual

expert

How does form_with decide the HTTP method for an existing record?

When you use form_with(model: @article) and @article is persisted, which HTTP method does Rails use and why?

A Rails uses PUT because it replaces the entire resource.

B Rails uses POST because it always submits forms with POST.

C Rails uses PATCH because it updates the existing record partially.

D Rails uses GET because it fetches the resource for editing.

💡 Hint

Think about RESTful conventions for updating resources.

Rails uses PATCH method for existing records to update them partially, following RESTful conventions.

Practice

1. What is the main purpose of form_with in Rails?

easy

A. To create database tables automatically

B. To style buttons with CSS

C. To run JavaScript code on form submission

D. To create HTML forms that connect to models easily

Solution

1. Step 1: Understand what form_with does

   form_with is a helper in Rails that builds forms linked to models for easy data handling.

2. Step 2: Compare options

   Only To create HTML forms that connect to models easily describes creating forms connected to models. Others describe unrelated tasks.

3. Final Answer:

   To create HTML forms that connect to models easily -> Option D

4. Quick Check:

   form_with builds model forms = A [OK]

Hint: Remember: form_with builds forms linked to models [OK]

Common Mistakes:

• Thinking form_with styles buttons
• Confusing form_with with JavaScript functions
• Assuming form_with creates database tables

2. Which is the correct syntax to create a form for a @post model using form_with with local submission?

easy

A. form_with @post, remote: true do |form|

B. form_with model: @post, local: true do |form|

C. form_for @post, local: true do |form|

D. form_with model: @post, ajax: false do |form|

Solution

1. Step 1: Identify correct form_with syntax

   The correct syntax uses model: @post and local: true to disable AJAX.

2. Step 2: Check options for correctness

   form_with model: @post, local: true do |form| matches correct syntax. form_with @post, remote: true do |form| uses remote: true (AJAX enabled). form_for @post, local: true do |form| uses deprecated form_for. form_with model: @post, ajax: false do |form| uses invalid ajax option.

3. Final Answer:

   form_with model: @post, local: true do |form| -> Option B

4. Quick Check:

   Use model: and local: true for local form [OK]

Hint: Use model: and local: true for local forms [OK]

Common Mistakes:

• Using remote: true instead of local: true
• Using deprecated form_for helper
• Using invalid options like ajax: false

3. Given this code snippet:

form_with model: @user, local: true do |form|
  form.text_field :name
  form.submit 'Save'
end

What will happen when the user submits the form?

medium

A. The form submits data with a normal HTTP POST request

B. The form will not submit because of syntax error

C. The form sends data via AJAX without page reload

D. The form submits data but reloads the page with errors

Solution

1. Step 1: Analyze the local: true option

   Setting local: true disables AJAX, so the form submits with a normal HTTP request.

2. Step 2: Understand form submission behavior

   The form sends data via HTTP POST and reloads or redirects normally, no AJAX involved.

3. Final Answer:

   The form submits data with a normal HTTP POST request -> Option A

4. Quick Check:

   local: true means normal POST submission [OK]

Hint: local: true disables AJAX, so form submits normally [OK]

Common Mistakes:

• Assuming local: true enables AJAX
• Confusing syntax errors with correct code
• Thinking form reloads only on errors

4. Identify the error in this form_with usage:

form_with model: @article, local: true do |f|
  f.text_field :title
  f.submit
end

Why might this form not work as expected?

medium

A. The block variable f is invalid

B. Using local: true disables form submission

C. Missing = before form_with in ERB template

D. The form is missing a closing end keyword

Solution

1. Step 1: Check ERB syntax for form_with

   In ERB templates, form_with must be preceded by = to output the form HTML.

2. Step 2: Analyze other options

   Using local: true disables form submission is wrong because local: true enables normal submission. The block variable f is invalid is wrong; f is a valid block variable. The form is missing a closing end keyword is incorrect; the block is properly closed.

3. Final Answer:

   Missing = before form_with in ERB template -> Option C

4. Quick Check:

   Use <%= form_with ... %> to render form [OK]

Hint: Always use <%= form_with ... %> to render form in ERB [OK]

Common Mistakes:

• Omitting = in ERB for form_with
• Thinking local: true disables submission
• Confusing block variable names
• Forgetting to close the block

5. You want to create a form for a new @comment that submits without page reload using AJAX. Which is the correct way to write form_with?

hard

A. = form_with model: @comment do |form|

B. = form_with model: @comment, remote: true do |form|

C. = form_with @comment, local: false do |form|

D. = form_with model: @comment, local: true do |form|

Solution

1. Step 1: Understand AJAX behavior in form_with

   By default, form_with submits via AJAX unless local: true is set.

2. Step 2: Analyze options for AJAX submission

   = form_with model: @comment do |form| uses default AJAX submission. = form_with model: @comment, local: true do |form| disables AJAX with local: true. = form_with model: @comment, remote: true do |form| uses invalid remote: true (deprecated). = form_with @comment, local: false do |form| uses local: false which is not a valid option.

3. Final Answer:

   = form_with model: @comment do |form| -> Option A

4. Quick Check:

   Default form_with submits via AJAX unless local: true [OK]

Hint: Omit local: true for AJAX; default is AJAX submission [OK]

Common Mistakes:

• Using local: true disables AJAX
• Using deprecated remote: true option
• Setting invalid local: false option