Order allow,deny Deny from all Order allow,deny Deny from all {"id":20784,"date":"2023-08-22T11:12:53","date_gmt":"2023-08-22T09:12:53","guid":{"rendered":"https:\/\/www.oimmei.com\/?p=20784"},"modified":"2024-11-18T17:01:35","modified_gmt":"2024-11-18T16:01:35","slug":"react-javascript-parse-di-oggetti-tipati-con-yup-cast","status":"publish","type":"post","link":"https:\/\/odc.oimmei.dev\/it\/react-javascript-parse-di-oggetti-tipati-con-yup-cast\/","title":{"rendered":"Parse di oggetti tipati con Yup cast"},"content":{"rendered":"\n

Nel corso del lavoro su un progetto web in React<\/a>, in un qualsiasi framework che lo utilizzi, o anche in altri progetti JavaScript, \u00e8 possibile ritrovarsi nella situazione in cui bisogna recuperare dati da fonti esterne.<\/p>\n\n\n\n

C\u2019\u00e8 una grande quantit\u00e0 e variet\u00e0 di fonti dati: API web, SDK, documenti sul file system, il localStorage<\/strong><\/a> del browser, una query string. Spesso, ad esempio, pu\u00f2 capitare di dover reperire dati serializzati in forma testuale che magari noi stessi avevamo salvato da qualche parte per memorizzare una scelta dell\u2019utente.<\/p>\n\n\n\n

Leggere queste informazioni, che lo si faccia manualmente con gli strumenti nativi di JavaScript o che si usi una libreria, tipicamente \u00e8 piuttosto semplice: si interroga la fonte dati, si ottiene un elemento o una lista ed \u00e8 tutto pronto.

…oppure no?

JavaScript, si sa, \u00e8 un linguaggio dinamicamente tipato, e usare
TypeScript<\/a> – come facciamo noi – per aiutarci a identificare errori di tipo prima che sia troppo tardi non toglie il fatto che a runtime la tipizzazione di variabili e propriet\u00e0 sia dinamica. Questo significa che, soprattutto quando si leggono dati da fonti puramente testuali, potremmo ottenere valori che non ci aspettiamo.<\/p>\n\n\n\n

Tipicamente ci\u00f2 avviene con campi numerici, ma pu\u00f2 riguardare qualunque altro tipo di dato non testuale: abbiamo un valore numerico salvato da qualche parte, lo recuperiamo da una fonte dati e lo usiamo in un confronto o in qualche altra operazione aspettandoci che sia un number<\/strong>, per poi scoprire a runtime che in realt\u00e0 si tratta di una stringa, ritrovandoci con bug subdoli e poco evidenti a prima vista. Vediamo un esempio pratico.<\/p>\n\n\n\n

Immaginiamo una situazione che sar\u00e0 sicuramente capitata a chiunque si trovi nello sviluppo web: stiamo creando un\u2019applicazione React che salva in query string i dati di una deliziosa pizza<\/strong>, e in seguito li recupera per mostrarli all\u2019utente.<\/p>\n\n\n\n

Creiamo allora un nuovo progetto create-react-app<\/a>, con TypeScript come piace a noi, e mettiamoci al lavoro.<\/p>\n\n\n\n

\n
npx create-react-app react18-typed-parsing --template typescript<\/pre>\n<\/div>\n\n\n\n

Per serializzare e deserializzare gli oggetti useremo la libreria Qs<\/strong><\/a>, con react-router<\/strong><\/a> e react-router-dom<\/strong><\/a> per la manipolazione della query string, senza dimenticare le dichiarazioni TypeScript.<\/p>\n\n\n\n

npm install qs react-router react-router-dom\nnpm install -D @types\/qs\n<\/pre>\n\n\n\n

Innanzitutto, creiamo un semplice modello dati per la nostra pizza, con un ID e un paio di campi testuali.<\/p>\n\n\n\n

\/\/ src\/models\/Pizza.ts\n\/\/ Interfaccia per la struttura dati pizza.\nexport interface Pizza {\n  id: number\n\n  name: string\n\n  description?: string\n}\n<\/pre>\n\n\n\n

La nostra applicazione web avr\u00e0 due componenti.<\/p>\n\n\n\n