RFC to allow applying classes to child components from the parent

Question

RFC to allow applying classes to child components from the parent

AlbertMarashi opened this issue 4 years ago · comments

I was directed to post this to the RFCs, so I am reposting this from. sveltejs/svelte#4843

I am posting here to get thoughts or pros/cons about the various solutions

Feature request description.

I think Svelte is missing an important feature that other frameworks like Vue have. We need a way to easily apply CSS to a child component from the parent without having to use the verbose selector :global(childSelector) {} inside the CSS

We should be able to apply CSS via classes to child components from the parent element. This is a missing feature that should be in svelte.

Describe the solution you'd like

imagine <Link/> is a component that renders an <a> element and has some scripts for routing (eg: event.preventDefault()), and you would like to style that <a> element from the parent

Solution 1:

Add an attribute such as descendants or something to the <style> element to let svelte know that these styles should apply to child components too

<Link href="/about">About Us</Link>
<style descendants>
// notice the descendants attributes (similar to how Vue has scoped
a {
  color: red;
}
</style>

Solution 2:

Allow Child components to be given some sort of attribute that tells svelte to pass the scope to the child component, eg:

<Link:scoped/>
or
<Link scoped/>
<style>
a {
  color: red;
}
</style>

Solution 3:

Allow targeting of components within the parent CSS. eg:

<style>

Link {
  color: red;
}

// or
:component(Link) {
  color: red;
}

</style>

Solution 4:

Get svelte to inject the component's unique scope ID as a class, which would allow nesting in preprocessors

<style lang="stylus">

:scope() a {
   color: red;
}
// or
:scope() {
  a {
     color: red;
  }
}

</style>

Output::

.svelte-123 a {
  color: red;
}

Describe alternatives you've considered

I have considered taking the selector :global(childSelector){} but it is far too verbose, especially if you have something like a <Link> component for JavaScript routing, and it might be found in your nav, sidebar, content, headings, footer (with each instance styled differently)

Not to mention that this only works if you wrap the component in something (selector) otherwise it would apply the global everywhere, eg:

<div>
   <Link href="/about">About Us</Link>
</div>
<style>
	div :global(a) {
		color: red;
	}
</style>

I would like to do something like this:

<Link href="/about">About Us</Link>
<style descendants>
a {
 color: red;
}
</style>

How important is this feature to you?

This is such an important issue that has been raised a number of times and I am begging the svelte team to consider adding anything like this.

I am willing to contribute adding these features if supported

Additional context

This issue has been raised many times:

@nikku summed this up perfectly

sveltejs/svelte#2870 (comment)

Related issues:

Add any other context or screenshots about the feature request here.

Albert Marashi · Answer 1 · Sun May 17 2020 13:14:51 GMT+0800 (China Standard Time)

I will provide some thoughts as to why #13 is incomplete too. Firstly, I'd like to say that this is a useful feature that has been added, but doesn't address the fact of targeting sub-elements

<ChildComponent
  --border="3px solid blue"
  --borderRadius="10px"
  --placeholderColor="blue"
></ChildComponent>

Some issues with this:

It's verbose, if you have to do this outside of an {#each} for multiple items it's not great.
You can't target child elements of the child component effectively
Writing CSS will feel more natural to users and having CSS in HTML feels hacky

I totally understand the reason for using CSS variables, and I think the addition to svelte is great, but it doesn't address the other concerns

Albert Marashi · Answer 2 · Sun May 17 2020 13:15:09 GMT+0800 (China Standard Time)

I will also provide some thoughts as to why :global won't always work:
in here, if I want to target a specific element within a slot of a child component, it's not a great or easy thing to do when you're using a preprocessor

div :global(a){
   h1 {
      color: red;  // this will not work
   }
   h2 {
       color: blue; // this will not work
   }
}

instead you must do something like

div :global(a h1){
   color: red;
}

div :global(a h2){
   color: blue;
}

which I feel is verbose, and additionally, you must wrap your child component in an element in order to target it (div in this case)

Albert Marashi · Answer 3 · Sun May 17 2020 13:24:19 GMT+0800 (China Standard Time)

I know I am supposed to make an RFC using the template, but i'd like to get some more thoughts first

Hybrid Web Dev · Answer 4 · Sun May 17 2020 13:34:19 GMT+0800 (China Standard Time)

I fully agree. Having to write css inline on html is indeed hacky. Additionally it makes re-purposing/re-factoring/splitting up components far harder. As far as I'm concerned, any implementation that prevents writing natural css rules in the traditional method is flawed. Ideally, you should be able to write pure css in style tags in components, just like you can other frameworks(React or vue). This includes the ability for parent components to impact nested elements without the requirement of special declarations.

slimboyfats · Answer 5 · Sun May 17 2020 14:56:14 GMT+0800 (China Standard Time)

I think that in case we are using descendants- style tag then we might also need to have the possibility to have a regular style-tag in the same components. Or am I overthinking?

< style >
a {
color: purple;
}
</style>

< style descendants >
a {
color: red;
}
</style>

Hybrid Web Dev · Answer 6 · Sun May 17 2020 15:01:06 GMT+0800 (China Standard Time)

No, i think that goes against what I am saying regarding requiring special syntax.

Why not just flat out the ability to just...style the descendants with normal css in a normal style tag.

Component

.some-comp
    .a-child

Style

   .some-comp { 
      style here...
   }
   .some-comp a-child {
      style here...
   }

I think that it is overthinking it by doing anything other than sticking to normal css hiearchy.

slimboyfats · Answer 7 · Sun May 17 2020 15:02:10 GMT+0800 (China Standard Time)

Agree, sounds like the most natural way

Albert Marashi · Answer 8 · Sun May 17 2020 15:20:03 GMT+0800 (China Standard Time)

@hybridwebdev because you can't use preprocessing in that case.
@slimboyfats I would support having more than one style tag allowed in a component

pngwn · Answer 9 · Sun May 17 2020 17:22:06 GMT+0800 (China Standard Time)

This need to be a pull request, there are clear instructions in the readme

Antony Jones · Answer 10 · Mon May 18 2020 14:22:37 GMT+0800 (China Standard Time)

Why close this?

@hybridwebdev because a) this is the wrong place for a discussion/issue b) it's already been discussed to death in the Svelte repository.

There is clear need for a RFC on this, providing an exact implementation to be discussed and as such, that is the next step, not another endless discussion which doesn't go anywhere.

I've also deleted your comment as the remainder of it is the opposite of a constructive discussion.

pngwn · Answer 11 · Mon May 18 2020 14:28:45 GMT+0800 (China Standard Time)

Thumbs down and sad face all you like. We have a clear RFC process and it needs to be followed. It isn’t difficult and it was clear from the start that this is what needed to happen.

Hybrid Web Dev · Answer 12 · Mon May 18 2020 14:30:51 GMT+0800 (China Standard Time)

Thumbs down and sad face all you like. We have a clear RFC process and it needs to be followed. It isn’t difficult and it was clear from the start that this is what needed to happen.

You seriously need to calm you jets and lose the attitude man. Community projects are just that...COMMUNITY. If you're going to treat contributors like this, you'll find yourself losing your community. That kinda toxic attitude is detrimental to your goal.

Antony Jones · Answer 13 · Mon May 18 2020 14:33:10 GMT+0800 (China Standard Time)

@hybridwebdev you're talking to people who spend most of their free time helping others, contributing to community projects, and working with people to solve problems, out of the goodness of their hearts. Please remember that in future.

The RFC process is there to make everybody's life easier.

Hybrid Web Dev · Answer 14 · Mon May 18 2020 14:33:35 GMT+0800 (China Standard Time)

@hybridwebdev you're talking to people who spend most of their free time helping others, contributing to community projects, and working with people to solve problems, out of the goodness of their hearts. Please remember that in future.

The RFC process is there to make everybody's life easier.

Doesn't give you a right to be rude to people.

pngwn · Answer 15 · Mon May 18 2020 14:34:48 GMT+0800 (China Standard Time)

We do value community contributions and I have invested a huge amount of effort and energy into that very same community.

That said managing a large open source project is difficult and we need to implement certain measures to make that more manageable. Having a structured RFC process is one of them. This is explained on the readme of this repo. I also explained that the author of the original issue needed to create a pull request in this repo, not create an issue.

I’m sorry it is upsetting to you that we have certain processes that have to be followed but that is how we handle RFCs. Further discussion can take place when this has a PR.