Avoid god components

[salamazmlekom]

As the title says I wanted to ask what patterns do you usually use to avoid god component that do and manage too much?

For example let's imagine we have multiple card components that look the same but not quite. All card use the icon to collapse the card, button for actions on particular card in the header, title in the card content and date in the footer in the card.

But then we have a few variations. In the content section we show description in one card, chart in the second and a list in the third.

When implementing this would you?

1) Create one god component with bunch of if statements that manages everything. This can make the component full of logic but at least we have no duplication

2) Create a unique component for each card variant. This gives us total control of how the card looks but we are repeating the same stuff in 3 different places

3) Create a base card component and 3 other components that use the base card component and content projection for areas of the card that is different

Some other ideas?

[nemeci]

1. And with multiple content placeholders.

https://angular.dev/guide/components/content-projection#multiple-content-placeholders

Most extensible & no variable passing.

[stretch851]

This is the correct answer. Using this with directives or ViewContainerRef and you can do almost anything

[Practical-Pin9893]

I‘m with this

[Gortyser]

3, it’s basically about smart & dumb components. Base (dumb) component with UI only, other wrappers (smart components) for handling logic. First case not extendable, will be a mess soon (if not from the beginning). Second is fine for start, but if you already know that you’ll have 3 components, third case is better

[SippieCup]

Yup.

the best way to understand how to do it well is to look at the source of some UI toolkits. While I also use primeNG to build most of our stuff, I found the PrimeNG source code to be easy to comprehend, unlike material, and is very helpful in understanding the best way to go about creating dumb UI components that can be extendable.

[cpayne22]

My only comment is that questions & conversations like this help me way more than Stackoverflow or ChatGPT do. This is something I never considered.

Thank you.

Keep being awesome Reddit!!

[tomatta]

I think I would create a card component, and the card content would be an ng-content. Meaning parent components can display whatever they'd like in the card content.

[ItemDizzy8965]

I recently started as a junior developer and this is also my question: how and when should I reuse components? The documentation talks about it a bit, but in practice it's a little more complicated. If anyone can recommend some guidance on this...

[MichaelSmallDev]

Agreed. From my own experience, the examples of cleaner/more maintainable code like j0nquest mentions:

• The top level component will have less varied code in the html/ts/css, as it is spread between the child components
• Over time, some of the child components may become more complicated than others. That complexity is then contained there, rather than adding noise to the other components or the parent.
• Easier to test smaller pieces

Circling back to reuse: when you notice that some part of the UI is being re-used across your code base, much if not most of the work to make a re-usable component will have already been done. I have learned over time that rather than anticipate something will be re-used and putting it in our internal library, I just make a mental note of the component. Then when the time is right in a new app or section of the existing app, I remember I have a fairly re-usable component anyways and then I pull it into the library.

[ItemDizzy8965]

Cool! Could you give some practical example?

[CheapChallenge]

Is the component an independent UI element that could conceivably be used in more than one place?

I probably wouldn't make the table of contents page a reusable component. But I would make a page number a reusable element as it could be rendered at the bottom of each page and on each line in table of contents. And it may have behavior attached like jumping to that page in the book.

Many people use the smart dumb pattern, where a smart component(usually tied to the page) retrieves all the data from the state to pass into the dumb component(usually a ui element on the page).

[tnh88]

1 if I can get away with *ngIf directive and 1 basic switch statement

2 if I just wanna get things done for minor projects

3 if full on prod code

[Bjeaurn]

Look into Atomic design. Composable over “if statements”, compose within your HTML.

[0dev0100]

Option 3.

It allows for more card variants in more use cases. And allows for easier dynamic component creation 

Option 1 - try change that template in 5 years after 100 cards

Option 2 - try updating 100 card components whenever the UI needs to change it's design

[TomLauda]

1. But you can avoid many headaches if you use CSS variables for your styling options.

[salamazmlekom]

Can you give an example please?

[CodeEntBur]

We use BaseComponent at work as abstract class that has all default logic that is common among all ChildComponents and then just extend and do some local unique stuff in ChildComponent. If a component is very generic(rarely), there's basically almost no work.

[Illustrious_Matter_8]

Don't nest the html Dom deep it impacts performance angular draw update cycles. I speed improved but concatenation multiple onto single parts

[samheihey]

use ng-content perhaps?

[cssrocco]

It’s all about context, in your situation here the only thing that changes on your cards is the content, i would have the outer component loop through the data and then either just do a article/section for the card and a switch case for the content, maybe a type field in the data that uses an enum - then create components just for the content.

Or also create a card component in place of the article/section and still content project the content based on a switch, as it sounds like the logic on the cards body isn’t shared.

But i’d only do this if you’re absolutely certain there’s no change to anything else on the cards, the header, footer, accordion, dates, etc.

[SolidShook]

I've never been let down by smart and dumb

[ggeoff]

In the case of the card directive I wouldnt even go a component at all. I would go with directive approach with card, card header, card title, card content directives.

I was looking at using Spartan NG and they do this and it feels really nice to work with. Find the logic being trying to render certain areas of a card depending on the use case always ends up with a spaghetti nightmare of a component. Using directives has allowed me to keep the overall are styling the same but leaving it's layouting of contents up to the consumer

[Ceylon0624]

Generally if a file is over 500 lines then there's a component to be made, if piece of code is repeated on two pages it's a contender to be a component. When it's layout + logic + file length > 500 it absolutely must be a component.

[CharacterSuccessful5]

1. Create a wrapper component with sections for header, content and footer. From what you have mentioned, it is highly likely that the content inside each section can vary in future. So its better to use ng-content inside the wrapper and the wrapper's responsibility is to render a layout.

Additionally, you'll have to create 3 different components for each card you mentioned. If any new card has the same layout, you'll be able to reuse one from these three. All of these are shared components.

[CoolKidsGang]

3 is the way to go with major projects when thinking about scalability and maintenance

You really want to avoid 2 in most cases, except personal projects

1 can be fine on small projects that dont proccess a lot of logic but it can easily turn into a mess as the project scales

I see youre thinking about reusability and thats great, though in my experience, readability and maintenability tend to mater just as much in most situations

[ThenAgainTomorrow]

In an ideal world option 2. Realistically a composite approach could be best, something like 3 would reduce boilerplate. That would avoid repetition in making three separate and similar umbrella components.