typescript - Klasser och objekt i Angular

Finns det något problem med att använda konventionella klasser och objekt i koden när man använder Angular?

Till exempel, ibland, när jag refaktoriserar och jag vill separera en specifik logik som är blandad i en rörig kod gör jag något liknande...

logik-hanterare.ts

export class LogicHandler {
  var1: Obj1;
  var2: Obj2;

  constructor(/* ... */) { /* ... */ }
}

...och jag skapar ett objekt av denna klass för att hantera denna specifika logik, inom component.ts-filen.

Problemet är att det fanns en senior på mitt team som alltid sa att han inte gillade den här idén eftersom han inte visste hur Angular hanterar new LogicHandler();.

Så, finns det en verklig anledning att oroa sig för detta?

Jag hoppas att någon kan svara på min fråga eller ge en bättre lösning på det presenterade problemet.

Faktum är att att göra det på det sätt jag föreslår är enklare och lättare att testa.

Svar #1

Som antytts av @browsermator i kommentarerna till frågan, finns det absolut inget problem med att använda vanliga klasser för andra ändamål än för Angular-komponenter.

Din appkod är vanlig TypeScript- (och JavaScript-)kod, så klasser stöds.

Vad Angular gör under sin AOT-fas är att plocka upp alla klasser som är dekorerade med @Component, kapsla in dem (t.ex. för att länka med template och stil) och hantera all instansiering under körning (new…). Samma gäller för tjänster och moduler.

Därför, så länge du inte dekorerar dina vanliga klasser med Angular-grejer, lämnar Angular dem ifred, och du kan använda dem som i en icke-Angular-värld.

Förresten finns det stor sannolikhet att du redan använder en sådan vanlig klassinstansiering, typiskt med new Date() (även om det är genom bibliotek som date-fns och liknande), vilket bevisar att det inte finns några kompatibilitetsproblem med Angular.

Svar #2

Genom att forska mer om ämnet kunde jag se att det enda problemet med detta tillvägagångssätt är att jag skapar ett beroende mellan min komponent och LogicHandler.

Så, om jag till exempel behöver testa min komponent kommer jag inte kunna mocka detta objekt enkelt, eftersom beroendet finns inuti komponenten och inte injiceras i den. Därför respekterar det inte SOLID-principens beroendeinversionsprincip (DIP).

Därför skulle det korrekta alternativet i detta fall vara att skapa LogicHandler som en tjänst och injicera den i min komponent via konstruktören.

Kort sagt är det en principfråga att aldrig instansiera ett objekt direkt inom en annan klass, just därför att ett objekt aldrig ska vara ansvarigt för sina beroenden.