0
votes

How to decide when to use child angular component inside parent?

Should it be one entity, for example lessons list and add lesson.

I try to get when I should use child component, when exist real relation between parent and child?

Lets assume we have product card with buttons inside:

<app-product-card>
    <!-- Product information here -->
    <app-product-buttons></app-product-buttons>
</app-product-card>

On of button app-product-buttons has clic event, that shows list of users, who bought this product.

Should I insert <app-users-producst-buy></app-users-producst-buy> inside:

  <app-product-card>
        <!-- Product information here -->
        <app-product-buttons [product]="product"></app-product-buttons>
        <app-users-producst-buy></app-users-producst-buy>
    </app-product-card>

Or inside as child in buttons component:

  <app-product-card>
        <!-- Product information here -->
        <app-product-buttons>
               <app-users-producst-buy [product]="product"></app-users-producst-buy>
        </app-product-buttons>
    </app-product-card>

How to make a right decicion on this cases? Or should I use dynamic components?

1
I would say this is an opinionated question, it depends on your setup and requirements. Does the child component need to communicate with it's parent? Is it reusable elsewhere? - Phix
No, child should not communicate wwith parent only one way data flow, parent -> child. No any callbacks to parent. Also I can call child component from another place. - user12700434
Yes, also it is reusable in others places, I just pass parent data to child - user12700434
It's up to you sir. Without seeing what these components actually do it's hard to say, but whatever works for your case. - Phix

1 Answers

0
votes

From my experience with Angular framework, this decision is no always easy as you are saying.

Moreover, you can apply that kind of rules:

1) Modularity: I always use child component when the child component I am about to design will appear in more than one place in the project.

2) Maintainability: The simpler, the more maintainable. When a component tends to be huge, and you can identify several sub-components, let's split it.

3) DRY (Don't Repeat Yourself): thinking in small, specialised components (without going into the excess, for sure) can be a key to keep a small but very functional code-base.

I hope these points can help you making decisions.