Segregate CSS in the construction of Angular components?

Asked

Viewed 193 times

2

I have a reusable component (main), it would be something like a widget, that the main structure is separated into 3 parts (or sub-components), which will not be reused anywhere else but the main component (main):

<!-- Código resumido -->
<!-- Componente Main -->
<div class="main">
    <!-- Sub Componente Header -->
    <div class="header"></div>
    <!-- Sub Componente Content -->
    <div class="content"></div>
    <!-- Sub Componente Footer -->
    <div class="footer"></div>
</div>

Each of them will grow separately in terms of HTML, CSS and Javascript/Typescript. My question is, the best form/best practice used in the CSS organization in this case?

1) Cluster styles within the css of the main component?

<!-- main-component.scss -->
:host {
    <!-- Css do componente main -->
    .header {
        <!-- Css do componente header -->
    }
    .content {
        <!-- Css do componente content -->
    }
    .footer {
        <!-- Css do componente footer -->
    }

    .header,
    .footer{
        <!-- Css recorrente nos dois componentes -->
    }
}

2) Segregate css, each with its own, leaving idepentende, although these components are never used separately?

<!-- main-component.scss -->
:host {
    <!-- Css do componente main -->    
}

<!-- header-component.scss -->
:host {
    <!-- Css do componente header -->    
}

<!-- content-component.scss -->
:host {
    <!-- Css do componente content -->    
}

<!-- footer-component.scss -->
:host {
    <!-- Css do componente footer -->    
}
  • 1

    Angular itself already answers your question, every time it creates a component it creates together the Html, Scss, TS and depending on the spec referring to that component.

  • I agree, but that premise comes from good componetization practices, when it comes to creating a front-end architecture, for better organization/reuse of code, but in the case I mentioned, if I use the "angular pattern", I gain in organization and lose in reuse, since I will have duplicated css in some cases.

2 answers

2

The more uncoupled your architecture is always better. Today you think you will always be together, but you never know tomorrow, maybe you want to use the same header in another project. So in this case always have the css of the component next to it. The host or deep should be used if you are using a library and want to change its css. Or there is a component that in many cases has css in a way but in a specific case you need to change. But the standard style of the component should be inside it.

  • So generally speaking, I know decoupling is better, but this is a case, which is sometimes even common, that the "sub-components" really wouldn’t work in another situation, they’re only made for organizing the main component. In the case of proper use of the Host (which I will still try to enlighten myself in another question) I end up using it in every component, when I need to use styles.

1


Here at the company we use VUE, not Angular, but I can tell you the practice we adopt here. Though not a canonical answer may help you in something.

The answer I have is that "it doesn’t matter". At least here, what we try to follow is what the team culture preaches. That in the case of the team and the Vue facilities we concentrate HTML/CSS/JS within the same file. But if the pattern of your team’s design structure has always been to keep them separate, there’s no point in putting them together. This can even confuse developers and make maintenance difficult. Choose a standard and use it as a rule. Consistency will generate efficiency.

Also, as a designer, it makes it very easy for me to have separate files .css, .html and.js. Makes life very difficult for me when I have to seek <styles> inside files .vue for example. I scrap in Devtools then I can’t find the .css within the project... it irritated me a little at first. Everything else goes from the culture of your team. In my opinion it has no defined rule, even if they are unique components. Remember the consistency I mentioned above ;)

  • I came with this doubt while creating a component, something like a Widget, create it in a single structure of html, css and js, and decided to break them in these "sub components", and I saw myself, removing css from the parent component and passing to the children. The idea of having to enter several css files to know how each piece of that stylized widget that made me generate this question,

  • @Ejspawn even though they’re unique today, think scalably... tomorrow can’t be. or else you can use this basis for a larger project, where everything separate would be better, etc. As I told you there is no answer 100% correct for this, you will have to ponder together with your team, only raise points that you should consider in choosing.

  • I think in the case then, would follow the safest approach, which would have less side effect, follow the standard, angular or your team (if there is one in the case). I think I’ll follow that way.

  • @Ejspawn yes, the ideal is to establish a standard that is comfortable for the team and adopt it. And always think that the project can scale, migrate, or serve as a template for bigger ones etc. Think about maintainability and these things too.It was worth the force!

  • 1

    Yes, my biggest doubt was whether in that kind of situation it would be worth "breaking the rules" or setting a rule just for the situation, but in the end, given the answers, I realized that I would end up with zero or little advantage. Thank you!

Browser other questions tagged

You are not signed in. Login or sign up in order to post.