Vue-form-generator: Dont work no param validateAsync as TRUE

Created on 6 Mar 2018  路  20Comments  路  Source: vue-generators/vue-form-generator

All 20 comments

not sure I understand what you're saying?

I am saying that this condition does not make sense since, the variable validateAsync is a TRUE and the asynchronous rule is in ELSE

And another thing, if these validators are all asynchronous, the javascript code is not waiting before assigning RESULTS to the promise (https://github.com/vue-generators/vue-form-generator/blob/master/src/fields/abstractField.js#L122)

@zevitagem can you be more specific about what is not working? You're just providing links to lines of code and giving very short explanations.

abstractField line 78 looks correct to me, if you are using async validation then the validator is pushed onto the results array and the results array is passed to Promise.all to handle the async calls. Otherwise, the validator is executed and it's result is added to the results array (if the validator result is a promise, we attach "then" logic to it to add support for non sync validators - backwards compatibility logic).

I'm not sure what you're saying is wrong with L122, the results array (which can contain a combination of async and sync validator results) is passed to Promise.all which returns a single promise after all of the promises in the results array have resolved ...

If you are having a specific issue, please provide more details about the issue and a JSFiddle example if at all possible. Thanks.

_Actually, evaluating this file after your comments, I realized that this is correct.
Had not noticed the "all()" down there to wait for all the "promises" to finish before executing the "then ()"._

My problem is:

  • When the "validateAsync" property is not set, the "validate" method returns a FALSE.

There are 2 validates:

The "fieldSubmit"

Note:

  • Apparently it is not being called the "validate" of the file "abstract Field.js" but rather the file "formGenerator.vue" since it is returning a FALSE.

I could not make it work without setting the "validateAsync" property to TRUE, so the ARRAY expected for the condition below would work:

If you have an async validator in your validation chain, then you will need to set validateAsync to true and treat the validation results as a promise ... without seeing your code (ie; a JSFiddle example?) it's hard to say what, if any, problem you are experiencing.

Unfortunately, the new "validateAsync" logic was added recently to solve problems with custom async validators ... and was written this way to support backwards compatibility, my hope is that in V3 all validation will be treated as async and return a promise, eliminating the need to set "validateAsync: true".

_I recommend setting validateAsync: true and just treating all validation results as a promise in new projects, and to update existing projects to support this to accommodate future updates to VFG (ie; V3)._

I have noticed that $parent references the FormGenerator.vue same, since it has no inheritance from SUBMIT -> abstractField.js, this abstractField.js is only used to complement and put common behaviors among all fields.

That is, in line 325 of the file formGenerator.vue, the "validate" call of the child component (SUBMIT) will be executed, which will have all that rule implemented in abstractField.js

And in the end, the only thing that maybe you would need to "improve" would be the validation that is done inside the fieldSubmit.vue, because it, it always expects an ARRAY of errors, but as we saw according to line 325 of formGenerator.vue, it may happen to come a FALSE.

Suggestion of validation for file "fieldSubmit.vue" in line 17:

Why implement this suggestion?

  • So, avoid getting into the "onSubmit" when in fact it has errors in the form.
var isAsync = objGet(this.$parente.options, "validateAsync", false);
if(((isAsync === false && errors === false) || (!isEmpty(errors))) && isFunction(this.schema.onValidationError)) {

I have no access to my code to send you the jsFiddle, but for you to have a notion, I'm using the example of:

My submit button has no validator, it basically has:

{
 type: "submit",
 label: "Enviar",
 model: null,
 onSubmit: function(){
    /*  */
 },
 onValidationError(){
    /* stop */
 }
}

I'm still not entirely sure what problem you're having here. Perhaps it's a misunderstanding of how the new "validateAsync" logic works or with how fieldSubmit works.

fieldSubmit's "validateBeforeSubmit" property should be set to true if you want the form to be validated before calling the "onSubmit" handler. "validateAsync" should be set to true if any of your validators are asynchronous (anywhere on the form). I recommend setting this to true regardless, as future versions of VFG will likely return a promise from validate so this should future-proof your code (hopefully).

if the fieldSubmit schema has "validateBeforeSubmit" set to true, its calls the forms "validate" method, and passes the result to the onSubmit or onValidationError handler ... if the result is a promise, it resolves it first.

I believe your schema is missing the "validateBeforeSubmit" property.

{
  type: "submit",
  label: "Enviar",
  validateBeforeSubmit: true, /** needed if you want validation to occur before calling onSubmit **/
  onSubmit: function(model, schema, $event) {
    // called only if the form is valid
    console.log('onSubmit', model, schema, $event);
  },
  onValidationError(model, schema, $event) {
    // call only if the form is invalid
    console.log('onValidationError', model, schema, $event);
  }
}
  • I understood how the component works and put up a suggestion for validation done inside the fieldSubmit.vue
  • My form has this parameter * validateBeforeSubmit * as TRUE, I forgot to put :(

My problem and all users of the component is the following:

  • When there is no asynchronous validations and the form has ERRORS, it is returning a FALSE instead of an ERROR ARRAY. Therefore, that validation existing in line 17 of * fieldSubmit.vue * becomes invalid because it never entered "onValidationError".

Take a test there to see:

  • Create the property * onValidationError * and * onSubmit * as a function
  • Set validateBeforeSubmit as TRUE
  • Force the form to give an error (minimum characters for example)
  • And click on the "SEND"

Current behavior:

  • It will enter the "onSubmit" as if it had been working perfectly

Expected behavior:

  • Sign in "onValidationError"

Note:

  • Currently the $event is not returned "onValidationError", I need this variable to use "preventDefault()" when I insert this component inside of a form.

@zevitagem can you setup your test scenario on JSFiddle so I can see a working example of this?

Yes, as soon as I get home, I will get the commit that was implemented in such a way and I will send it to you by jsFiddle.

@zevitagem that JSFiddle isn't functional. Can you make a working fiddle that shows what you are having an issue with?

You can use this as a base ...

https://jsfiddle.net/kpw2Lzba/

Okay, I used it as the base that sent me and see the behavior when you click on the SEND button with errors in the form:

https://jsfiddle.net/kpw2Lzba/1/

Just added in fields:

{
    type: "submit",
    label: "Salvar",
    model: null,
    validateBeforeSubmit: true,
    onSubmit: function(model, schema, event) {
        alert('onSubmit');

        event.preventDefault();
    },
    onValidationError: function() {
        alert('onValidationError')
    }
}

I assume you're referring to the fact that "onValidationError" is not called when the form is invalid? If so, this is only supported with async validation enabled and requires validateAsync: true to be set. Here's an example.

As for not being able to cancel the event with "preventDefault()", your <form /> should have a submit handler attached which is capable of inspecting the VFG instances status ... you would then call preventDefault() on the forms submit handler if you wish to cancel the submission ... this allows for multiple submit buttons and VFG instances to exist within your form, without having to attach preventDefault() logic to each of them. Here's an example.

Prior to the async validation code being added, the submit button simply ignored the click ... you can see the history here.

So, do you think it is correct to execute the "onSubmit" even with errors in the form just because the "validateAsync" parameter does not exist as TRUE?

I think it would be better if I continued to be ignored so it would prevent users from trusting this "onSubmit" expecting it to enter only with the valid form.

Or, if you put that condition that I wrote some comments above, it works.

if(((isAsync === false && errors === false) || (!isEmpty(errors))) && isFunction(this.schema.onValidationError))

@zevitagem I'm sorry you feel as though the 1+ hour(s) of time i've spent helping you with this issue so far is the equivalent to being ignored. So let's take a step back here ... and start from the beginning of this issue.

Summary of your ignorance ...

You: Your code is backwards
Me: Politely explains how you are wrong
You: Your code is correct, but if I don't enable a new feature then the code acts like it did before the new feature was added
Me: Asks for a JSFiddle to further assist you and help me understand what you're having trouble with
You: Provides a useless JSFiddle
Me: Asks for a better JSFiddle
You: Provides a working JSFiddle
Me: Provides TWO updated versions of your JSFiddle with alternate solutions to the problem you've stated
You: Tell me that I'm ignoring you
Me: Writes this nice summary of our discussion so far

The solution to the problem you are presenting to me, as I understand it so far, is that you should enable validateAsync: true in your form options ... this will _enable a NEW feature in VFG_ that provides an "onValidationErrors" callback for the submit button (which previously did not exist in VFG), as well as providing you with a promise that resolves to an array of error messages rather than a generic boolean result. As stated in my comment above (in bold, italics) , I recommend enabling validateAsync: true in any new projects as this will likely become the default way it is handled in v3.

I'd also like to point out that this is a public repository, and you are welcome to submit a Pull Request with ANY changes you think are appropriate ... once you've done this, a number of project contributors will review your request and go from there.

Now, if I've misunderstood anything you've said so far ... then I apologize, and you are welcome to politely restate your issue in such a way that I can better understand.

I explained, I understand that in the future everything will be summed up in a PROMISE.
But it's not only me that I need to understand, the whole community using the component has to have that clear when using simple things.

No you can launch a version of a component with minimal behaviors not working and leave loopholes claiming that it would be corrected in the future version, normally we just leave it for the future version when the current version not is working as it should and as everyone expects.

Imagine if you have a huge agency counting on this "onSubmit", imagine if they do not have server side validation, even with form errors, the request would be made since it is NOT IGNORED.

If the form request was ignored when an error occurred, everyone could trust because they knew they would only go in there as you said in the comments above if that were RIGHT.

This alternative I / YOU gave you about putting validateAsync: true, it works! But until someone discovers this, the guy will have to open the code, read how it works, and could be written in the documentation.

It could be written like this on the doc:

  • Because we have changed the fieldSubmit to receive asynchronous validations, please always send validateAsync: true, so, in future versions, you will not need move in nothing, since in v3 this parameter will default to the component. Okay, it was simple, of course, objective and no one will waste time debugging.

@zevitagem I'd welcome any updates to the documentation you can provide in a Pull Request. Thank you.

It seems clear that your issue has been resolved by enabling the new validateAsync feature ... I'll be closing this issue now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dflock picture dflock  路  5Comments

Atiladanvi picture Atiladanvi  路  4Comments

afourmeaux picture afourmeaux  路  4Comments

LouWii picture LouWii  路  4Comments

pimhooghiemstra picture pimhooghiemstra  路  5Comments