fix #1845: add functional component check in component name match - #1857
Conversation
There was a problem hiding this comment.
Left a comment. Also it looks like the OP in one of the issues posted a reproduction: #1845 (comment), the test is here. Could you verify if this fixes that? If we merge this and mark is as resolving those 3 issues, they'll be closed - we only want to do that if it actually is confirmed to fix those problems.
| @@ -0,0 +1,12 @@ | |||
| <template> | |||
| <div> | |||
There was a problem hiding this comment.
Should this be a functional component? Since the patch is related to functional component name?
There was a problem hiding this comment.
No, the patch is related to functional components but the fix is for normal components.
Eg for a functional component when you access vm.name you will get the name of the component. But accessing vm.name for a normal component will return the name property if that exists. Previously the code was just too greedy by always preferring to use vm.name if it exists. But given the aformentioned that will result in a find bug when you try to find a normal component that has a name prop itself

The following PR introduced a bug for finding components that contain a name prop themselves: 3cd81d0#diff-80ab213bfb0eeafc02c6f0005a492f52eab27ef052d46ed9e17c5df0da4eefe1
This PR fixes that behaviour by only using
vm.nameif the component is functionalThis should fix the following issues:
Resolves #1820
Resolves #1845
Resolves #1854
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
devbranch.fix #xxx[,#xxx], where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Other information: