feat: allow slot prop vars as components #13573
Conversation
WalkthroughThe changes introduce enhanced handling of component resolution within slot scope bindings in the compiler core. New test cases verify that components referenced via slot props are not resolved as normal components. The codebase is updated to support passing and checking an Changes
Sequence Diagram(s)sequenceDiagram
participant Compiler as Compiler
participant TransformContext as TransformContext
participant Codegen as Codegen
Compiler->>TransformContext: createTransformContext(options, identifiers)
Note right of TransformContext: identifiers map is set from options or default
Compiler->>TransformContext: resolveComponentType(tag)
alt tag in slot scope (identifiers)
TransformContext->>TransformContext: Check identifiers for tag
TransformContext-->>Compiler: Treat as slot prop, do not resolve as component
else tag is normal component
TransformContext->>TransformContext: Standard resolution logic
TransformContext-->>Compiler: Resolve as component
end
Compiler->>Codegen: Generate code with context
Poem
Warning Review ran into problems🔥 ProblemsCheck-run timed out after 90 seconds. Some checks/pipelines were still in progress when the timeout was reached. Consider increasing the reviews.tools.github-checks.timeout_ms value in your CodeRabbit configuration to allow more time for checks to complete. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
❌ Deploy Preview for vue-sfc-playground failed. Why did it fail? →
|
❌ Deploy Preview for vue-next-template-explorer failed. Why did it fail? →
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/compiler-core/src/transforms/transformElement.ts (1)
388-391: Consider removing or documenting the commented-out code.The commented-out code for slot scope bindings handling should either be removed if not needed, or documented with a TODO comment explaining the future implementation plan.
- // const fromSlotScope = checkType(BindingTypes.SLOT_SCOPE) - // if (fromSlotScope) { - // return fromSlotScope - // } + // TODO: Future implementation for slot scope bindings + // const fromSlotScope = checkType(BindingTypes.SLOT_SCOPE) + // if (fromSlotScope) { + // return fromSlotScope + // }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
packages/compiler-core/__tests__/transforms/transformElement.spec.ts(2 hunks)packages/compiler-core/src/codegen.ts(1 hunks)packages/compiler-core/src/options.ts(1 hunks)packages/compiler-core/src/transform.ts(2 hunks)packages/compiler-core/src/transforms/transformElement.ts(4 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
packages/compiler-core/__tests__/transforms/transformElement.spec.ts (2)
packages/compiler-core/src/index.ts (1)
BindingTypes(11-11)packages/compiler-core/src/runtimeHelpers.ts (1)
RESOLVE_COMPONENT(26-28)
packages/compiler-core/src/codegen.ts (1)
packages/compiler-core/src/options.ts (1)
CodegenOptions(307-349)
🔇 Additional comments (7)
packages/compiler-core/src/options.ts (1)
203-203: LGTM! Well-integrated interface extension.The addition of the optional
identifiersproperty follows the existing pattern and maintains backward compatibility. The type signature is consistent with identifier tracking used elsewhere in the codebase.packages/compiler-core/src/codegen.ts (1)
123-126: LGTM! Proper type boundary maintenance.Adding
'identifiers'to the omitted properties list is correct and maintains type consistency. This follows the established pattern of excluding transform-specific properties from the codegen context.packages/compiler-core/src/transforms/transformElement.ts (2)
285-300: LGTM! Well-implemented slot prop component resolution.The new step correctly checks for components from slot props using
context.identifiers. The logic properly handles both direct tags and dot notation components, and is appropriately gated for non-browser builds.
302-302: LGTM! Proper step renumbering.The comment numbering has been correctly updated to reflect the new step insertion.
Also applies to: 319-319, 333-333
packages/compiler-core/src/transform.ts (2)
146-146: LGTM! Well-designed parameter addition.Adding the optional
identifiersparameter withObject.create(null)as the default is a good design choice. It enables external control of identifier tracking while maintaining backward compatibility.
191-191: LGTM! Proper context assignment.The
identifiersassignment correctly integrates the parameter into the transform context.packages/compiler-core/__tests__/transforms/transformElement.spec.ts (1)
124-141: Well-structured test for slot prop component resolution.The test correctly verifies that components referenced via scoped slot bindings (e.g.,
{Foo}) are not resolved as regular components. The test expectations are appropriate:
- No
RESOLVE_COMPONENThelper injection- Component not added to components list
- Root node tag remains as the parent component
packages/compiler-core/__tests__/transforms/transformElement.spec.ts
Outdated
Show resolved
Hide resolved
I had a shot about implementing the issue I raised in #8553.
Since I just look into the identifiers I feel like there must be some implications that I cant see yet. But the proof of concept works.
Happy for any feedback
Summary by CodeRabbit
New Features
Bug Fixes
Tests
Chores