Il mio ecosistema React 2020
Una carrellata di librerie utili per il mio stack React
Sono quasi due anni che sviluppo su React e adoro la flessibilità che questa libreria offre in termini di ecosistema e features.
Nella prima parte cercherò di raccontare la mia esperienza con Redux in questi anni, riassunta a più non posso e di una alternativa; nella seconda parlerò più superficialmente delle altre librerie che uso per comporre il mio ecosistema.
Se prima Redux era il perno centrale su cui ruotavano tantissime soluzioni messe in atto a rendere consistente il flusso dei dati, oggi, per fortuna o per sfortuna non è più così.
Ho udito tante volte quel lamento: il mal di pancia di sviluppatori sofferenti che utilizzano (o sono costretti ad utilizzare) Redux. Al centro di questo malessere, la sua indigesta verbosità e la complessità che porta con se e che a volte, non sempre, si traduce in debito tecnico.
Quest’anno ho avuto modo di sperimentare redux-toolkit, una libreria che rende meno verboso e più semplice l’utilizzo di Redux grazie ad una serie di utilities built-in e sebbene attenui la quantità di codice scritto, non risolve completamente il problema. Questo l’ho riscontrato utilizzando redux-saga.
Qualcosa è cambiato
Sempre quest’anno ho avuto la fortuna di partecipare a molti più progetti. Come già detto il problema di Redux è l’eccessiva verbosità ed in progetti con scadenze vicine e trovandomi come unico sviluppatore stava diventando insostenibile psicologicamente. Ho cercato qualcosa che velocizzasse i tempi di sviluppo e soprattutto diminuisse il mio livello di frustrazione.
Dal momento che il caso d’uso più frequente con Redux era gestire il flusso dei dati che nella maggior parte dei casi proveniva da web services, ho cercato qualcosa che coprisse più quel caso specifico e React Query si da il caso che lo copre perfettamente.
All’inizio ero scettico perchè Tanner Linsley, autore di React Query, per farsi pubblicità faceva un ingiusto paragone tra quello che fa la sua libreria e Redux: se la prima copre un caso specifico, la seconda ne copre diversi: Redux si pone come un livello di astrazione e su questo non ci sono dubbi.
Ma d’altra parte aveva ragione, impossibile sfuggire all’evidenza.
Fino a quel momento ho usato Redux sì per tenere consistente il flusso dei dati, ma circoscritto ad uno use-case abbastanza ristretto: crud su web services.
La quality of life da quando ho adottato react-query sui miei progetti è notevolmente migliorata e fare optimistic update non è mai stato così facile.
HTTP client
A dare una notevole svecchiata al mio stack c’ha pensato wretch (su suggerimento del caro collega), una piccola libreria che wrappa fetch in maniera pulita, meno tediosa e più semplice.
Se non vi ho ancora convinto a dargli un occhio, allora vi faccio vedere questo:
// Fetch versionfetch("anything").then(response => {if(!response.ok) {if(response.status === 404) throw new Error("Not found")else if(response.status === 401) throw new Error("Unauthorized")else if(response.status === 418) throw new Error("I'm a teapot !")else throw new Error("Other error")}else // ...}).then(data => /* ... */).catch(error => { /* ... */ })// Wretch versionwretch("anything").get().notFound(error => { /* ... */ }).unauthorized(error => { /* ... */ }).error(418, error => { /* ... */ }).res(response => /* ... */).catch(error => { /* uncaught errors */ })// beh che dire
Internationalization framework
I18Next: Puro e semplice. Per me rimane la scelta migliore in quanto semplicità d’uso ed efficacia.
Gestione delle date
Al netto anche dell’imminente abbandono del progetto di moment, date-fns per me rimane l’alternativa preferita per lavorare con le date.
Una cosa che proprio non mi andava a genio di moment è che trasformava tutte le date in un oggetto Moment, costringendomi a parsare e riparsare oggetti Date in oggetti Moment o viceversa. Con date-fns invece, gli oggetti Date rimangono tali ed evita qualsiasi mal di testa.
Librerie css
Qui c’è da aprire un capitolo a parte per questo argomento, cercherò di essere sintetico.
Mi sento di consigliare styled-components ma dipende tantissimo dal tipo di progetto in cui vi trovate.
Ad esempio, trovo estremamente overkill l’utilizzo di styled-components in accoppiata ad un design system preesistente (change my mind) però lo utilizzerei nell’ottica di creare un design system da 0. Il riutilizzo e la temificazione assumono quindi un aspetto importante per la creazione di un design system robusto e sempre coerente e styled-components facilita di gran lunga il lavoro in tal senso.
In un progetto in cui è già presente un design system (esempio facile: material-ui) tutto questo non serve: difficilmente ci sono stilizzazioni importanti (e se ci sono, sotto mani non esperte si corre il rischio di infrangere le regole del design-system adottato) e non occorre aggiungere complessità ad un progetto che contiene già soluzioni adatte a casi d’uso generici. Inoltre librerie come material-ui, offrono la possibilità di modificare moltissimi elementi del design-system di base, permettendo di realizzare con il minimo sforzo, interfacce personalizzate e sempre coerenti.
Gestione dei form
React-form-hook la utilizzo da sempre e continua ad essere la migliore libreria per gestire i form.
In accoppiata con yup o joi che permettono di creare form validation altrimenti tediose e complicate, si dimostra semplice per form di qualsiasi complessità.
Conclusioni
È chiaro che tutte queste considerazioni contengono molte opinioni (non necessarie se vogliamo dirla tutta), ci tengo a precisare che sono state fatte in base alla mia esperienza personale e che non voglio convincere nessuno.
Sarei contento di ricevere alcune delle vostre opinioni in merito, voi cosa usate nel vostro ecosistema React?
