-
Notifications
You must be signed in to change notification settings - Fork 21.5k
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
form_with should default to local: false #39711
Comments
Thanks for the issue. What you are saying seems reversed to me. From the documentation for
So the the scaffold generator builds a form that has XHRs disabled by default: <%= form_with(model: article, local: true) do |form| %> To enable XHR you would need to change the generated If you are seeing something different, could you offer a way of reproducing that? I followed the steps you listed above and I was seeing the behavior I expected with normal, non-XHR form submission. |
Hi @composerinteralia ! I'm really sorry, my explanations weren't very good indeed. I'm going to start over, hopefully it's clearer this time! I probably should have started by saying that the code generated by a scaffold works perfectly. Otherwise a bunch of people would have probably noticed before me 😄 That being said, I think the code generated by a scaffold is a proof that Currently, to get a form generated with
Both of those options require some extra work, which is why I think neither is good. Currently the scaffolding went for option 2, which is a lot simpler than 1. That's a fair choice, but I think there's a better 3rd option: making |
Aha, now I am understanding you.
The scaffold generator switched over to using I agree it is awkward to have Rails generate a form with non-default options. |
I'm glad my explanations were better this time. Thanks for pointing to the relevant PRs! I believe the second PR makes sense: it's great that scaffolds use the latest and greatest features. That's cleaner, and it's a way to spread awareness of newer features.
Well, I think That why I think the decision made in the first PR was suboptimal. Don't get me wrong, I think Ajax forms are great. But getting them to work requires a lot more work, at least at the moment. So until they work out of the box in Rails (if they ever should), I think I feel like I have somewhat convinced you, hopefully other people will agree too! |
I ran rails new FooBar
cd FooBar
bin/rails generate scaffold Article title:string body:string
bin/rails db:migrate
bin/rails server then edited the form to remove What sort of problems are you having? I have used remote forms on several projects now, and I don't recall needing to do any complicated setup. |
You're right, your example does work. Thanks for taking the time to run it by the way! But it works only because it's a tiny bit too simple. As soon as there is any validation error on a model, it will stop working. For example, try to edit class Article < ApplicationRecord
validates :title, format: /foo/
end Now go ahead and try to validate the form with a title that does not contain "foo". If you leave |
Ah, right. Now that you are saying that, it does sound familiar. @seanpdoyle turned me onto turbolinks/turbolinks#85 (comment). Adding that snippet of JS is enough to get your errors rendering again. Anyway, I see your point that it does require some additional setup. @kaspth you probably have opinions here (about defaulting to remote forms in |
Another interesting thread you just found! Apparently I'm not the only one thinking this default should be changed. @jorgemanrubia said:
|
This issue has been automatically marked as stale because it has not been commented on for at least three months. |
This issue is definitely not stale and still very much present… |
I barely feel qualified to comment on this but I too think it's very odd that you have to specify a non-default option in order to get forms working properly without a lot of extra work. |
this is my biggest problem with rails at the moment - such a frustration and very much anti-"convention over configuration" |
It feels just strange that, by default, the response after the submission of a form with validation errors will not be displayed when using turbolinks (also enabled by default), especially in a framework that's all about good practices and convention over configuration. Turbolinks does not handle the See: #34839 |
Sweet! Thanks for fixing this!! |
When creating a form with
form_with
, thelocal
attributes defaults totrue
. That is a problem because it forces the unsuspecting user to handle XHR requests.I think it would be OK to make
local: true
the default value if it automagically worked out of the box. But it doesn't, and actually it breaks in very weird ways: the form doesn't seem to respond, even though a request hits the server. One need to notice that the format is set to JS, which is very non-obvious.As a matter of fact, even a new scaffold will have to specify
local: false
, which I think proves my point.Steps to reproduce
Expected behavior
Actual behavior
System configuration
Rails version: 6.0.3.2
Ruby version: 2.6.6p146
The text was updated successfully, but these errors were encountered: