Validate HTTP response with Zod in Angular

Learn how to integrate #zod into your #angular applications.
In this video, you can start your journey with Zod and Angular
Install
Create schemas
Parse HTTP response
Create a custom #rxjs operator
You can find the source code here (github.com/Pup...)
_______________________________
If you feel my speaking is incomprehensible... you're probably right!
I'll write an article soon, and I'll link it here.
_______________________________
Hit like and subscribe for more content! :D
You can also follow me on the other platforms:
Twitter: / puppo92
dev.to: dev.to/puppo
GitHub: github.com/puppo
_______________________________
Thanks to:
Music by Playsound (pixabay.com/us...) from Pixabay (pixabay.com//?...)
Canva (www.canva.com/)

[@Alessandro_Russo]

Mi è chiaro tutto. Possibili applicazioni reali? Cosa giustificherebbe il codice boilerplate necessario per ogni interfaccia?

[@Puppo_92]

Io tendenzialmente lo uso sempre per mappare DTO! La garanzia di avere a runtime i tipi che mi aspetto in fase di build, mi permette in caso di problemi con le api, perché per esempio è stata cambiata una firma senza che tutti fossero avvisati, di recepire l’errore il prima possibile e magari prima che un cliente si lamenti di leggere un NaN nell’applicazione.
Sul fatto del boilerplate non credo che scrivere lo schema crei un codice poi così “lungo” che scrivere interfaccia o il tipo. La differenza sta su import di Zod e eventuale z.infer se si vuole esportare anche il tipo.
Tutto sta nel beneficio e nella volontà di garantire i tipi che ci si aspetta a buildtime anche a runtime. Garantendo che i DTO siano come ci aspettiamo possiamo supporre che tutto il resto della nostra applicazione giri propio come ci si aspetti e come i test dovrebbero rispecchiare. Il layer di validazione delle API a mio avviso è sempre poco gestito a livello FE, ma quel layer è uno dei più deboli della nostra applicazione e va protetto al meglio! Da quel layer entrano dato che non dipendono da noi purtroppo e se entra qualcosa di inaspettato saperlo il prima possibile e notificate l’utente che qualcosa non va è a mio avviso molto più importante che non pensarci e permettere al codice di proseguire e eseguire metodi e funzioni con dati che non ci aspettiamo, dando poi all’utente informazioni errate o strane che non si aspetta. Spero di averti dato le risposte che cercavi. Se non ti torna o hai altro da chiedere sai dove trovarmi in caso 🙂 o possiamo anche sentirci se pensi sia più utile. Questo ovviamente è il mio pensiero in base alla mia esperienza quotidiana, non è sicuramente legge e sono aperto a sentire anche altre opinioni ovviamente 🙂

[@Alessandro_Russo]

@@Puppo_92 Top, hai risposto a tutti i miei dubbi e anche a quelli che nel frattempo mi erano venuti. Altro che ChatGPT. Grazie!

[@Alessandro_Russo]

@@Puppo_92 Si è proprio un layer in aggiunta. Si dovrà valutare in fare architetturale se c'è una vera necessità in base al progetto.

[@Puppo_92]

@@Alessandro_Russo si esatto! Io tendenzialmente lo prevedo quasi sempre nei progetti che seguo. E poi faccio in modo che il client http che usiamo obblighi il passaggio dello schema in modo da “obbligare” tutti a gestire la cosa. Chiaro devi creare lo schema o poi il tipo. Ma come puoi aver visto la sintassi tra uno schema Zod è un tipo ts non è poi così diversa e poi va aggiunto il tipo se necessario. Comunque come tutte le cose va valutata dal progetto. Ecco ciò che ho notato che comunque è una cosa che con “poco” sforzo garantisce molto. E comunque tutti i membri del team ci mettono veramente poco a switchare da interface o types a schema Zod.