New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide form_with as a new alternative to form_for/form_tag #25197

Closed
dhh opened this Issue May 30, 2016 · 35 comments

Comments

Projects
None yet
@dhh
Member

dhh commented May 30, 2016

form_tag and form_for provide two very similiar interfaces to much of the same thing. We should unify that usage and subsequent calls to field tags. Additionally, there are several deficiencies with the current helpers that I'd like to solve at the same time, now that we will have a new form method to change defaults with:

  1. Don't set DOM id or classes on the form or the fields any more. It frequently created duplicate ids and its not used often enough to warrant being a default behavior. You can easily add the id or class if need be.
  2. Don't require HTML tags, like class and id, to be wrapped in a html: {} key. There aren't a high likelihood of conflict and it complicates the default cases.
  3. Allow form fields that do not correspond to model attributes. This makes it easier to mix and match a form with some fields that correspond to a model and others that will trigger other behaviors (like sending a welcome email).
  4. Make remote: true the default. Full-page changes after submissions are rough. When using Turbolinks, a normal redirect will generate a Turbolinks.visit() call, and otherwise there's SJR. (We could consider having config.action_view.forms_remote_by_default that you could set to false, for people going old school).

Examples:

# Passing model: @post will 1) set scope: :post, 2) set url: url_for(@post)
form_with(model: @post) do |form|
  form.text_field :title # Will reference @post.title as normal
  form.text_area :description, "Overwrite @post.description if present, if not, it will still work"

  form.submit
end

form_with(scope: :post, url: posts_path) do |form|
  form.text_field :title # post[title]
  form.text_area :description, "Overwrite @post.description or ignore if it's not present"

  form.submit
end

# Submits title=X&description=Y
form_with(url: different_path, class: 'something', id: 'specific') do |form|
  form.text_field :title, 'This has is the value of the title'

  form.text_area :description, class: 'No value has been supplied here'

  form.fields(:permission) do |fields|
    # on/off instead of positional parameters for setting values
    fields.check_box :admin, on: 'yes', off: 'no'
  end

  form.select :category, Post::CATEGORIES, blank: 'None'
  form.select :author_id, Person.all.collect { |p| [ p.name, p.id ] }, blank: 'Pick someone'

  form.submit
end

There's still a fair amount of design work to deal with, especially around the FormOptionsHelper. We should move away from positional parameters entirely and replace them with named ones. But we should also try to cut down on needless options and pick better defaults. And finally we should simply drop a lot of the overly-specialized select option methods.

Note: For 5.x, form_for and form_tag should just be soft deprecations, no warnings. Then we can deprecate with a warning, perhaps, in Rails 6.x.

@dhh dhh added the actionview label May 30, 2016

@dhh dhh added this to the 5.1.0 milestone May 30, 2016

@vipulnsward

This comment has been minimized.

Show comment
Hide comment
@vipulnsward

vipulnsward May 30, 2016

Member

I can give this a try.

Member

vipulnsward commented May 30, 2016

I can give this a try.

@sgrif

This comment has been minimized.

Show comment
Hide comment
@sgrif

sgrif May 30, 2016

Member

Ideally we could implement form_for and form_tag on top of this and move it to a gem, which would lower the maintenance cost if we choose not to deprecate it (It would be incredibly painful to deprecate those)

Member

sgrif commented May 30, 2016

Ideally we could implement form_for and form_tag on top of this and move it to a gem, which would lower the maintenance cost if we choose not to deprecate it (It would be incredibly painful to deprecate those)

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh May 30, 2016

Member

That'd work for me.

On May 30, 2016, at 20:15, Sean Griffin notifications@github.com wrote:

Ideally we could implement form_for and form_tag on top of this and move it to a gem, which would lower the maintenance cost if we choose not to deprecate it.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Member

dhh commented May 30, 2016

That'd work for me.

On May 30, 2016, at 20:15, Sean Griffin notifications@github.com wrote:

