make disable_with default in submit_tag #21135

DropsOfSerenity · 2015-08-05T16:41:05Z

I heard on the "Bike Shed" podcast that the idea of possibly making disable_with a default for submit_tag to prevent double submission by default, thought I would draft up a pull request for it and take a stab at it.

kaspth · 2015-08-05T20:02:44Z

actionview/lib/action_view/helpers/form_tag_helper.rb

      #
      def submit_tag(value = "Save changes", options = {})
        options = options.stringify_keys

-        tag :input, { "type" => "submit", "name" => "commit", "value" => value }.update(options)
+        tag :input, { "data" => {"disable_with": "Please wait..."}, "type" => "submit", "name" => "commit", "value" => value }.update(options)


Add a space after { and before }, like the outer hash has.

Also we've just stringified the keys above. So we need to use a string key here as well.

DropsOfSerenity · 2015-08-06T16:49:33Z

@kaspth updated with your style changes sir :)

rafaelfranca · 2015-08-06T16:53:46Z

actionview/test/template/form_helper_test.rb

@@ -2226,7 +2226,7 @@ def test_submit_with_object_as_new_record_and_locale_strings
      end

      expected = whole_form('/posts', 'new_post', 'new_post') do
-        "<input name='commit' type='submit' value='Create Post' />"
+      "<input name='commit' data-disable-with='Please wait...' type='submit' value='Create Post' />"


This indentation is wrong now

rafaelfranca · 2015-08-06T16:55:51Z

thank you for the work. It makes sense but I think we may have problems with with the hash update. Could you add tests that it is working with the inputs that I pointed?

DropsOfSerenity · 2015-08-06T17:22:24Z

Ok yeah, now that I fixed the tests in form_tag_helper_test I got a failing test when any other data attributes were passed in. I fixed by using deep_merge! instead of update and wrote a test to cover the base case as well.

DropsOfSerenity · 2015-08-06T17:32:14Z

ah I see that passing "data-disable-with" to the options has will also result in problems, writing a test and working on a solution.

DropsOfSerenity · 2015-08-06T18:26:23Z

Alright I've updated the code and written some tests to ensure that a user specified option is not overridden.

kaspth · 2015-08-06T19:51:11Z

actionview/lib/action_view/helpers/form_tag_helper.rb


-        tag :input, { "type" => "submit", "name" => "commit", "value" => value }.update(options)
+        tag :input, tag_options


submit_tag has changed enough that I think we need a benchmark to make sure there isn't any serious performance regression.

Sounds good, I appreciate the feedback, let me take some time tonight solidifying and benchmarking everything.

DropsOfSerenity · 2015-08-07T01:35:40Z

@kaspth So I've done some benchmarking and applied a fix.

I found that deep_stringify_keys was causing a drop of roughly 30,000 iterations per second, a loss of 37% performance approx.

After changing it to expect the symbol key for the nested hash (which ruby does anyway so it's not necessary to deep stringify) the performance normalized back to 80k ip/s.

# Rails#master
Calculating -------------------------------------
      submit_tag old     7.988k i/100ms
-------------------------------------------------
      submit_tag old     83.042k (± 2.8%) i/s -    415.376k

# Rails with updated submit_tag code
Calculating -------------------------------------
      submit_tag new     7.711k i/100ms
-------------------------------------------------
      submit_tag new     80.468k (± 2.2%) i/s -    408.683k

I think the last thing i'm trying to wrap my head around is that nested hashes by default right now are being stringified only on the base level, and not on the nested level.

e.g.

irb(main):004:0> { "data" => { "disable_with": "Please wait..." } }.stringify_keys
=> {"data"=>{:disable_with=>"Please wait..."}}

irb(main):007:0> {}.update({ "data" => { "disable_with": "Please wait..." } }.stringify_keys)
=> {"data"=>{:disable_with=>"Please wait..."}}

This would mean this is happening for other data attributes being passed in already as well. Am i missing something here?

bogdan · 2015-08-07T14:38:52Z

The default string can be longer then original label of submit. It will take extra space when change the label. It can be a problem in tough designs where there is no empty space.
It needs to be I18n-ed by default.

rafaelfranca · 2015-08-07T14:46:19Z

it needs to be I18n-ed by default.

It doesn't. If you need i18n you can just explicitly set disable_with.

rafaelfranca · 2015-08-07T14:46:49Z

The default string can be longer then original label of submit. It will take extra space when change the label. It can be a problem in tough designs where there is no empty space.

If that is the case they can just override the default.

rafaelfranca · 2015-08-07T14:47:19Z

A problem that I think is: is it possible to remove disable_with now that we are setting a default?

DropsOfSerenity · 2015-08-07T14:48:09Z

Maybe using "Saving..." instead of "Please wait..." would be a little more device friendly?

sgrif · 2015-08-07T14:50:49Z

Based on this implementation, no it doesn't look like there's a way to opt-out. Adding disable_with: false, "data-disable-with": false, or data: { "disable-with": false } should all opt-out of this behavior.

DropsOfSerenity · 2015-08-07T14:51:53Z

Alright, I'll add this functionality :)

bogdan · 2015-08-07T14:52:24Z

No I18n makes the feature only available for en apps. Others will be forced to specify something everywhere in a project. Also I18n makes it possible to disable the feature and make upgrading easier.

rafaelfranca · 2015-08-07T14:59:02Z

We don't have I18n support right now and I want to keep it out. I18n by default will slow down a lot submit_tag for applications that only use english (I bet it is something like 80% of the apps)

bogdan · 2015-08-07T15:12:40Z

@rafaelfranca so what should I do after upgrading? Go through my app and specify disable-with: false everywhere because now it shows unreadable symbols to all my users.

Did you include multi-language apps into those 80%? They would also experience problems.

What about people that don't want a change? How would they disable feature globally without modifying entire app?

I think 80% is overestimated: exclude people that don't want this feature and multi-language apps (<- most successful ones by the way).

It looks bad without ability to globally disable. We should have a way of doing it. Also we need somehow tell people in the internationalisation guide:

Please go to your AppController and extend submit_tag to support I18n because we don't support it out of the box.

I hardly image it will work without I18n. It will be top1 change request.

rafaelfranca · 2015-08-07T15:16:00Z

It looks bad without ability to globally disable.

Agree, good point.. I prefer to have it disabled globally without using i18n, but I don't want to introduce other global switch just for that, so I agree that I18n would solve this and also enable other features. 👍

derekprior · 2015-08-07T16:35:19Z

What about using the button text and just disabling the button? If you need something specific, you can override with a string or i18n otherwise the button is just disabled? Not enough user feedback?

DropsOfSerenity · 2015-08-07T16:44:07Z

Since our submit button defaults to "Save Changes" e.g

def submit_tag(value = "Save changes", options = {})

It would seem like it sense to default the text to "Saving..." and allow the user to mess with i18n or define there own disable_with as needed.

Will have some i18n changes coming through soon.

bogdan · 2015-08-07T17:51:59Z

I like @derekprior's idea. We should not aim to make a good interface - there is no consensus on what label is the best. If we just disable the button, we fix the technical issue that all of agree that needs to be addressed.

derekprior · 2015-08-07T18:00:54Z

Don't get me wrong - having a conventional place to go to override the
label without code would be great but if it really is a performance concern
then I think disabling only is a fine compromise.

That's in line with what users see today except that the button is
disabled.

On Friday, August 7, 2015, Bogdan Gusiev notifications@github.com wrote:

I like @derekprior https://github.com/derekprior's idea. We should not
aim to make a good interface - there is no consensus on what label is the
best. If we just disable the button, we fix the technical issue that all of
agree that needs to be addressed.

—
Reply to this email directly or view it on GitHub
#21135 (comment).

DropsOfSerenity · 2015-08-07T18:02:47Z

Makes sense, in that case we don't want the i18n anymore since it will just be using the value of the submit tag anyway?

DropsOfSerenity · 2015-08-07T18:29:47Z

Alright the feature can now be disabled on a per tag basis and uses the value passed in as it's default value.

The only thing missing now is if/how we want to be able to disable this feature globally.

DropsOfSerenity · 2015-08-08T02:25:46Z

What do you guys think about adding a globally configurable action_view settings like so?

# Specify whether submit_tag should automatically disable on click
cattr_accessor :automatically_disable_submit_tag
@@automatically_disable_submit_tag = true

So then users that want to disable the feature for whatever reason can set the preference in application.rb

config.action_view.automatically_disable_submit_tag = false

sgrif · 2015-08-08T03:59:02Z

I'm 👍 for adding a config to opt out, if only to aid migration.

On Fri, Aug 7, 2015, 8:26 PM Justin notifications@github.com wrote:

What do you guys think about adding a globally configurable action_view
settings like so?

Specify whether submit_tag should automatically disable on click

cattr_accessor :automatically_disable_submit_tag@@automatically_disable_submit_tag = true

So then users that want to disable the feature for whatever reason can set
the preference in application.rb

config.action_view.automatically_disable_submit_tag = false

—
Reply to this email directly or view it on GitHub
#21135 (comment).

DropsOfSerenity · 2015-08-08T04:11:24Z

Added opt out settings + a test for it.

DropsOfSerenity · 2015-08-11T17:27:40Z

Do I need to do anything further for this?

kaspth · 2015-08-11T17:44:23Z

actionview/lib/action_view/helpers/form_tag_helper.rb

      #   disabled version of the submit button when the form is submitted. This feature is
-      #   provided by the unobtrusive JavaScript driver.
+      #   provided by the unobtrusive JavaScript driver. To disable this feature for a single submit tag
+      #   pass <tt>:data => { :disable_with => false }</tt>


New hash syntax

Prevents double submission by making disable_with the default. Default disable_with option will only be applied if user has not specified her/his own disable_with option, whether that is in the `data-disable-with` string form or the `:data => { :disable_with => "Saving..." }` hash form. disable_with will default to the value attribute. A configuration option was added to opt out of this functionality if the user so desires. `config.action_view.automatically_disable_submit_tag = false`

DropsOfSerenity · 2015-08-11T23:38:28Z

Ok so in summary of recent changes:

Used new hash syntax in comment on how to disable.
Made an initial check to see if the user has disabled the feature on this specific submit tag before doing work.
Updated the logic using ||= now that the case of the user disabling the feature has been taken care of beforehand.
Used Hash#delete instead of Hash#extract!
Moved explanation of what disable_with defaults to at the end of the doc.
Removed unnecessary braces.

DropsOfSerenity · 2015-08-14T22:26:24Z

Any other ideas guys?

make disable_with default in submit_tag

sgrif · 2015-08-17T12:50:11Z

Can you add this issue number to the upgrade guide meta issue?

DropsOfSerenity · 2015-08-19T23:42:36Z

@sgrif Where can I find that?

sgrif · 2015-08-19T23:44:35Z

Just did it. Was on my phone earlier and didn't have time to search.

DropsOfSerenity · 2015-08-19T23:46:48Z

Ah thankyou I kind of had no idea what you were talking about since this is my first time contributing to rails :P but thanks :D

Should be able to remove when upgrading to Rails 5 thanks to rails/rails#21135

claudiob · 2016-03-18T20:46:15Z

It looks like this does not work with the button_to helper, where the generated code is something on the line of:

<form class="button_to" method="post" action="…">
  <button type="submit">…</button>
</form>

@DropsOfSerenity @sgrif I think we should make that happen… what do you think?

kaspth reviewed Aug 5, 2015
View reviewed changes

rafaelfranca reviewed Aug 6, 2015
View reviewed changes

kaspth reviewed Aug 6, 2015
View reviewed changes

rafaelfranca mentioned this pull request Aug 7, 2015

Add data: { disable_with: Submitting... } to forms #21160

Closed

kaspth reviewed Aug 11, 2015
View reviewed changes

sgrif added a commit that referenced this pull request Aug 17, 2015

Merge pull request #21135 from DropsOfSerenity/master

249a06d

make disable_with default in submit_tag

sgrif merged commit 249a06d into rails:master Aug 17, 2015

sgrif mentioned this pull request Aug 19, 2015

[Meta] Rails 5.0 Release Notes #20612

Closed

tjgrathwell added a commit to railsbridge/bridge_troll that referenced this pull request Sep 22, 2015

Add "disable_with" to most form submits to prevent double submission

a76c197

Should be able to remove when upgrading to Rails 5 thanks to rails/rails#21135

This was referenced Sep 2, 2016

BAU: stop Rails 5 automatically disabling submit buttons alphagov/verify-frontend#219

Merged

Default disable_with on submit_tag breaks the app if the user goes back #26366

Closed


		tag :input, { "type" => "submit", "name" => "commit", "value" => value }.update(options)
		tag :input, tag_options

make disable_with default in submit_tag #21135

make disable_with default in submit_tag #21135

Conversation

DropsOfSerenity commented Aug 5, 2015

kaspth Aug 5, 2015

Choose a reason for hiding this comment

kaspth Aug 5, 2015

Choose a reason for hiding this comment

DropsOfSerenity commented Aug 6, 2015

rafaelfranca Aug 6, 2015

Choose a reason for hiding this comment

rafaelfranca commented Aug 6, 2015

DropsOfSerenity commented Aug 6, 2015

DropsOfSerenity commented Aug 6, 2015

DropsOfSerenity commented Aug 6, 2015

kaspth Aug 6, 2015

Choose a reason for hiding this comment

DropsOfSerenity Aug 6, 2015

Choose a reason for hiding this comment

DropsOfSerenity commented Aug 7, 2015

bogdan commented Aug 7, 2015

rafaelfranca commented Aug 7, 2015

rafaelfranca commented Aug 7, 2015

rafaelfranca commented Aug 7, 2015

DropsOfSerenity commented Aug 7, 2015

sgrif commented Aug 7, 2015

DropsOfSerenity commented Aug 7, 2015

bogdan commented Aug 7, 2015

rafaelfranca commented Aug 7, 2015

bogdan commented Aug 7, 2015

rafaelfranca commented Aug 7, 2015

derekprior commented Aug 7, 2015

DropsOfSerenity commented Aug 7, 2015

bogdan commented Aug 7, 2015

derekprior commented Aug 7, 2015

DropsOfSerenity commented Aug 7, 2015

DropsOfSerenity commented Aug 7, 2015

DropsOfSerenity commented Aug 8, 2015

sgrif commented Aug 8, 2015

Specify whether submit_tag should automatically disable on click

DropsOfSerenity commented Aug 8, 2015

DropsOfSerenity commented Aug 11, 2015

kaspth Aug 11, 2015

Choose a reason for hiding this comment

DropsOfSerenity commented Aug 11, 2015

DropsOfSerenity commented Aug 14, 2015

sgrif commented Aug 17, 2015

DropsOfSerenity commented Aug 19, 2015

sgrif commented Aug 19, 2015

DropsOfSerenity commented Aug 19, 2015

claudiob commented Mar 18, 2016