This content originally appeared on Bits and Pieces - Medium and was authored by Teslenko Oleh
Part 1: Understanding the Single Responsibility Principle (SRP)
In my opinion, all of us want to write code that’s easy to maintain and scalable. That’s where SOLID principles come in! They’re a set of design principles that can help you create awesome code that’s modular and easy to understand. Here’s a brief overview of the SOLID principles:
- Single Responsibility Principle (SRP): A class should have only one reason to change.
- Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
- Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types.
- Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use.
- Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions.
In this article, we discuss the Single Responsibility Principle (SRP), which says that a class should only have one reason to change. In Angular, that means each component, service, directive, and pipe should have one clear responsibility.
💡 As an aside, if you want to get the most out of your Angular components, you could consider using tools such as Bit. With Bit you can “harvest” them from your codebase and share them on bit.dev. You can then reuse these components across all your projects.
Learn more here:
Let’s take a look at an example of how we can apply the SRP in Angular. Say we have a component that displays a list of items and allows the user to add new items. If we were to implement this component without the SRP, it might look something like this:
@Component({
selector: 'app-item-list',
templateUrl: './item-list.component.html',
styleUrls: ['./item-list.component.scss'],
})
export class ItemListComponent implements OnInit {
items: Item[] = [];
constructor(private itemService: ItemService) {}
ngOnInit(): void {
this.itemService.getItems().subscribe((items) => {
this.items = items;
});
}
addItem(name: string): void {
this.itemService.addItem(name).subscribe((item) => {
this.items.push(item);
});
}
}In this example, the ItemListComponent is responsible for both fetching data from the ItemService and adding new items to it. This violates the SRP because the component now has two reasons to change: if the data fetching logic changes, or if the adding logic changes.
To apply the SRP, we can extract the adding logic into a separate component:
@Component({
selector: 'app-item-add',
templateUrl: './item-add.component.html',
styleUrls: ['./item-add.component.scss'],
})
export class ItemAddComponent {
@Output() itemAdded = new EventEmitter<Item>();
constructor(private itemService: ItemService) {}
addItem(name: string): void {
this.itemService.addItem(name).subscribe((item) => {
this.itemAdded.emit(item);
});
}
}In this new component, we are handling the addition of items to the list. It emits an itemAdded event when a new item is added to the list. We can now use this component in our ItemListComponent:
<app-item-add (itemAdded)="onItemAdded($event)"></app-item-add>
<ul>
<li *ngFor="let item of items">{{ item.name }}</li>
</ul>
@Component({
selector: 'app-item-list',
templateUrl: './item-list.component.html',
styleUrls: ['./item-list.component.scss'],
})
export class ItemListComponent implements OnInit {
items: Item[] = [];
constructor(private itemService: ItemService) {}
ngOnInit(): void {
this.itemService.getItems().subscribe((items) => {
this.items = items;
});
}
onItemAdded(item: Item): void {
this.items.push(item);
}
}In this article, we demonstrated how to apply the SRP to an Angular component that displays a list of items and allows the user to add new items. By extracting the responsibility of adding items into a separate component, we were able to create a more modular and maintainable solution.
Remember, the SRP is just one of five SOLID principles that can help us write better code. By applying all of these principles in conjunction with each other, we can create software that is both robust and flexible.
Thanks for your attention, if you like this article you can 👏 or write a comment.
Build Angular Apps with reusable components, just like Lego
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- Introducing Angular Component Development Environment
- 10 Useful Angular Features You’ve Probably Never Used
- Top 8 Tools for Angular Development in 2023
- Getting Started with a New Angular Project in 2023
- How We Build Micro Frontends
- How to Share Angular Components Between Projects and Apps
- How we Build a Component Design System
- Creating a Developer Website with Bit components
Best Design Principles in Angular was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Teslenko Oleh
Teslenko Oleh | Sciencx (2023-05-02T12:10:43+00:00) Best Design Principles in Angular. Retrieved from https://www.scien.cx/2023/05/02/best-design-principles-in-angular/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.