Come imparare React Native (e divertirsi)

I modi per imparare cose nuove sono molti, poterlo fare come momento dedicato è un'opportunità.

In Cantiere Creativo investiamo parte del nostro orario lavorativo alla formazione in vari modi: corsi, pairing tra colleghi, code review.

Ma anche in autonomia, sperimentando nuove tecnologie e argomenti inesplorati.

Nell'ultimo periodo ho avuto modo di approcciarmi da solo a React Native.

Avevo già utilizzato questo framework collaborando in piccola parte su qualche lavoro, ma ancora non avevo provato da solo a creare un nuovo progetto.

Come primo approccio è sempre bene partire da un progetto modesto per non perdersi nelle logiche di un qualcosa troppo complesso.

Un progetto più ampio deve rimanere duttile, quindi richiede sicuramente una buona organizzazione dei contenuti, una particolare attenzione alle logiche costruttive e un codice comprensibile in modo da rimanere mantenibile.

In un lavoro piccolo, con poche e semplici funzioni, è possibile andare per gradi e, quando si raggiunge una certa complessità ed è possibile ottimizzare, non è necessario stravolgere troppo.

Così si ha la possibilità di capire bene le logiche basilari e l'attribuzione delle responsabilità ai singoli componenti.

E questo è ciò che ho fatto, sono partito dal più piccolo elemento, ne ho studiato le necessità e la logica utile a realizzarlo, per poi passare al componente di livello superiore, che integrasse il primo.

Ma già a questo punto mi sono trovato a pensare a chi attribuire la responsabilità di gestire lo "stato": a chi spetta? Al primo o al secondo?

Ho avuto modo, quindi, di capire, grazie a vari refactor, come ottimizzare il mio codice già con soli due componenti abbastanza piccoli.

Sono certo che col tempo e con un po' di esperienza questi processi adesso lenti, saranno più veloci e spontanei nel mio approccio costruttivo, così da poter investire più tempo nella visione generale del progetto.

Questo è stato il metodo che ho cercato di applicare mentre costruivo la mia prima applicazione chiamata Figu!

Il tipico "esercizio" per chi inizia è la classica TODO App, che nella sua essenzialità racchiude tutti gli aspetti basilari: creazione, lettura, modifica ed eliminazione di dati, il cosiddetto CRUD (Create, Read, Update and Delete).

Ho pensato di dargli un taglio diverso e variare leggermente il percorso creando, invece, un gestore di album di figurine.

Ho così iniziato a creare il primo componente, la singola figurina.

Sembra forse il tassello più semplice, ma in realtà racchiude gran parte dello scopo della mia applicazione: indicare se ho già trovato quel "numero" e quante copie ne ho.

Il componente padre quindi è l'Album, ovvero il raccoglitore delle figurine, il vero elemento fondamentale, a cui ho deciso di attribuire la gestione dello stato di tutte le figurine.

Solo per far interagire questi due componenti ho fatto varie ottimizzazioni in più sessioni per cercare di ottenere il miglior risultato possibile con un codice pulito.

Ho pensato che avrebbe fatto comodo un resoconto di quanto mi manca a concludere la mia raccolta, rappresentato da una percentuale e una barra di progresso.

E poi un riquadro che mostri quante figurine ho trovato, quante me ne mancano e quanti "doppioni" ci sono.

Perché non condividere il tutto con gli amici? Ho aggiunto un bottone per la condivisione dei singoli sottogruppi.

L'ultimo ingranaggio di questo meccanismo rimane il sistema di creazione di un album con nome e quantità di figurine.

Una semplice modal che si apre al click dell'apposito bottone nella schermata principale.

Per concludere, all'apertura dell'app verrà mostrato un elenco di tutti i miei album con link al dettaglio e possibilità di essere eliminati dalla lista.

La mia applicazione quindi si riassume in due semplici "pagine": un elenco e un dettaglio.

In React (o React Native, come in questo caso) il passaggio di "proprietà" da un componente all'altro è pane quotidiano, non avrei avuto grossi problemi, quindi, a far arrivare tutti i dettagli di un album tra i miei 4-5 componenti attraverso le "props", anche se un po’ macchinoso.

Ma, visto che mi sto dedicando alla formazione, perché non approfondire la gestione dello stato di un'applicazione?

Quando ho iniziato a studiare React, l'ho sempre sentito nominare insieme a Redux (nota libreria nata proprio per questo scopo): confesso che fin da subito mi ha un po' intimorito, al solo pensiero di dover gestire almeno tre file.

Probabilmente non sono stato l'unico a provare questa sensazione, al punto che ha preso piede l'uso sempre più frequente di Context.

Context offre un sistema per condividere informazioni tra componenti senza per forza passare le props attraverso tutti i livelli della struttura, in maniera semplice (e gestibile anche in un solo file). Viene utilizzato principalmente quando i dati devono essere accessibili da molti componenti anche molto nidificati.

src/MyContext.js

In pratica con la funzione createContext si crea uno stato iniziale accessibile dai files in cui viene richiamato grazie al relativo Context.Provider.

Quest’ultimo si usa per “avvolgere” i componenti che useranno quello stato. Che sia quindi solo un gruppo ristretto oppure tutti i componenti della nostra applicazione.

src/App.js

In questo modo entrambi i componenti <Main /> e <Sidebar> avranno accesso al valore {theme} che rendiamo disponibile. 

È possibile creare più contesti diversi utilizzabili per condividere uno stato centralizzato specifico per i componenti che saranno inclusi nello specifico Provider.

Credo che nel mio esercizio questa fosse la strada giusta da prendere, conscio del fatto che se anche la mia applicazione dovesse scalare, potrò comunque continuare ad usare il Context senza problemi.

In fin dei conti sono in una fase di studio e come dice Dan Abramov nell'articolo "You Might Not Need Redux": 

E chi sono io per contraddire chi l'ha creato?!

Sembra scontato, ma può capitare di pensare che in un progetto piccolo si possa scrivere codice senza fare attenzione alla forma, limitandoci a "farlo funzionare".

Niente di più sbagliato!

Ho cercato di fare attenzione alla scrittura del mio codice, ma un controllo per valutare se ho mantenuto gli standard necessari era d'obbligo.

Una volta aggiunto un linter che mi indicasse gli errori da correggere, mi sono ritrovato a dover fixare circa 800 tra error e warning.

C'è da dire che gran parte erano piccolezze, ma come ho detto finora, sono dettagli che non vanno trascurati.

L'aspetto positivo è che ho capito due cose fondamentali: la prima è che nel prossimo progetto farò questo controllo dall'inizio per monitorare da subito il mio codice, la seconda è sicuramente l'insieme delle correzioni che ho fatto, sperando di ricordarmele già mentre scrivo.

Finita questa revisione, ho avuto modo di fare una code review con il nostro CTO, a cui ho spiegato il mio intento e con cui ho rivisto alcune parti della logica applicata.

In più mi ha suggerito altre best practices da applicare e da tenere a mente per garantire la qualità. Così, quando mi troverò a lavorare anche in piccole parti di un grande progetto, gli altri componenti del team sapranno che la sezione che ho costruito sarà qualitativamente soddisfacente.

Potete vedere Figu in azione in questo piccolo video, se siete curiosi!

Per arrivare alla soddisfazione di realizzare un grande progetto è bene ricordare tutte le piccole parti di cui è composto. Prendersi cura di ognuna di esse, con attenzione ai dettagli è fondamentale per il successo del risultato finale, cogliendo l’opportunità di migliorare le proprie competenze e acquisire maggiore consapevolezza.

Anche il più lungo dei viaggi si realizza con tanti piccoli passi.