Ideally we could implement form_for and form_tag on top of this and move it to a gem, which would lower the maintenance cost if we choose not to deprecate it.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Jun 28, 2016

Member

@dhh how would you create a nested form in this way? Just pass an array to :url?

form_with(model: Comment.new, url: [ @post, Comment.new ]) do |form|
  # ...
end
Member

kaspth commented Jun 28, 2016

@dhh how would you create a nested form in this way? Just pass an array to :url?

form_with(model: Comment.new, url: [ @post, Comment.new ]) do |form|
  # ...
end
@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jun 28, 2016

Member

No, I would stick with that as a parameter to model. So it's form_with(model: [ @post, Comment.new ]) do ...

Member

dhh commented Jun 28, 2016

No, I would stick with that as a parameter to model. So it's form_with(model: [ @post, Comment.new ]) do ...

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jun 28, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jun 28, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jun 28, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jun 28, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jun 28, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jun 28, 2016

@marekkirejczyk

This comment has been minimized.

Show comment
Hide comment
@marekkirejczyk

marekkirejczyk Jun 28, 2016

Contributor

I just created a pull request with a prototype - far from ready solution yet.

My considerations so far:

  • Is the general approach right (new module, new builder, using tag helpers (ie text_field) in implementation, note: I assume FormWithBuilder will not be inheriting from FormBuilder in final implementation).
  • Do we plan to deprecate tag helpers (ie text_field) at some point?
  • Implementation of url only forms (ie form_with(url: different_path) ...) - seems to be far away from model or url+scope (ie form_with(scope: :post, url: posts_path)). I think about using separate builder based on pure tag helpers (ie text_field_tag instead of text_field) would be a good idea here (one abstract problem - building tags, to concrete implementations depending on parameters), but would make it more difficult to create custom builders.
  • Any thoughts on the syntax of following?

Allow form fields that do not correspond to model attributes

Your feedback will be appreciated :)

@kaspth @dhh @vipulnsward

Contributor

marekkirejczyk commented Jun 28, 2016

I just created a pull request with a prototype - far from ready solution yet.

My considerations so far:

  • Is the general approach right (new module, new builder, using tag helpers (ie text_field) in implementation, note: I assume FormWithBuilder will not be inheriting from FormBuilder in final implementation).
  • Do we plan to deprecate tag helpers (ie text_field) at some point?
  • Implementation of url only forms (ie form_with(url: different_path) ...) - seems to be far away from model or url+scope (ie form_with(scope: :post, url: posts_path)). I think about using separate builder based on pure tag helpers (ie text_field_tag instead of text_field) would be a good idea here (one abstract problem - building tags, to concrete implementations depending on parameters), but would make it more difficult to create custom builders.
  • Any thoughts on the syntax of following?

Allow form fields that do not correspond to model attributes

Your feedback will be appreciated :)

@kaspth @dhh @vipulnsward

@marekkirejczyk

This comment has been minimized.

Show comment
Hide comment
@marekkirejczyk

marekkirejczyk Jul 10, 2016

Contributor

Just updated PR (view here). All @dhh examples from this PR are now covered.

Questions:

If id are not set by default, how do we handle for attribute in labels? i.e.:

<label for=?>Title</label>
<input type='text' name='post[title]' value='Catch 22' />

For select, collection_select, etc helpers will benefit from named parameters, i.e.

Before:

