Semantic-ui: [Form] Form ALWAYS get the "success" class?

[xDaizu]

I'm sending the form over ajax capturing the "submit" event $("#form").on("submit"...) using e.preventDefault(); to stop the POST default send (which is still configured as a fallback, just in case) and, as a callback to the ajax call, setting the form state as "success" or "error"... BUT no matter what the response is, the form always gets the "success" class.... why? Is it just because it passed validation? Because then, the example on the page is misleading as hell

Form Completed

You're all signed up for the newsletter.

meaning: "THE SERVER RECEIVED AND UNDERSTOOD YOUR PETITION", which you can't be sure of until you receive the server's response, so it should be activated programatically. So... is there anyway to override this (seemingly useless) behaviour? I've searched the docs and I didn't find anything...

[jlukic]

The easiest way to take about these issues is to create a test case showing the issue reproduced, an explanation of the expected behavior and how it differs. See our contributing guide.

[xDaizu]

Ok, my bad, I'll do just that :+1:

It's actually a very simple use case (or so I think), second simplest after doing a simple POST request, but for the sake of debate, I'll expose it in as much detail as I can, without boring you :smile_cat: :

So we have the HTML structure

<div class="button awesome-form-submit-button">
<form id="awesome--fForm">
</form>

<div class="button awesome-form-submit-button">
<div class="button awesome-form-submit-button">

Yeah, it has a lot of submit buttons. Don't look at me like that, it's the UX guy's whim. Now, we need to validate before submitting, because UX, so...

var $form = $("#awesome-form");
var $buttons = $(".awesome-form-submit-button");

So now we make it so the buttons manually launch validation. Why, with all the cool validation features integrated in semantic-ui? Weeeell, it's explained in this other issue, but that's out of the scope of this case.

$buttons.on("click", function(){
    // We clear the form state (didn't find any other way in the docs, tell me if there is)
    $form.removeClass("success error warning");
    // We do the basic validation provided by semantic-ui and some extra more
     if ($form.form("is valid") && extraValidation($form)) {
                    console.log("#personal-data-form is valid! HURRAY! Submiting....");
                    $form.form("submit");
                } else {
                    console.log("Form is NOT valid! BUUH! Not submiting....");
                }
    });

Ok, now it would submit, wouldn't it? But we want to AJAX submit, so we catch it

$form.on("submit", function(e){
    $form.addClass("loading");
    $buttons.button("loading");
    var serialized_data = $form.serialize();
    // the next is just a generic function that sends an ajax petition, process the response and calls a callback
    form_AJAX_send(serialized_data, awesome_form_submit_callback);
    e.preventDefault();

    return "potatoes";
});

So now the form shouldn't be in neither success, error or warning state, because the petition hasn't been processed. A success state informs the user that the server understood and successfully processed his petition, so he can rest assured and go have his cup of coffee.

As for when to report the status... in the callback, obvs:

    /**
     * The response is a simple response from the server pre-processed by form_AJAX_send()
     *  So if the server API changes, I only have to change form_AJAX_send
     * @param {object} response
     * @param {boolean} response.success
     * @param {string[]} response.errors
     */

function  awesome_form_submit_callback(response) {
   // Form not loading anymore, it's resolved, for better or worse
   $form.removeClass("loading");
   $buttons.button("reset");
    // Now I check the response object
    if (response.success) {
                        $form.addClass("success");
                    } else {
                        $form.addClass("error");
                    }
}

Now, that's how I feel I should use it. Right now, I have this line:
$form.removeClass("success"); as the first line on $form.on("submit", function (e) { because it adds successfor some reason unknown to me and/or the documentation.

I've only been using semantic-ui for 3 days, so it may be possible I'm programming with my forehead here, in which case just, please, tell me what's the semantic-ui's way of approaching this use case...

[xDaizu]

After implementing the above code, I also get another related strange behaviour.

The validation rules are set to on:"submit".
My extraValidation($form) function calls $form.form ("add error", ["Error description"]) and I manually add the .error class to the field because how else would I do it?

Now the submit action stopped, and the form shows the "Error description" text and the faulty input field marked in red. So far, so good. But, the very moment I interact with any of the faulty fields (not even looked at the submitting button), the form receives the "success" class.

Im guessing that even if the validation is on submit you are running it again after you change and "offending field" to inform the user he did right. Which is cool, but it doesn't take into account my custom validation field (it obviously would if it were properly defined ). Also, I'm starting to suspect that the success class behaves as validation success and not as submission success (which is counter-intuitive to the provided example in the docs, you are signed up when the form is actually submitted). This is not a bad thing _per sé_, it's very useful to have an state for _success validation_, but we would also need a _success submit_. Maybe all of this would be fixed if we defined two different states.

[vkruoso]

I found this a really annoying problem. I can't use a static success message to show when the form is processed because the success class is added just because it is valid. The use case is simple: show a success message (by adding the success class to the form) when the form was correctly validated, submitted and processed.

It looks like this code does the trick: https://github.com/Semantic-Org/Semantic-UI/blob/master/src/definitions/behaviors/form.js#L764-L771 (in particular L767).

[xDaizu]

@vkruoso I actually think there should be two distinct states: "validation success" and "submission success". The proposal is there, now we just have to wait to hear from the "_powers that be_" :sweat_smile:

[xDaizu]

Not to be insistent (I know your plate is pretty full), but I think that I provided both a "Test Case" and a description in line with the "Contributing Guide", so the tags are no longer appliable. If that's not the case, please, let me know and I'll elaborate some more... (even though I'm not really sure _how_ :sweat_smile: )

[zek]

I have the same issue. Validation success but server response is not.

[jlukic]

Can someone create a JSFiddle test case showing the minimum amount of code to reproduce issue?

[ghost]

@jlukic There you go: https://jsfiddle.net/um4d1xze/1/

The success message is shown even though the URL is not accessible. The success message should only be shown when a request was successful.

[chris-griffin]

@jlukic just to clarify this is less of a bug and more of an unexpected implementation. I would suggest the following:

1) Modify the docs to clarify that the ui success message that is by default hidden within a form becomes visible when validation is successful, and not when the form was submitted successfully.

OR

2) (Ideally) Although a form validation success state is helpful, it is usually communicated to the end-user via a lack of error messages (not via a success message). The success message is typically reserved for a successful submit and server response. Could we change the default behavior show that the success message is not shown on data validation success?

[chris-griffin]

Here is a JS Fiddle to show the updated behavior (or lack thereof)

https://rawgit.com/chris-griffin/Semantic-UI/form-success/dist/semantic.css

[chris-griffin]

Just for anyone who stumbles upon this thread. @jlukic provided a work around in a comment on the pull request:

"You can modify the className 'success' in the settings object to set as a blank string.
.form({ className: { success: '' });"

It doesn't seem like the default behavior is likely to change:

"Removing this feature would cause code for those that already rely on this feature to break, so this could not be changed without a major release, and I'm happy currently with the decision to use it."

[jlukic]

Sorry for my negligence in this thread. Closing per @chris-griffin's copy and paste from #4583