Skip to content

499 Invalid prop definition crash #506

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

Closed
wants to merge 2 commits into from

Conversation

Akryum
Copy link
Member

@Akryum Akryum commented Jan 13, 2018

Fix #499

@Akryum Akryum requested a review from yyx990803 January 13, 2018 23:27
@Akryum Akryum self-assigned this Jan 13, 2018
@Akryum
Copy link
Member Author

Akryum commented Jan 13, 2018

It looks like vee-validate is doing quite weird things with props. I added a guard against invalid prop definitions. This is so edgy I don't know if it's really the devtools that should have fix for this or vee-validate. Thoughts @yyx990803?

@Akryum
Copy link
Member Author

Akryum commented Jan 13, 2018

@logaretm ⬆️

@Akryum
Copy link
Member Author

Akryum commented Jan 13, 2018

Also, the issue doesn't seem related to provide/inject.

@logaretm
Copy link

logaretm commented Jan 14, 2018

I can provide a fix on my end. But what is considered an invalid prop? vee-validate adds mostly adds data/computed fields to the components in the beforeCreate hook.

And there is the fields object which is consistently being updated since the props depend directly on the vnodes currently present in the template.

@logaretm
Copy link

logaretm commented Jan 14, 2018

@Akryum My guess is correct. The fields property seems to be the culprit here:

this.$options.computed[options.fieldsBagName || 'fields'] = function fieldBagGetter () {
  if (!Object.keys(this.$validator.flags).length) {
    return fakeFlags;
  }
  return this.$validator.flags;
};

The check Object.keys(this.$validator.flags).length provides a temporary fallback which is an ES6 proxy if available in the env. Until the fields are present after the directives have been bound to prevent undefined or null access crashes.

Removing the check fixes the issue in my local tests. I can push a release quickly and I would appreciate it if you can point out other violations that are being done by vee-validate so I can address them too.

EDIT: Wording

@Akryum
Copy link
Member Author

Akryum commented Jan 14, 2018

From what I understand, fields looks like a Vue component and the devtools are now displaying components in the inspector. But the $options.props object of fields is invalid (each prop definition minimal form is myProp: { type: null }.

@Akryum
Copy link
Member Author

Akryum commented Jan 14, 2018

Also, the name resolved for it is something like <{ "dirty": false, "valid": true, ... }>.

@Akryum Akryum closed this Jan 14, 2018
@logaretm
Copy link

But it isn't a component nor a prop, is it? so to clarify It just looks like one and gets interpreted as one and this caused the issue.

@Akryum
Copy link
Member Author

Akryum commented Jan 14, 2018

We check if object._isVue is true and we treat it as a component then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants