Fix #1868 v-slots now work inside a div - #1877
Conversation
| ctx.$options.parent._vnode.data.scopedSlots | ||
| ) { | ||
| const slotKeys: Array<string> = ctx.$options.parent._vnode.data.scopedSlots | ||
| if (ctx && ctx.$vnode && ctx.$vnode.data && ctx.$vnode.data.scopedSlots) { |
There was a problem hiding this comment.
Hey, sorry for the delay on this... so basically ctx.$options.parent._vnode.data.scopedSlots references the same thing as ctx.$vnode.data.scopedSlots? Do you see any potential risk/regression here?
There was a problem hiding this comment.
Really sorry I am only getting to this now. They main difference is we are not going to the parent for reference of the current vnode. I am unsure if there was a specific reason we were doing this?
There was a problem hiding this comment.
I have no idea, this part of the code base is incredibly complex.
I wonder if we can do this in a way that changes less code to reduce risk. A lot of code bases depend on shallowMount and stubs working how they currently do (which is what this code is relate dto) and I don't want to accidental break anything.
There was a problem hiding this comment.
I guess this code change is address the fact that parent might actually be a normal DOM node and therefore not have a _vnode property. This is the case with the original bug report. Instead we are using the $vnode on the context to get access to the scopedSlots rather than relying on a parent
2 participants
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: