Send submitting elements value along with post

[kim3er]

New PR in favour of #295

Creates hidden element in form to ensure inclusion of value associated to submitting element.

[staabm]

Missing comma

[kim3er]

I'll get it added.

[staabm]

Not sure this selector works.. Do all pjax forms necessarily have a data-pjax attribute?

[kim3er]

The Readme infers as much (https://github.com/defunkt/jquery-pjax#pjaxsubmit), but there is nothing cas iron. I think it is should be 'opt-in' functionality though. Do you agree?

[staabm]

The samples in the code do not require it:
https://github.com/defunkt/jquery-pjax/blob/master/jquery.pjax.js#L111

[staabm]

I think you need to capture the current submit element globally, no matter if a pjax-form is handled atm or not. I see no other way.

Any other ideas @mislav @josh ?

[kim3er]

I'm happy to do this. I just think that the form functionality as a whole should be opt-in.

[kim3er]

Or possibly opt-out? form:not(:pjax-ignore)

[staabm]

If there are no perf implications I would enable it by default, because then pjax-forms would behave like usual forms, which is what devs would expect in the first place IMO

[mislav]

First of all, I'd like to avoid adding hidden elements to the DOM because then we have to worry about cleaning them up after pjax, and probably other edge-cases as well.

How about we add the submit button name+value pair to serializeArray() result?

[kim3er]

Rather than add a hidden element, we could add the name+value to a data attribute on the form, during the click event. Then apply attribute to the post in the submit event.

[josh]

@github uses https://github.com/josh/rails-behaviors/blob/master/remote_submit.coffee to generically resolve the submit button tracking.

I'm a little wary of the complexity of supporting this here.

[kim3er]

@josh My PR is based on that code.

[kim3er]

In the latest changes I've:

• Switched from a hidden input to a data attribute.
• Added a unit test

[mislav]

Yeah I'm also wary of the complexity to do this, but I think if you install pjax on the page, we should make sure that forms are submitted with the same parameters as they would be natively. Transparency is one of the promises of pjax.

This is starting to look usable. I would like if there were more unit tests, though, such as if the form has multiple submit buttons, or the submit buttons don't have a name attribute, etc.

I'd also like to avoid this conflicting with rails-behaviors button tracking. If it conflicts, we cannot have it in pjax.

[kim3er]

I've added more unit tests to deal with:

• Single form, single submit
• Multiple forms
• Multiple submits
• Multiple submit types

There should be no conflict with rails-behaviors because we're using data attributes instead of hidden fields.

@staabm raised a point re naming conventions. This PR currently assumes the submitting form will be decorated with data-pjax, when in fact there is no restriction on the implementing code:

    $("#main")
        .pjax("a")
            .on('submit', '.anything-goes', function(evt) {
              $.pjax
                .submit(evt, $("#main"));
            })

I think this could be resolved in a few different ways:

Bind All
Bind the click event to all submitting elements, by removing the data-pjax assumption. This would mean potentially binding inputs that are not part of a PJAX controlled form.

Documentation
Update the documentation to make implementors aware that this functionality depends on the data-pjax decoration.

New Initialiser
Rather than bind handle submit manually, make it part of the PJAX constructor. We would then have the implementors intended selector.

This:

    $("#main")
        .pjax("a", '.container')
            .on('submit', '.anything-goes', function(evt) {
              $.pjax
                .submit(evt, $("#main"));
            })

Becomes:

    $("#main")
        .pjax("a", '.container', { form: '.anything-goes' })

My preference is for the Documentation option.

[mislav]

Thanks. I'm traveling right now so it can be a while until I review all of
this.

[gsiegman]

Any idea when this might be merged in?

[sj26]

Also hit this problem recently. The other option is stashing the clicked submit button for all forms using something like the jquery-ujs solution:

https://github.com/rails/jquery-ujs/blob/master/src/rails.js#L453

Which means on $.pjax.enable there would need to be something like:

$(document).on("click.pjax","form :submit", function(event) {
  var button = $(this),
    name = button.attr("name"),
    value = button.val() || "Submit",
    data = name ? {name: name, value: value} : null;

  button.closest("form").data("pjax:submit-button", data);
});

Then fetching and respecting it inside handleSubmit, and removing it inside disable.

[staabm]

also stumbled over this problem today..

[Shade-]

The recent v54 update to Chrome adds this issue also in it.

[kim3er]

I'm still up for doing any leg work on this, if there is any interest from the team.

[edslocomb]

This tripped us up today. We've implemented a Yes/No/Maybe widget as a form with three button elements, submitting different values depending on which button is clicked. This widget works nicely in a no-js environment, but breaks when we try to attach pjax to it.

The only other option which works in a degraded no-js environment is three forms, each with a hidden field and a submit button, a la button_to() in Rails. But those extra form tags wreck our css, bleh.

It looks like this issue has been outstanding for something like two years now; is there anything we can do to move it forward?