Question

I have a pretty standard use-case. I have a parent object and a list of child objects. I want to have a tabular form where I can edit all the children at once, as rows in the table. I also want to be able to insert one or more new rows, and on submit have them be created as new records.

When I use a fields_for to render a series of sub-forms for nested records related by has-many, rails generates field names e.g. parent[children_attributes][0][fieldname], parent[children_attributes][1][fieldname] and so on.

This causes Rack to parse a params hash that looks like:

{ "parent" => { 
    "children" => {
      "0" => { ... },
      "1" => { ... } } }

When passed a new (un-persisted) object, the same fields_for will generate a field name that looks like:

parent[children_attributes][][fieldname]

Note the [] with no index in it.

This cannot be posted in the same form with the fields containing [0], [1], etc. because Rack gets confused and raises

TypeError: expected Array (got Rack::Utils::KeySpaceConstrainedParams)

“OK”, thinks I. “I’ll just make sure all the fields use the [] form instead of the [index] form. But I can’t figure out how to convince fields_for to do this consistently. Even if I give it an explicit field name prefix and object:

fields_for 'parent[children_attributes][]', child do |f| ...

So long as child is persisted, it will automatically modify the fieldnames so that they become e.g. parent[children_attributes][0][fieldname], while leaving fieldnames for new records as parent[children_attributes][][fieldname]. Once again, Rack barfs.

I’m at a loss. How the heck do I use standard Rails helpers like fields_for to submit multiple new records, along with existing records, have them be parsed as an array in the params, and have all the records lacking IDs be created as new records in the DB? Am I out of luck and I just have to generate all the field names manually?

Answer 1

As others have mentioned, the [] should contain a key for new records because otherwise it is mixing a hash with an array type. You can set this with the child_index option on fields_for.

f.fields_for :items, Item.new, child_index: "NEW_ITEM" # ...

I usually do this using the object_id instead to ensure it is unique in case there are multiple new items.

item = Item.new
f.fields_for :items, item, child_index: item.object_id # ...

Here’s an abstract helper method that does this. This assumes there is a partial with the name of item_fields which it will render.

def link_to_add_fields(name, f, association)
  new_object = f.object.send(association).klass.new
  id = new_object.object_id
  fields = f.fields_for(association, new_object, child_index: id) do |builder|
    render(association.to_s.singularize + "_fields", f: builder)
  end
  link_to(name, '#', class: "add_fields", data: {id: id, fields: fields.gsub("\n", "")})
end

You can use it like this. The arguments are: the name of the link, the parent’s form builder, and the name of the association on the parent model.

<%= link_to_add_fields "Add Item", f, :items %>

And here is some CoffeeScript to listen to the click event of that link, insert the fields, and update the object id with the current time to give it a unique key.

jQuery ->
  $('form').on 'click', '.add_fields', (event) ->
    time = new Date().getTime()
    regexp = new RegExp($(this).data('id'), 'g')
    $(this).before($(this).data('fields').replace(regexp, time))
    event.preventDefault()

That code is taken from this RailsCasts Pro episode which requires a paid subscription. However, there is a full working example freely available on GitHub.

Update: I want to point out that inserting a child_index placeholder is not always necessary. If you do not want to use JavaScript to insert new records dynamically, you can build them up ahead of time:

def new
  @project = Project.new
  3.times { @project.items.build }
end

<%= f.fields_for :items do |builder| %>

Rails will automatically insert an index for the new records so it should just work.