58

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?

Avdi
  • 18,340
  • 6
  • 53
  • 62
  • So what does your call to fields_for look like? – Frederick Cheung Jul 12 '12 at 06:16
  • Which Rack version are you using? Is it broken in previous versions as well? – rdvdijk Jul 12 '12 at 06:44
  • Not the most elegant solution, but you can use `:child_index` option and pass some random index for each new record. See [this](http://apidock.com/rails/ActionView/Helpers/FormHelper/fields_for#512-Setting-child-index-while-using-nested-attributes-mass-assignment) example. It's about adding fields for new records on the client-side, but you should get the idea. Though, it's strange that it doesn't work as is for you on the server-side. – KL-7 Jul 12 '12 at 08:07

8 Answers8

45

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.

ryanb
  • 16,227
  • 5
  • 51
  • 46
  • 4
    This is the answer I've seen a lot, and I'm really bothered by using some pseudo-random number like the object_id as a differentiator. Not to mention: exposing internal object IDs in a client-facing interface? Scary! So many attacks are based on using inadvertantly exposed internals. What really bothers me is that Rails has a perfectly good way to submit arrays of param hases: the '[]'. And if you can coerce it into leaving the '[]' alone, this works beautifully! It just tries really hard not to let you use '[]' in all the field names. – Avdi Jul 12 '12 at 17:35
  • The `object_id` isn't a necessary implementation, you can use any random value there: `id = SecureRandom.hex`. However that does not guarantee it is unique. Perhaps a hash of the object_id would be better? – ryanb Jul 12 '12 at 17:44
  • 1
    I do a agree that the behavior of inserting the id when passing in `[]` in `fields_for` is odd. AFAIK it has been this way since `fields_for` was first added. You can see that in [this episode](http://railscasts.com/episodes/75-complex-forms-part-3) at about the 3:00. – ryanb Jul 12 '12 at 17:58
  • I've confirmed that a small tweak to rails can make child_index: nil Do The Right Thing; considering submitting a PR for it. – Avdi Jul 12 '12 at 18:15
  • If the change is for Rails 4, maybe it should not mess with the `[]` at all by default. I can't think of a case where the inconsistency of inserting the id is wanted. – ryanb Jul 12 '12 at 18:24
  • My solution takes a blank fields "template" and in the client side it adds new fields assigning a timestamp identifier for each name attribute of every input inside the []. Works for any level of nesting, and is more generic on the server side. It is incomplete in the sense that is not packed as a rails plugin but really doesn't take much effort to use. In the example I used formtastic but works the same with plain rails form helpers. – Macario Jul 12 '12 at 19:50
  • 6
    @Avdi, I understand your anoyance, but once you start with deeper levels of nesting you need a way to relate child fields with their parent models. Think `Exam has many questions, question has many possible answers` and in one form you want to create many questions and many answers for each question, so the name for an answer field has to be `exam[questions_attributes][123][answers_attributes][321][answer_text]` and for a question `exam[questions_attributes][123][question_text]`. Note that the pseudo id (123) has to correspond between the question and its associated answers. – Macario Jul 12 '12 at 21:47
  • The only requirement for this pseudo id is that it has to be unique and it has to correspond for fields with a deeper nesting, it doesn't have to be the actual record id, and it has to be set on the client side when injecting new fields into the DOM, thus on the serverside you will get a hash with the correct hyerarchy of relationships. – Macario Jul 12 '12 at 21:50
  • Thank you for the clarification Marcario, I could not remember the reason hashes were preferred over arrays and you're correct. It is necessary for deep nesting. – ryanb Jul 12 '12 at 23:42
  • @Macario thanks very much for this answer. I had a suspicion that there was some deeper reason I was missing for Rails to favor always generating indices. This makes a lot of sense. – Avdi Jul 13 '12 at 17:48
  • While I may not change the project in question, with that clarification from @Macario, I'm going to mark this answer "accepted" so that others who come along later are not led down a path which may eventually get them into trouble. Thanks all! – Avdi Jul 13 '12 at 17:55
  • 2
    P.S. I still think this is way too confusing for newbs. "Oh, you'll need to munge the field names in JS" doesn't seem like a very batteries-included way of handling this fairly common case :-/ – Avdi Jul 13 '12 at 17:59
23

So, I was not happy with the solution I saw most often, which was to generate a pseudo-index for new elements, either on the server or in client-side JS. This feels like a kludge, especially in light of the fact that Rails/Rack is perfectly capable of parsing lists of items so long as they all use empty brackets ([]) as the index. Here's an approximation of the code I wound up with:

# note that this is NOT f.fields_for.
fields_for 'parent[children_attributes][]', child, index: nil do |f|
  f.label :name
  f.text_field :name
  # ...
end

Ending the field name prefix with [], coupled with the index: nil option, disables the index generation Rails so helpfully tries to provide for persisted objects. This snippet works for both new and saved objects. The resulting form parameters, since they consistently use [], are parsed into an array in the params:

params[:parent][:children_attributes] # => [{"name" => "..."}, {...}]

The Parent#children_attributes= method generated by accepts_nested_attributes_for :children deals with this array just fine, updating changed records, adding new ones (ones lacking an "id" key), and removing the ones with the "_destroy" key set.

I'm still bothered that Rails makes this so difficult, and that I had to revert to a hardcoded field name prefix string instead of using e.g. f.fields_for :children, index: nil. For the record, even doing the following:

f.fields_for :children, index: nil, child_index: nil do |f| ...

...fails to disable field index generation.

I'm considering writing a Rails patch to make this easier, but I don't know if enough people care or if it would even be accepted.

EDIT: User @Macario has clued me in to why Rails prefers explicit indices in field names: once you get into three layers of nested models, there needs to be a way to discriminate which second-level model a third-level attribute belongs to.

Avdi
  • 18,340
  • 6
  • 53
  • 62
  • I've run into this problem several times, and I always end up just generating the field names myself. I'd definitely use the option if it were there and worked. – bhollis Jul 13 '12 at 16:27
  • Same here. This is something I fight with, every time I need to do master-children forms in Rails. – kolrie Jul 13 '12 at 16:29
  • I believe the reason Rails prefers a hash over an array is to make multiple attributes work reliably: `foo[bar][][zap]` and `foo[bar][][zip]` need to be associated with the same record. This problem is amplified when there are deeply nested records. Macario mentions this in another comment. – ryanb Jul 13 '12 at 16:33
  • AFAICT, this will cause problems if the order of the children isn't deterministic. For example, in a has-many relation, unless you always order the children by the same column, your relational database could return the children in an unexpected order. This would cause the wrong param values to be applied to children. – nickh Jul 13 '12 at 16:52
  • @ryanb thanks for that clarification. It seems to work fine in my tests; I assume it works based on order. However, I'm now mindful of Macario's warning about multiply-nested models in one form. – Avdi Jul 13 '12 at 17:51
  • have been playing with this - i keep getting an error that says "`@[_attributes]' is not allowed as an instance variable name" – dax Jul 05 '13 at 07:48
  • I got it finally using this as a guide. Thanks! http://stackoverflow.com/questions/17527384/how-to-dynamically-add-nested-attributes-in-rails-with-jquery – dax Jul 11 '13 at 12:20
  • I got it after adding `children_attributes: [:id, :attr1, :attr2]` to .permit in child_params method in the children_controller. Also I included a `<%= f.hidden_field :id, :value => f.object.id %>`. – kadrian Aug 06 '14 at 20:01
14

The common solution is to add a placeholder into [], and replace it with a unique number on inserting the snippet to the form. Timestamp works most of the time.

julian7
  • 311
  • 1
  • 5
3

Maybe you should just cheat. Put the new records in a different faux attribute that is a decorator for the actual one.

parent[children_attributes][0][fieldname]
parent[new_children_attributes][][fieldname]

It's not pretty, but it should work. It might take some extra effort to support round-trips to the form for validation errors.

Josh Susser
  • 31
  • 2
  • It flabbergasts me that I would need to do this. And, in fact, I could swear I didn't need to do this in the past. – Avdi Jul 12 '12 at 06:25
  • Oh, and also: the ability for `accepts_nested_attributes_for`-generated setters to accept multiple new (ID-less) attribute hashes and create new records for all of them while saving updated records is *explicitly documented*, suggesting that this is supposed to be totally doable. – Avdi Jul 12 '12 at 06:28
3

long post deleted

Ryan has an episode on this: http://railscasts.com/episodes/196-nested-model-form-revised

It looks like you need to generate the unique index manually. Ryan uses the object_id for this.

akjoshi
  • 15,374
  • 13
  • 103
  • 121
Arctodus
  • 5,743
  • 3
  • 32
  • 44
3

I've came across this user case in all my last proyects, and I expect this to continue, as julian7 pointed, it is necesary to provide a unique id inside the []. In my opinion this is better done via js. I've been dragging and improving a jquery plugin for dealing with this situations. It works with existing records and for adding new records but expects a certain markup and it degrades gracefully, heres the code and an example:

https://gist.github.com/3096634

Caveats for using the plugin:

  1. The fields_for call should be wrapped in a <fieldset> with data-association attribute equal to the pluralized name of the model, and a class 'nested_models'.

  2. an object should be built in the view just before calling fields_for.

  3. the object fields perse should be wrapped in a <fieldset> with class "new" but only if the record is new (cant remember if I removed this requirement).

  4. A checkbox for the '_destroy' attribute inside a label must exist, the plugin will use the label text to create a destroy link.

  5. A link with class 'add_record' should exist within the fieldset.nested_models but outside the fieldset enclosing the model fields.

Appart from this nuisances its been working wonders for me.
After checking the gist this requirements must be clearer. Please let me know if you improve on the code or if you use it :).
BTW, I was inspired by Ryan Bates first nested models screencast.

Macario
  • 2,214
  • 2
  • 22
  • 40
1

I think you can make it work by including the id of the record as a hidden field

jeffrydegrande
  • 11
  • 1
  • 1
1

There is a gem called cocoon for doing this, I would go for a leaner mor DIY aproach but it was specifically built for this cases.

Macario
  • 2,214
  • 2
  • 22
  • 40