f.select :category, categories, { include_blank: "Select one" }, class: "nice"
f.collection_select(:post, :author_name, :authors, :id, :name, { include_blank: "Select one" }, class: "nice"

After:

f.select :category, categories, blank: "Select one" , class: "nice"
f.collection_select :post, :author_name, :authors, :id, :name, blank: "Select one", class: 'beauty'

Is there anything more clever we can do here?

Form fields now are allowed not correspond to model attributes. i.e.:

f.text_field :title
f.text_field :title, scope: 'custom'
f.text_field :title, scope: nil

Will generate:

<input type='text' name='post[title]' value='...' />")
<input type='text' name='custom[title]' value='...' />")
<input type='text' name='title' value='...' />")

Looks good?

On implementation side:

  • Builder now uses Tag::Base family instead of form tags helpers, so it will be easy to deprecate helpers.
  • Still todo: nested forms, get rid of old form_builder as a base, tests for all the fields methods and cases, docs

Your feedback will be appreciated @kaspth @dhh @vipulnsward.

Contributor

marekkirejczyk commented Jul 10, 2016

Just updated PR (view here). All @dhh examples from this PR are now covered.

Questions:

If id are not set by default, how do we handle for attribute in labels? i.e.:

<label for=?>Title</label>
<input type='text' name='post[title]' value='Catch 22' />

For select, collection_select, etc helpers will benefit from named parameters, i.e.

Before:

f.select :category, categories, { include_blank: "Select one" }, class: "nice"
f.collection_select(:post, :author_name, :authors, :id, :name, { include_blank: "Select one" }, class: "nice"

After:

f.select :category, categories, blank: "Select one" , class: "nice"
f.collection_select :post, :author_name, :authors, :id, :name, blank: "Select one", class: 'beauty'

Is there anything more clever we can do here?

Form fields now are allowed not correspond to model attributes. i.e.:

f.text_field :title
f.text_field :title, scope: 'custom'
f.text_field :title, scope: nil

Will generate:

<input type='text' name='post[title]' value='...' />")
<input type='text' name='custom[title]' value='...' />")
<input type='text' name='title' value='...' />")

Looks good?

On implementation side:

  • Builder now uses Tag::Base family instead of form tags helpers, so it will be easy to deprecate helpers.
  • Still todo: nested forms, get rid of old form_builder as a base, tests for all the fields methods and cases, docs

Your feedback will be appreciated @kaspth @dhh @vipulnsward.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jul 11, 2016

Member
  • Labels: Let's see what it looks like when the label code just requires an id to be set manually on the element.
  • select/collection_select: Not sure I understand the question? Looks like using named stuff is just nicer?
  • Form fields: Look good, but we should be using HTML5 tags, so close with > not />.
Member

dhh commented Jul 11, 2016

  • Labels: Let's see what it looks like when the label code just requires an id to be set manually on the element.
  • select/collection_select: Not sure I understand the question? Looks like using named stuff is just nicer?
  • Form fields: Look good, but we should be using HTML5 tags, so close with > not />.
@marekkirejczyk

This comment has been minimized.

Show comment
Hide comment
@marekkirejczyk

marekkirejczyk Jul 11, 2016

Contributor

@dhh

Labels

Labels: Let's see what it looks like when the label code just requires an id to be set manually on the element

I see 3 options:

  • Option 1: Manually add for and id:
f.label(:title, "The Title")      # or f.label("The Title", for: 'title')
f.text_field :title, id: 'title'

translates to:

<label for='title'>The Title</label>
<input type='text' name='post[title]' id='title'/>
  • Option 2: We can recommend to use nesting feature of labels:
f.label("The Title") do
  f.text_field :title
end

or shorter version:
f.label("The Title") { f.text_field :title }

or even shorter - label as an extra param of text_field:
f.text_field :title, label: "The Title"

which would translate to:

<label>The Title <input type='text' name='post[title]' /></label>
  • Option 3: Keep the old semantics and generate id i.e.
f.label :title, "The Title"
f.text_field :title

translates to:

<label for='post_title'>The Title</label>
<input type='text' name='post[title]' value='Catch 22' />

select helpers

select/collection_select: Not sure I understand the question? Looks like using named stuff is just nicer?

Is there anything else we would like to do (as we already touching *_select helpers) other then introduce named parameters and revisit parameter names?

Contributor

marekkirejczyk commented Jul 11, 2016

@dhh

Labels

Labels: Let's see what it looks like when the label code just requires an id to be set manually on the element

I see 3 options:

  • Option 1: Manually add for and id:
f.label(:title, "The Title")      # or f.label("The Title", for: 'title')
f.text_field :title, id: 'title'

translates to:

<label for='title'>The Title</label>
<input type='text' name='post[title]' id='title'/>
  • Option 2: We can recommend to use nesting feature of labels:
f.label("The Title") do
  f.text_field :title
end

or shorter version:
f.label("The Title") { f.text_field :title }

or even shorter - label as an extra param of text_field:
f.text_field :title, label: "The Title"

which would translate to:

<label>The Title <input type='text' name='post[title]' /></label>
  • Option 3: Keep the old semantics and generate id i.e.
f.label :title, "The Title"
f.text_field :title

translates to:

<label for='post_title'>The Title</label>
<input type='text' name='post[title]' value='Catch 22' />

select helpers

select/collection_select: Not sure I understand the question? Looks like using named stuff is just nicer?

Is there anything else we would like to do (as we already touching *_select helpers) other then introduce named parameters and revisit parameter names?

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Jul 11, 2016

Member

Whatever we decide with labels if would be nice to tie them to checkboxes if that's the field you're rendering. I think that's a good default for Rails to help out with. Which we could solve with the :label option.

@dhh I'm curious what you mean by this in your original comment:

form.text_area :description, "Overwrite @post.description if present, if not, it will still work"

Why should it only overwrite the description if present? And how will it work if the @post has no description?

Is there anything else we would like to do (as we already touching *_select helpers) other then introduce named parameters and revisit parameter names?

I think we have to drop down to actual code to be able to spot that.

Member

kaspth commented Jul 11, 2016

Whatever we decide with labels if would be nice to tie them to checkboxes if that's the field you're rendering. I think that's a good default for Rails to help out with. Which we could solve with the :label option.

@dhh I'm curious what you mean by this in your original comment:

form.text_area :description, "Overwrite @post.description if present, if not, it will still work"

Why should it only overwrite the description if present? And how will it work if the @post has no description?

Is there anything else we would like to do (as we already touching *_select helpers) other then introduce named parameters and revisit parameter names?

I think we have to drop down to actual code to be able to spot that.

@jonathanhefner

This comment has been minimized.

Show comment
Hide comment
@jonathanhefner

jonathanhefner Jul 12, 2016

Perhaps ids could still be generated for use with <label for="">, but it could be made obvious that they are generated. For example, choose random number when the builder is instantiated (in case there are multiple builders per page) and concat that number with an internal counter which is incremented per field.

Regardless of id generation, I like the f.text_field :title, label: "The Title" API. Using label: false could skip the label, and a default of label: true could produce whatever f.label :title would. This would give the built-in form builder most of the brevity that popular (but bloated) form builder gems have, which I think is their chief selling point.

jonathanhefner commented Jul 12, 2016

Perhaps ids could still be generated for use with <label for="">, but it could be made obvious that they are generated. For example, choose random number when the builder is instantiated (in case there are multiple builders per page) and concat that number with an internal counter which is incremented per field.

Regardless of id generation, I like the f.text_field :title, label: "The Title" API. Using label: false could skip the label, and a default of label: true could produce whatever f.label :title would. This would give the built-in form builder most of the brevity that popular (but bloated) form builder gems have, which I think is their chief selling point.

@marekkirejczyk

This comment has been minimized.

Show comment
Hide comment
@marekkirejczyk

marekkirejczyk Jul 12, 2016

Contributor

@jonathanhefner We could also add parameter to form_for tag, to generate (or not) labels by default for given form:

form_with model: @post, labels: true do
...
end
Contributor

marekkirejczyk commented Jul 12, 2016

@jonathanhefner We could also add parameter to form_for tag, to generate (or not) labels by default for given form:

form_with model: @post, labels: true do
...
end

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 12, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 12, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 12, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 12, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 12, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 12, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 13, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 13, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 13, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 13, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 13, 2016

marekkirejczyk added a commit to marekkirejczyk/rails that referenced this issue Jul 13, 2016

@claudiob

This comment has been minimized.

Show comment
Hide comment
@claudiob

claudiob Sep 15, 2016

Member

@dhh Do you envision form_with to be used by scaffolds as part of this issue?

For instance, would rails g scaffold post create a posts/_form.html.erb partial that starts with

<%= form_with(pizza) do |f| %>

replacing the current

<%= form_for(post) do |f| %>

?

Member

claudiob commented Sep 15, 2016

@dhh Do you envision form_with to be used by scaffolds as part of this issue?

For instance, would rails g scaffold post create a posts/_form.html.erb partial that starts with

<%= form_with(pizza) do |f| %>

replacing the current

<%= form_for(post) do |f| %>

?

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Sep 15, 2016

Member

Can't see why we wouldn't use form_with in scaffolds, so yes 👍

Member

kaspth commented Sep 15, 2016

Can't see why we wouldn't use form_with in scaffolds, so yes 👍

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Sep 15, 2016

Member

Indeed. I would consider form_for soft-deprecated after we get form_with.

On Sep 15, 2016, at 15:18, Kasper Timm Hansen notifications@github.com wrote:

Can't see why we wouldn't use form_with in scaffolds, so yes 👍


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Member

dhh commented Sep 15, 2016

Indeed. I would consider form_for soft-deprecated after we get form_with.

On Sep 15, 2016, at 15:18, Kasper Timm Hansen notifications@github.com wrote:

Can't see why we wouldn't use form_with in scaffolds, so yes 👍


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@nynhex

This comment has been minimized.

Show comment
Hide comment
@nynhex

nynhex Sep 16, 2016

Late to the party on this one, but I really like form_with instead of having two different methods that do almost the same thing. This is a step in the right direction.

nynhex commented Sep 16, 2016

Late to the party on this one, but I really like form_with instead of having two different methods that do almost the same thing. This is a step in the right direction.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Nov 15, 2016

Member

value is fine by me.

Member

dhh commented Nov 15, 2016

value is fine by me.

kaspth added a commit that referenced this issue Dec 13, 2016

form_with/fields: Don't output ids by default
Continuing 67f81cc where we decided not to output ids
by default in the new form helpers.

Went with @dhh's suggestion of just requiring ids on
fields being labelled:
#25197 (comment)

Seems okay enough.

@kaspth kaspth removed the attached PR label Jan 2, 2017

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Jan 2, 2017

Member

Going to mark this as done for 5.1 and pull it off the milestone, then we can dig further in 5.2 👍

Member

kaspth commented Jan 2, 2017

Going to mark this as done for 5.1 and pull it off the milestone, then we can dig further in 5.2 👍

@kaspth kaspth added the pinned label Jan 2, 2017

@kaspth kaspth removed this from the 5.1.0 milestone Jan 2, 2017

eric1234 added a commit to eric1234/signed_form that referenced this issue Jan 22, 2017

Remove `fields` helper from being tested.
Without this we get an error as it is tested like a normal helper.
This won't work as it needs a block. It should actually be tested
exactly like `fields_for` since it is a replacement for that helper.

I considered adding tests for this helper as well as the related
`form_with` replacement of `form_for`. Decided against this for
two reasons.

1. Although some of the `form_with`/`fields` helpers have been merged
   into Rails it is not done yet and subject to change.
   rails/rails#25197
2. We are going to have to do more later anyway once this feature
   makes it's way to a release and it will get a bit messy as we'll
   have to skip tests using `form_with`/`fields` on older Rails.
   Rather than do a half-attempt now let's make a concentrated effort
   once the feature is finalized.
@PritiKumr

This comment has been minimized.

Show comment
Hide comment

👍

@Schwad

This comment has been minimized.

Show comment
Hide comment
@Schwad

Schwad Feb 24, 2017

Good work all, looking forward to playing around with this on the 5.1 beta! :)

Schwad commented Feb 24, 2017

Good work all, looking forward to playing around with this on the 5.1 beta! :)

