Clean Entities

[rmandlx]

Clean Entities

[rmandlx]

1. Könnte klappen, muss das mal ausprobieren
2. Klar

[joluj]

Hat schon irgendwie geklappt, aber nicht schön.
Aber lass es so machen. Dann haben wir 3 Arten:

• Entities: für die Datenbank
• Dtos: fürn Austausch Frontend/Backend und ggf. für'n Store. Haben z.B. refs auf childrenIds, nicht auf children. Am besten auch ohne parentId usw
• ???: Für die App. Refs auf children Objekte, nicht auf ids

[rmandlx]

Also ich hab nochmal ein wenig experimentiert und bin mir jetzt ziemlich sicher, dass die Buildprobleme nicht von class-validator/typeorm, sondern einzig von @nestjs/swagger kommen (OmitType usw.)
deswegen denke ich, könnte man auch auf OmitType usw. verzichten und stattdessen Omit von Typescript selbst verwenden

export class ProductCreationDto implements Omit<ProductDto, 'id' | 'createdTime'>{
    @Expose()
    @IsString()
    name: string;
}

Einziger Nachteil wäre, dass man dann beim obigen Beispiel wahrscheinlich für name nochmal die Decorator setzen muss, da Omit<> ja ein Interface erzeugt, wodurch die Decorator aus ProductDto nicht mehr relevant sind. (Muss ich aber noch confirmen)

Aber immerhin hat man dann nicht so viel Codeduplikation. Dann können die Dtos, die im Backend sowieso schon zur Validierung benutzt werden, auch einfach im Frontend genau so verwendet werden.
Wie man dann im Frontend mit Entities umgeht ist Sache des Frontends, genauso wie es Sache des Backends ist, welche Entities man verwendet. Gemeinsame Basis stellen nur die Dtos dar.

[joluj]

1. Klappt es mit den swagger Zeug wenn man im Frontend import { ProductCreationDto } from '???'; mit import type { ProductCreationDto } from '???'; ersetzt? Da sollte dann hoffentlich auch nichts wirklich importiert werden.
2. Für Konsistenz der Namensgebung: kann man die Entities dann auch mit dem Postfix entity erstellen? Dann gibt es ProductEntity, ProductDto und Product

[joluj]

@richmandlx Weißt du noch, wie man das Problem reproduzieren konnte? Ich schaffs nicht mehr :D
Evtl. haben wirs auch dadurch gelöst, dass wir eben diese 3er Aufteilung haben und von den DTOs ausgehen.

[rmandlx]

es sollte wahrscheinlich reichen, ne klasse in angular zu verwenden, die in aus einer lib kommt, die von @nestjs/swagger abhängt. (klasse darf auch nicht nur für typchecking verwendet werden, wie es zum Beispiel bei httpclient.get<ProductDto>(...) der Fall wäre)
Das hatte bei mir schon gereicht um angular zu breaken :D
Die class-validator annotationen sollten garnicht so n großen problem sein, auch wenn diese warnings in der konsole verursachen.

[joluj]

Kk, ich probier's bei Zeiten nochmal damit. Hab's nur mit dem UserDto probiert und da gabs keine Probleme (außer die warnings wenn ich UserDto nicht nur als Typ verwendet hab, also z.B. const X = new UserDto ())

[joluj]

Es kommen keine Probleme auf :D

Für was braucht man @nestjs/swagger und warum ist das eine Abhängigkeit in den DTOs?

Die class-validator warnings kommen nicht, wenn man die Types wie im Screenshot verwendent, d.h. kein new ProductDto() schreibt, sondern nur die die types

[rmandlx]

Ums auch für die anderen nochmal klar zu machen:
el jablo und ich haben nochmal über die issues diskutiert und letztendlich wäre es schon geil die mapped-types von @nestjs/swagger zu verwenden. Das ist jetzt auch erstmal der plan, aber man kann dann die DTOs NUR als typen im frontend verwenden! So wie in jablos screenshot wird alles funktionieren. Sobald man aber bspw. const product = new ProductDto(...) macht, wird die dto lib (inklusive @nestjs/swagger) ins frontend mit eingebunden und weil @nestjs/swagger selbst wiederum viele dependencies hat, die im browser einfach nicht existieren, weil sie aus der node welt kommen (beispielsweise path), kann die angular app nicht mehr gebaut werden. Das sieht dann so aus:

Es gäbe einen relativ netten use case, für den ich trotzdem gerne die konkreten dto klassen im frontend benutzen würde: class-transformer
Dates werden übers netzwerk beispielsweise als strings gesendet. Also auch wenn im DTO ein Date definiert ist, wird im frontend nach dem api aufruf ein string ankommen. Ist halt wieder sehr fehleranfällig, weil der programmierer laut dto definition ein Date erwarten würde, aber sobald er irgendwann eine Date spezifische methode aufruft, wird es einen Fehler werfen... Das könnte man schön mit class-transformer handeln, indem man die http requests alle noch mal piped und plainToInstance verwendet:

this.httpClient.get<ProductDto>('test')
.pipe(dto => plainToInstance(ProductDto, dto, {excludeExtraneousValues: true}))
.subscribe(dto => {
   //das feld ist jetzt hier wieder ein Date, wenn der @Type(() => Date) decorator für das feld gesetzt wurde, danke an class-transformer :D
  console.log(dto.creationTime);
}

Aber wie gesagt, da @nestjs/swagger nicht mit dem frontend funktioniert, kann man das erstmal vergessen.
Ich hab mich auch mal über den obigen in rot geschriebenen Fehler informiert und denke, dass es sogar eine lösung wäre, zu sagen man will kein polyfill und konfiguriert einfach resolve.fallback {"path":false} aber ich hab nirgendwo im Netz gefunden, wo man das überhaupt konfigurieren könnte. Hier gibts n github issue, indem oft nur erklärt wurde, wie man den anderen fall löst, also dass es ein polyfill modul für den browser gibt und man das konfiguriert. Will aber auch nicht unnötig etliche polyfills definieren, die eh nicht gebraucht werden... angular/angular-cli#20819