fix(core): setProps validates keys against component options #416
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
My team and I discovered that
setPropsadds all given keys as values on components, whereas thepropsDatapassed to the Vue constructor will only add properties for those that are actually defined. For example if I have this component:If I mount the component for test with options:
Vue ignores that
somewrongpropentirely. However we found that calling:did add that property to the instance. This bit us a little in our TDD since the developer didn't realize they hadn't defined the property in their component because of
setProphaving that inconsistent behavior. Basically they could use a variable in the template that wasn't defined indataorpropsbecausesetPropsinjected it for us.We started using
mountin more tests to avoid this, but it felt bad so here's a PR that seems to resolve the issue by havingsetPropscheck thevm.$options._propsKeyvalue that Vue creates. I'm not sure that poking into that_propsKeycollection is the best answer since that feels very private to me, but I'm not sure another way to do this check and it seems like this is important behavior forsetPropsfor consistency. If there's another way to approach this or a good reason whysetPropsshouldn't have this, please let me know.