@sevos

This comment has been minimized.

Show comment
Hide comment
@sevos

sevos Mar 18, 2017

Hey, it appears the authenticity token is not added to a form created by form_with helper, but it's added to a form created with form_tag

sevos commented Mar 18, 2017

Hey, it appears the authenticity token is not added to a form created by form_with helper, but it's added to a form created with form_tag

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Mar 20, 2017

Member

@sevos form_with generates remote forms by default, which don't output authenticity tokens in the form but rather fetch it from a meta tag in the head on submit. 😬

Member

kaspth commented Mar 20, 2017

@sevos form_with generates remote forms by default, which don't output authenticity tokens in the form but rather fetch it from a meta tag in the head on submit. 😬

@sevos

This comment has been minimized.

Show comment
Hide comment
@sevos

sevos Mar 20, 2017

Somehow it does not play along with Turbolinks. I've had to fall back to form_tag.
What was special about my form? It was a form with single file upload field (multipart: true)

sevos commented Mar 20, 2017

Somehow it does not play along with Turbolinks. I've had to fall back to form_tag.
What was special about my form? It was a form with single file upload field (multipart: true)

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Mar 20, 2017

Member

@sevos general help is best sought on Stack Overflow. We keep the issue tracker to bugs only.

But if you can find a bug and reproduce it in a sample app, we can take a look at that.

