Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[✨] Named slots based on element type and some more improvements #97

Closed
DustinJSilk opened this issue Feb 2, 2023 · 1 comment
Closed
Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation

Comments

@DustinJSilk
Copy link

DustinJSilk commented Feb 2, 2023

Is your feature request related to a problem?

(Sorry for adding multiple requests to a single ticket!)

I've been working with slots for a while now, and there's a few things that are difficult to achieve. These are a few improvements which would be great to add to the library, if possible:

  • A named slot but based on the element type.
    Often elements used in named slots are different types, it would be great if we could define the slot as <Slot element="p" /> and then all p elements would project there. Prop called either element/type/el
  • Add a class attribute to the <Slot /> component that gets added to the injected element
    This means that content added to a component can be given strict styles defined in the component it is used in
  • Slots without an element. (Maybe its not even possible)
    The extra dom element can be tricky. Developers adding to a components children need to think if the element they use is compatible with where it is being projected. For example, you cant put a p inside a p. Its also an extra element that could be avoided

Describe the solution you'd like

..

Describe alternatives you've considered

..

Additional context

No response

@gioboa
Copy link
Member

gioboa commented Oct 14, 2024

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.

@gioboa gioboa transferred this issue from QwikDev/qwik Oct 14, 2024
@github-actions github-actions bot added [STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation labels Oct 14, 2024
@QwikDev QwikDev locked and limited conversation to collaborators Oct 14, 2024
@gioboa gioboa converted this issue into discussion #173 Oct 14, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation
Projects
None yet
Development

No branches or pull requests

2 participants