Who is the boss of your components?

I have been working with Angular since about version 2.0.0 , from small applications, IOS/Android ones, to large scale enterprise level applications. I love Angular and that's why I always justified using it, but it wasn't since lately working with an abnormally large team, where I deeply understood the implications of bad Angular and smart Angular coding.

Architecture wise all my apps probably look the same, thanks to Angular's opinionated , very... , way of work, which forces us, it's users to code in a very specific way. So whats the difference ? why did I my team suffer ? At some point I got it, who should take more responsibilities ? the employee or the boss ?

Who's is the boss of your component ?

lets say we have a component the shows the client's name

@Component({
  selector: 'ng-client-name',
  templateUrl: './client-name.component.html',
  styleUrls: ['./client-name.component.css']
})
export class ClientNameComponent implements OnInit {

  @Input() name: string
  constructor() { }

  ngOnInit(): void {
  }

}

Who decides on the fallback ? the component? or its user ?
well it depends, but lets see this simple example through

<ng-client-name [name]="clientName || 'Creg'" ></ng-client-name>

In the above example, the parent component is incharge of the fallback, if no clientName, show "Creg" Instead.
ClientNameComponent will always have a value.

But what about the code block below ?

  @Input() name: string = "Creg"

In this use case, in contrary to the other code block the component keeps it self safe, no error could occur since the possible issue is contained and dealt with inside it self.

This simplified example, that we could all probably write a quick fix for all use cases in about 2-3 minutes, shows a deep problem while working with a large team. Who is the boss? Me making the component, or the the other person who uses it ?

Do not try to think like your colleagues, won't work, and making everything super compatible to everything and everyone is even worse.

While building a shared Angular library I had to build components to be used on 3 different apps with different functionality, so who is the boss of the logic ?
the answer? the component, but we fake it so they think its the parent. Confused? let me explain.

@Component({
  selector: 'ng-client-name',
  template: `
<div>
     <span>{{name}}</span>
     <input (change)="change($event)"/>

 </div>
`,
  styleUrls: ['./client-name.component.css']
})
export class ClientNameComponent implements OnInit {

  @Input() name: string;
  @Output() onChange: EventEmitter<string> = new EventEmitter<string>();
  constructor() { }

  ngOnInit(): void {
  }

  change($event: any): void {
    this.onChange.emit($event.target.value);
  }

}

From the code block above we see that the component is the boss of the internal logic, the component decides when to update the parent of the change. but the parent is in-charge on what to do with the change.

<ng-client-name [name]="name" (onChange)="updateName($event)"> </ng-client-name>

This ideal may seem a little annoying to work with at first, since there is a lot of code to be written on both sides of the component, but this forces us to do a couple of things:

1. Deeply understand the scope of the functionality of each component
2. Automatically each component gets a higher level of dynamic ability.
3. When scope is clear, the behaviour on all platforms is small but controlled and contained .
4. More maintainable .

Creating shareable components is very common, usually we do simple things, like buttons, checkboxes, essentially one for one, one entry point and one exit point, and the whole logic is done by the parent, or complete blackboxes which are completely independent. this happens in order to create easier to transfer components, but in hindsight it creates a lot of duplication code or no customisability , since each user of the component needs to deal with its edge cases... and if we wrap it with our own component, than whats the point.

When working with a team, your goal is the success of the team. the team's success > product's success > your success.

Hopefully this article will help you make better components and be better team player.

For any questions feel free to PM me or leave a comment below.

ps.
This is obviously an opinion and a success story for my self I wanted to share, no religious beliefs here :)
Stay safe