Member

kaspth commented Mar 20, 2017

@sevos general help is best sought on Stack Overflow. We keep the issue tracker to bugs only.

But if you can find a bug and reproduce it in a sample app, we can take a look at that.

@samandmoore

This comment has been minimized.

Show comment
Hide comment
@samandmoore

samandmoore Mar 21, 2017

form_with generates remote forms by default, which don't output authenticity tokens in the form but rather fetch it from a meta tag in the head on submit. 😬

Is that true even with per form authenticity tokens enabled?

form_with generates remote forms by default, which don't output authenticity tokens in the form but rather fetch it from a meta tag in the head on submit. 😬

Is that true even with per form authenticity tokens enabled?

@sevos

This comment has been minimized.

Show comment
Hide comment
@sevos

sevos Mar 21, 2017

I will try to isolate the problem!

sevos commented Mar 21, 2017

I will try to isolate the problem!

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Mar 21, 2017

Member

@sevos So there is an issue here after all, thanks for reporting! Since form_with defaults to remote forms it's best we embed authenticity tokens in the forms, so people don't have to rely on rails-ujs.

Currently the workaround is to either bundle rails-ujs or set config.action_view.embed_authenticity_tokens_in_remote_forms = true in application.rb.

👆 @samandmoore yup, when that config's enabled it works.

