Frontend review

[kle-pra]

Super, da ste uporabili predlagane tehnologije. In tudi da ste dodali možnosti večih sob in pripadajočih rezervacij ter preverjanje, če je termin prost.

Frontend:

Všeč mi je

• da ste uporabili zadnjo verzijo Angular med razvojem
• da ste uporabili standalone komponente, nov način brez modulov
• da ste smiselno razbili po komponentah
• konstanta za URL v konfigu

Predlagani popravki

• da se doda strong type za Room, Reservation (kot v Javi models). Sedaj je tipa any, kar ni najboljše, typescript nam omogoča definiranje tipov
• tudi service klici lahko nato vračajo točen tip.
• uporaba private : če se funkcija uporabi samo v komponenti, se lahko označi kot private (private getDateTime ali #getDateTime)

[sysmat]

• všeč m i je zadnja verzija angular in standalone
• škoda da v templatih niste uporabili now control flow, @for
• škoda da niste uporabili bolj sodoben način z inject namesto konstruktorjem
• škoda da niste uporabili async pipe
• apiUrl je zafiksiran, kar ni vredu, kako bi to rešili

[BrawnyMan]

Hvala za vaše predloge. So izjemno koristni in se popolnoma strinjam z njimi.

• glede ngFor in @for: Izbral sem prvo možnost, ki sem jo našel na Angular spletni strani. Za @for sploh nisem vedel in vidim, da je boljši in sodobnejši,

• kar zadeva inject: Osebno nisem videl potrebe po tem in tudi nisem vedel, da je bolj sodobna praksa. To možnost bom raziskal in jo upošteval v prihodnje.

Glede apiUrl pa ne razumem točno, kar je narobe. Bi lahko prosim podali dodatno pojasnilo glede te težave?

[sysmat]

recimo da backend teče v PROD https://my.host.si/

[BrawnyMan]

Spremenil bi vrednost apiUrl v "https://my.host.si/"

[sysmat]

ne ni to rešitev

[sysmat]

v namig relative path & proxy

[BrawnyMan]

Na takšen način? (koda je samo primer logike)

const path = "/api"
let base: string;

if (NODE_ENV === "PROD") {
  base = "http://my.host.si";
} else {
  base = "http://localhost:7392";
}

const fullPath = base + path;

[BrawnyMan]

Posodobil sem kodo.

Spremenil sem:

• dodal models za Room, Reservation, ...
• uporabilprivate in vračanje točnih tipov,
• uporaba @for namesto ngFor,
• uporaba inject namesto konstruktorja,

Zanimam me glede async pipe. Trenutno pokličem .subscribe() na HTTP Request, ki že ima async v sebi. Je še vseeno bolje uporabiti async ali je .subscribe() vredu?

[kle-pra]

Hvala za popravke.

• Glede aync pipe, je prednost, da se v html templatu avtomatsko subscribe-a (ter unsubscribe-a) in velja za bolj "reactive, deklerativen način". Za branje/prikaz seznama navadno zadostuje ta način. Način s subscribe je tudi v redu, včasih celo ne gre drugače (odvisno kaj želimo, dodajanje rezervacije ob eventu bo vedno potreben subscribe), je pa potrebno potem tudi unsubscribe narediti za vse subscripcije (lahko ročno ali z takeUntil operatorjem,tehniko). Sicer so http client klici izjema in so auto unsubscribed, vsi ostali pa ne (subjecti itd ...), zato je dobro kar konsistentno uporabljati unsubscribe. Tu bi še opozoril, da je trenuten način uporabe subscribe v kodi deprecated (bolje podati celoten object z next in error) - VSCode nas na to opozori, tako da prečrta.

• Fajn da ste dodali modele za strong types. Tukaj bi predlagal da se poenoti SendingReservation in Reservation model v en, zares gre za isto stvar - rezervacijo, ko se ustvarja ali prikaže. Id polje je lahko opcijsko (id?: number). Naj se tudi konsistentno poimenuje interface-e ter funkcije - velike/majhne črke konsistentno. Za RoomResponse in Room bi tudi zares lahko uporabili isti Room model in DTO (saj vsebuje ime in room id) -> getRoomName bi postal getRoom in preko tega bi dobili ime sobe, da se malo poenostavi, je pa to bolj predlog. Namesto interface se pogosto uporbalja raje Type, je pa stvar preferenc, nič narobe z interface, zelo podobno

• V service funkcije in druge metode ste tipe lepo dodali, isto velja private polja. Tudi inject uporaba je OK - lahko se pa uporabi tudi v service za http client, predvsem da je konsistetno.

• @for - priporočam, da se namesto indeksa za track raje uporabi id (track reservation.id), kjer je možno - index lahko privede do težav pri brisanju iz seznamov, saj se spreminja.

Glede API URL pa je dober način z uporabo proxy conf - npr: https://stackoverflow.com/questions/37172928/how-to-proxy-api-requests-to-another-server/71764796#71764796