SOLID Principles: Angular


S – Single Responsibility

Ex: A component cannot have multiple widgets which can instead be made as a reusable component for future.

 

Instead of

Do this

app.component.ts

<div>

<!--Navbar -->

  <nav>

  <ul>

    <li>Savings</li>

    <li>Deposits</li>

    <li>Loan</li>

  </ul>

  </nav>

  <!--card to display savings account details -->

  <div class="card-wrapper">

      <div class="header">CITI BANK</div>

    Account: AC29326262

    Balance: 5000

    Transactions avg: 3

     </div>

  </div>

  <!--card to display deposits details -->

  <div class="card-wrapper">

      <div class="header">CITI BANK</div>

    Account: AC29326262

    Deposits Total: 90000

    No. of Deposits: 6

     </div>

  </div>

</div>

app.component.ts

<nav-bar></nav-bar>

<card [type]=”savings”></card>

<card [type]=”deposits”></card>

 

navbar.component.ts

  <nav>

  <ul>

    <li>Savings</li>

    <li>Deposits</li>

    <li>Loan</li>

  </ul>

  </nav>

 

card.component.ts

<div *ngIf=”type == ‘savings’ >

<div class="card-wrapper">

      <div class="header">CITI BANK</div>

    Account: AC29326262

    Balance: 5000

    Transactions avg: 3

     </div>

  </div>

<div *ngIf=”type == ‘deposits >

<div class="card-wrapper">

      <div class="header">CITI BANK</div>

    Account: AC29326262

    Deposits Total: 90000

    No. of Deposits: 6

     </div>

  </div>

 

O- Open for extension, closed for modification

All the libraries are already good example of this as we only extend the use in out app but we do not have the control to the source file of the library. Above example is closed for modification, yes. Only savings and deposits type can be displayed. But not open for extension.

The savings and deposits cards should now be made as separate components.

Card component has to contain the header and <ng-content>

Savings and deposits components should use card component to fill the details in  <ng-content>

App.component.ts will have savings and deposits components

Now having just <card></card> will still display the structure of the card with empty content. It is now available for extension: <card> Test </card>

Card.component.ts

<div class="card-wrapper">

      <div class="header">CITI BANK</div>

      <ng-content></ng-content>

 </div>

App.component.html

Deposit.component.ts

Savings.component.ts

<savings></savings>

<deposits></deposits>

<card> test </card>

<card>

    Account: AC29326262

    Deposits Total: 90000

    No. of Deposits: 6

</card>

<card>

    Account: AC29326262

    Balance: 5000

    Transactions avg: 3

</card>

Output:


 

L – Liskov Substitution

Consider we have export to csv/download button in the content of both savings and deposits component. This is now redundant code. Let us have a separate download directive. This download directive now acts as a parent/base class


 

Parent/base component

Download.component.ts

@Directive({ selector: 'download' })

export class DownloadComponent {

  download() {

    alert('Downloading in parent class...');

  }

}

 

Now if savings component extends this base directive and also has the same ‘download()’ method, it is a violation of Liskov’s principle.

WRONG

RIGHT

Savings.component.ts

<button (click)=”download()”>

    Download

<button>

 

export class SavingsCardComponent extends DownloadComponent {

  download() {

    alert('I do not support it...');

  }

}

 

Output: ‘I do not support it’

Savings.component.ts

<button (click)=”download()”>

    Download

<button>

 

export class SavingsCardComponent extends DownloadComponent {

  download() {

    super.download();

    alert('I do not support it...');

  }

}

Output: ‘Downloading in parent class’

                ‘I do not support it’

 

Note: Implementation of the same function of the parent class should not be replaced.

 

I – Interface Segregation Service: Many client-specific interfaces are better than one general-purpose interface

One big interface is split into smaller interfaces as few properties might not be valid for all components that implement it

Ex: export interface ICard {

                Title:string,

                isLoading: Boolean,

                interest: number

}

Now, the deposits component needs to calculate interest but not savings component.

Savings.component.ts

Deposits.component.ts

export class savings implements ICard {

  Title=’’;

  isLoading=false;

  interest=0; //not needed. Still need to have atleast default as ICard is “implemented”

}