Member

kaspth commented Mar 21, 2017

@sevos So there is an issue here after all, thanks for reporting! Since form_with defaults to remote forms it's best we embed authenticity tokens in the forms, so people don't have to rely on rails-ujs.

Currently the workaround is to either bundle rails-ujs or set config.action_view.embed_authenticity_tokens_in_remote_forms = true in application.rb.

👆 @samandmoore yup, when that config's enabled it works.

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Mar 25, 2017

Member

Also: long since closed through #26976 and follow up commits.

Member

kaspth commented Mar 25, 2017

Also: long since closed through #26976 and follow up commits.

@krtschmr

This comment has been minimized.

Show comment
Hide comment
@krtschmr

krtschmr Apr 19, 2017

@kaspth regarding the token issue: if remote is false and token is true, there still no tokens rendered

#28796

krtschmr commented Apr 19, 2017

@kaspth regarding the token issue: if remote is false and token is true, there still no tokens rendered

#28796

ticolucci added a commit to ticolucci/rails-girls-il that referenced this issue May 10, 2017

Adjust Picture form guide to Rails5.1 generated view code
The Installation guides do not specify a rails version:
`gem install rails --no-document`

Therefore the new people will install rails 5.1 (as of today).
One of the view changes was the introduction of `form_with` instead of `form_for`:
rails/rails#25197

