Skip to content
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

Performance issue when large group of radios used #1191

Closed
barnabas-szekeres opened this issue Mar 1, 2018 · 4 comments

Comments

@barnabas-szekeres
Copy link

commented Mar 1, 2018

Versions:

  • VueJs: 2.5.13
  • Vee-Validate: 2.0.4

Description:

When you render a lot of radio buttons – for example 100 radio – the validator will be stuck for some seconds. Submitting the form will take a very long time –– longer than seconds.

When you comment out the error.has part of the code the issue gone. Is this a performance issue or just a simple limitation?

Steps To Reproduce:

I made a codepen for the reproduction: https://codepen.io/barnabas-szekeres/full/QQYoKo

@logaretm

This comment has been minimized.

Copy link
Owner

commented Mar 2, 2018

I guess because it generates a lot of updates to the DOM, the combination of errors.has and errors.first takes about 5sec each on my test machine. a total of 10 seconds which is certainly unacceptable.

I think there is a way to improve this using #1125 suggestion, such component/directive could be implemented in a more efficient manner.

@Koc

This comment has been minimized.

Copy link

commented Mar 6, 2018

@logaretm what about making errors variable reactive and change access to errors. Instead errors.has('email') write errors.email? Maybe in this case Vue has proper changes tracking 😕 ...

Or create computed property, ther are cached by Vue by default https://vuejs.org/v2/guide/computed.html#Computed-Caching-vs-Methods

@logaretm

This comment has been minimized.

Copy link
Owner

commented Mar 6, 2018

For clarification, errors.has only calls errors.first internally and casts the result to a boolean, which in turn causes two calls to errors.first to be made in the OP case, still errors.first alone takes a lot of time on a single call.

@Koc I thought about that initially, but again it would depend on the implementation, for computed props it would look like this:

errors.email = function () {
return this.first('email');
};

which is the same. But we can change implementation to be an actual prop that is set after each validation cycle:

// internally at validator.js
this.errors.email = 'THE ERROR MESSAGE';

the validator has to handle fields that are added/removed from the DOM with v-if/v-for which was annoying to implement for the flags bag. I still like the direction of the custom component/directive that should be able to optimize the DOM updates for itself. I will setup a few testing scenarios and decide which direction to take.

@logaretm logaretm referenced this issue Mar 29, 2018
3 of 4 tasks complete
@logaretm

This comment has been minimized.

Copy link
Owner

commented Oct 27, 2018

This issue took its time, but has been resolved with the introduction of Validation components, will be released soon with the details. Take a look at those PRs #1625 and #1677

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.