export class savings implements ICard {

  Title=’’;

  isLoading=false;

  interest=6;

}

 

So have another Interface:

export interface ICard {

                amount:number,

                isLoading: Boolean,

                interest: number

}

export interface ICard {

                amount:number,

}

export interface ICardInterest {

                isLoading: Boolean,

                interest: number

}

And import each of it separately where needed:

Savings.component.ts

Deposits.component.ts

export class savings implements ICard {

  amount=82323;

  isLoading=false;

  interest=0; //not needed. Still need to have atleast default as ICard is “implemented”

}

export class savings implements ICard, ICardInterest {

  amount=3737;

  isLoading=false;

  interest=6;

}

 

 

D - Dependency Inversion Principle: High level modules should not depend on low-level modules. It should depend upon abstraction

This has to be kept in mind every time Dependency Injection is used.

Consider you need to do some calculation in card component where <ng-content> is present based on whether the “interest” is present in that component or not. In card component you can use ‘@ContentChild()’ to load the deposits/savings component and check if “interest” property is present on not.

export class CardComponent {

  @Input() type;

  @ContentChild(DepositsCardComponent) depositCmp?: DepositsCardComponent;

  ngAfterContentInit() {

    alert(this.depositCmp);

    if (this.depositCmp) {

      alert('interest present....');

    }

  }

}

 

This is the violation of rule because there is a hard dependency on the component name directly. What we are interested in is any component in the ng-content that has the “interest” property.

So create abstraction:




StackBlitz Reference: https://angular-ivy-pguqxi.stackblitz.io



 

Comments

Post a Comment

Popular posts from this blog

Inside the JavaScript Memory Box: Visualizing Variables, References, and Copies

Image
There is a difference in the way JavaScript refences variables based on whether they are primitive or non-primitive Primitive Types: string, number, bigint, Boolean, symbol, null, undefined Non-Primitive: Arrays, Objects Each variable in JS is stored in a memory “box” Assignments: But when another variable tries to assign this value, JS thinks “wait, is this a primitive or non-primitive? Because if it is primitive, I will create a new box for this new variable with the same content. But if it’s not, I will just create a refence to the existing box” PRIMITIVE: Analogy: Let's say you have a note that says 5. You give a copy of this note to your friend.  Friend now updates this copy to 10. But your copy still says 5 let a = 5; let b = a; b = 10; //a remains unchanged NON-PRIMITIVE: Analogy: Let's say you have a note with address "123 Elm Street". In that house lives a cat named "Tom". You give a copy of this note to your friend. Friend now goes t...
Read more

React & State Management: All Concepts

Section 1: Fundamentals 1. Counter with increment, decrement, reset — useState Remember: prev is needed when the new state depends on the old state. When you're setting a hardcoded value like 0, you just pass 0 directly. Why:  reason prev matters — if multiple state updates happen in the same render cycle, React batches them. Using prev guarantees you're working off the latest state, not a stale snapshot. 2. Toggle show/hide paragraph — useState Remember: onClick={toggle} — pass the function reference, not the call. onClick={() => toggle()} — also fine, arrow function that calls toggle when clicked. onClick={toggle()} — calls toggle immediately during render, setVisible triggers re-render, toggle calls again, infinite loop. Why: JSX evaluates expressions inside {} during render. toggle() is an expression that executes immediately. React doesn't get a chance to attach it as a handler — it just runs it right there, state updates, component re-renders, runs again. ...
Read more

React: Communication between components

Parent to Child: Props Child to Parent Callback Props (advanced props) Controlled Components useImperative hook  Nested Tree: useContext Sibling: Lift State Up PARENT TO CHILD: Props App.jsx Users.jsx <User name ={user} /> function User({ name }) {  return <h1> {name} </h1> } CHILD TO PARENT a) Callback Props (Advanced Props) Parent.jsx Child1.jsx export function Parent() {   function sayHello () {     alert(“hello triggered”)   }   <Child1 onSayHello ={ sayHello } /> } function Child1({ onSayHello }) {   return <button onClick={ onSayhello() }>          Click       </button> } b) Controlled Components Usually used in forms. Controlled components mean the parent owns the state, the child renders inputs, and every ch...
Read more