I updated both the 'replace the following code' sections as well as the edit code to
follow the new helper standards. (using the variable `form` instead of `f` \o/)
@PrimeTimeTran

This comment has been minimized.

Show comment
Hide comment
@PrimeTimeTran

PrimeTimeTran Jan 1, 2018

Sorry I'm a little bit late to the party, but would you guys mind giving me a pointer?
https://stackoverflow.com/questions/48053022/rails-5-1-strong-parameters-deprecated

I've read the repo's code and I'm still confused. Is there no way to use from_with for a nested route? For example, users/:user_id/friendships/:id

Sorry for the newb question! I read through the comments thoroughly and didn't spot an example of that.

Maybe if I understand I can help you guys out with documentation in the future? lol. I've always wanted to contribute to Rails

PrimeTimeTran commented Jan 1, 2018

Sorry I'm a little bit late to the party, but would you guys mind giving me a pointer?
https://stackoverflow.com/questions/48053022/rails-5-1-strong-parameters-deprecated

I've read the repo's code and I'm still confused. Is there no way to use from_with for a nested route? For example, users/:user_id/friendships/:id

Sorry for the newb question! I read through the comments thoroughly and didn't spot an example of that.

Maybe if I understand I can help you guys out with documentation in the future? lol. I've always wanted to contribute to Rails

@Schwad

This comment has been minimized.

Show comment
Hide comment
@Schwad

Schwad Jul 27, 2018

Not sure if this is mentioned elsewhere, but do we need to update actionview guides to reflect this addition? https://guides.rubyonrails.org/form_helpers.html

Lots of talk about form_tag and form_for but no form_with. If someone can verify I'm more than happy to take a crack at it. Thank you! :)

Schwad commented Jul 27, 2018

Not sure if this is mentioned elsewhere, but do we need to update actionview guides to reflect this addition? https://guides.rubyonrails.org/form_helpers.html

Lots of talk about form_tag and form_for but no form_with. If someone can verify I'm more than happy to take a crack at it. Thank you! :)

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jul 27, 2018

Member
Member

dhh commented Jul 27, 2018

@kaspth

This comment has been minimized.

Show comment
Hide comment
@kaspth

kaspth Jul 28, 2018

Member

@Schwad looks like I forgot to add it, please do! You should be able to copy a bunch of things from
https://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_with

Member

kaspth commented Jul 28, 2018

@Schwad looks like I forgot to add it, please do! You should be able to copy a bunch of things from
https://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_with

@Schwad

This comment has been minimized.

Show comment
Hide comment
@Schwad

Schwad Aug 10, 2018

Okay, I've whipped together a PR. Would appreciate a peek from @dhh or @kaspth .

Essentially I did what you recommended @kaspth - I informed the documentation from what you put together there and formatted it for the guide. I think if form_with does become the default convention (it's all I use now) then a second PR should be considered to put it ahead of form_for and form_tag in the guides.... But for now this at least includes the existing documentation in the full guide.

#33523

Schwad commented Aug 10, 2018

Okay, I've whipped together a PR. Would appreciate a peek from @dhh or @kaspth .

Essentially I did what you recommended @kaspth - I informed the documentation from what you put together there and formatted it for the guide. I think if form_with does become the default convention (it's all I use now) then a second PR should be considered to put it ahead of form_for and form_tag in the guides.... But for now this at least includes the existing documentation in the full guide.

#33523

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment