Migliori mockup nel browser con Node.js

Cominciamo!#section1

Installare Node in locale è facilissimo per gli ambienti più comuni. Potete scaricare degli installer che includono Node così come npm, il suo package manager, dal sito del progetto. Installarlo su un server remoto non è altrettanto semplice, ma abbiamo a disposizione della buona documentazione che può esserci d’aiuto. Dopo aver eseguito il processo di installazione, dovreste essere in grado di andare nel terminal o nella command line e testarlo.

Se non dite a Node di far girare un file specifico, avrete il Read-Eval-Print Loop, o REPL. Se scrivete node in terminal o sul prompt di comando, potete iniziare ad eseguire del JavaScript arbitrario. Per esempio, dopo aver avviato REPL, scrivete var a = 9;. REPL risponderà con “undefined”. Ora, scrivete a * 3 (o un qualsiasi altro numero) e vi risponderà con il risultato corretto. Potete rendere le cose più interessanti definendo una funzione e poi chiamandola:

> function sayHello( name ) { return “Hello, “ + name; }
undefined
> sayHello( “A List Apart” );
‘Hello, A List Apart’

Per uscire dal REPL, o per porre fine a qualunque altra esecuzione di Node (come un web server funzionante), premete Ctrl+C. Nel caso del REPL, dovrete farlo due volte per confermare.

Sebbene sia carino sapere che Node può fare un po’ di aritmetica base e di concatenazione di stringhe, il suo valore per noi developer sta nel far girare i programmi. Potete vedere un esempio di tale programma, un web server basilare, sulla homepage del progetto. Suggeriscono di creare un file chiamato example.js con questo codice:

var http = require(’http’);
http.createServer(function (req, res) {
  res.writeHead(200, {’Content-Type’: ‘text/plain’});
  res.end(’Hello World\n’);
}).listen(1337, ‘127.0.0.1’);
console.log(’Server running at http://127.0.0.1:1337/’);

Questo utilizza solo un modulo, il modulo core http. Come potrete immaginare, il modulo http contiene tutte le cose di base che ci servono per un sito su HTTP. Node contiene una collezione diligentemente editata di moduli core che forniscono cose come gli event handler, l’accesso al file system e le astrazioni di vari protcolli di rete. Ma proprio come probabilmente usereste una libreria JavaScript o un framework per accelerare e blindare lo sviluppo sul lato client, per lo sviluppo con Node oltre al semplice “Hello World” generalmente si aggiungono altri moduli non-core che usano npm.

Il modulo http contiene una funzione createServer, comunque, che è tutto quello di cui hai bisogno per creare un web server molto basilare. Nel codice qui sopra, una volta che il server è stato creato, ascolta sulla porta 1337 sulla vostra macchina locale. Quando riceve una richiesta, rimanda indietro una risposta testuale.

Una cosa da notare è che il lavoro in questo caso è svolto nell’event handler, come la maggior parte delle cose in Node. Il callback in createServer() gestisce un connection event, che occorre ogni volta che un nuovo cliente contatta il server. Per avviare questo server, scrivete node example.js nel termina e poi aprite un browser all’indirizzo http://127.0.0.1:1337. Questo fa partire un connection event e dovreste vedere il messaggio nel callback.

Per ottenere un qualunque valore serio da un server Node, anche uno che non andrà mai in produzione, è meglio acquisire un po’ di familiarità con i moduli in npm. Ce ne sono migliaia disponibili, ma quelli di cui avrete bisogno per creare un’applicazione web elementare sono alcuni tra i più vecchi e stabili, quindi non sentitevi in dovere di cercarli tutti prima di cominciare. Uno che sicuramente vi tornerà comodo per progettare un’applicazione è Express, un framework per applicazioni web tutt’altro che complicato.

Se siete abituati ad installare dei progetti open source clonando un repository GitHub o scaricando un file zip, probabilmente vi piacerà npm. Per installare Express con npm, per esempio, andate nel terminal o sulla riga di comando e scrivete npm install express. Fintanto che sarete online e avrete il permesso di scrivere sulla vostra macchina, questo farà il fetch di tutto il codice e di tutti gli asset di cui ha bisogno Express per girare, così come i moduli da cui ha dipendenze. La prima volta che farete girare npm dalla vostra directory di lavoro, tutti questi elementi finiranno in una nuova sotto-directory node_modules. Ora il modulo è pronto per essere usato nei programmi Node allo stesso modo in cui usavamo http, attraverso la funzione require.

Progettare applicazioni#section2

Lo use cas ideale per progettare le vostre applicazioni con Node è un’applicazione di una sola pagina nella quale il server fornisce la maggior parte dei dati, ma Node è ancora utile per un sito più tradizionale. Ovviamente, dovrete cominciare lo sviluppo con i requisiti definiti nella maniera più precisa possibile, ma l’implementazione di solito fa emergere dei requisiti che non erano stati considerati e alcuni di questi possono avere un considerevole impatto sulla vostra timeline. Anche in un’applicazione server-driven in cui potrebbe non essere possibile riutilizzare le strutture dati e i template così come sono, creare una versione client-only aiuta a testare le proprie supposizioni riguardanti i dati di cui si avrà bisogno e come li userete.

Se state sviluppando una app da una sola pagina, la giustificazione è molto più facile. Avrete bisogno di pensare all’ottimizzazione della comunicazione con il server perché vengano fatte meno richieste possibili, il che vuol dire conosce come i dati dovranno essere impacchettati da ogni estremità del server e il modo in cui metterete in cache i dati alla ricezione (sempre che ci sia).

Un vantaggio dell’avere JavaScript sul server è che i template possono essere resi dallo stesso template engine sia lato client sia lato server. Questo vi permette di sperimentare su entrambe i lati ed ottimizzare per la vostra situazione. È anche una cosa che fa risparmiare tempo rendere i template con oggetti JavaScript e considerare solo il modo in cui i dati saranno raggruppati alla fine (non come saranno memorizzati nel database). Progettare questi raggruppamenti di dati è il grosso del lavoro che possiamo fare con Node verso la fine di quella che consideriamo tradizionalmente la progettazione dell’applicazione.

Mettere insieme ciascuna pagina da parti diverse su tutto il server è difficile per una applicazione in qualsiasi linguaggio. Al contrario, qualunque cosa renda una pagina dovrebbe avere delle dipendenze chiare e il risultato di ciascuna pagina o di richiesta dati dovrebbe combinare queste dipendenze in un’unità integrata e sensatamente organizzata.

Se avete lavorato in un framework server-side nel quale una pagina o una view è legata a un singolo oggetto o modello e in cui i dati aggiuntivi sono importati ed esposti in modi diversi, probabilmente comprendete come l’alternativa diventi un fastidio. Sarete anche coscienti del fatto che la soluzione è un buon view-model i cui dati sono definiti da ciascuna view, non dai modelli che lo alimentano. Con questo esercizio, puntiamo a tracciare cosa va in questi view-model.

Usare i template#section3

C’è una buona probabilità che il vostro server di produzione non abbia JavaScript, quindi potreste ritrovarvi a convertire i template che producete in questa fase del design. Potreste tentare di mitigare questa cosa scegliendo un template engine come Mustache con dei parser esistenti per una miriade di linguaggi. Oppure potreste sceglierne uno con la minor logica possibile (trovo che le sole cose che voglio per un template davvero flessibile siano i costrutti condizionali – if, then, else -, i cicli e i partials) e l’opzione di cambiare i delimiter attorno ai tag del template in accordo con il linguaggio di template del server. Avrei da ridire sul fatto che il processo di ottenere tutti i dati correttamente piazzati nel proprio HTML sia molto più difficile che dare un “cerca e sostituisci” sul risultato finale, così la creazione di un template in JavaScript che potete usare facilmente è tempo ben speso, anche se non può essere analizzato dal vostro server di produzione.

Potreste scegliere di progettare la UI delle vostre pagine usando dei dati di mockup “hard-coded” prima e di aggiungere i tag di template dopo, oppure potreste cominciare con un template e alcuni dati di mockup pronti per andare nel vostro server Node. Anche se è un passo ulteriore, trovo che la prima soluzione sia più semplice, perché l’ultima tende a richiedere uno spostamento extra dei dati di mockup. Cominciare con dati “hard-coded” mi permette di esaminare il mockup finito e di vedere che tipi di “oggetti” sono presenti (ad es., un utente, un oggetto in vendita o uno status update). Questo mi aiuta a creare una gerarchia di oggetti flessibile in maniera più semplice nei miei dati. Ma potreste essere naturalmente fantastici nella creazione di gerarchie di oggetti, così, ovviamente, fate quello che preferite.

Da qualsiasi parte cominciate, elaborare i template dovrebbe darvi un’indicazione su quali parti di ciascuna pagina siano dinamiche e quali dati siano richiesti da ciascuna. Se le sottosezioni delle vostre pagine sono rese separatamente perché sono riutilizzate da diverse pagine più in alto nella gerarchia o perché sono rese anche dal client, convertire il markup in template vi permette anche di trovare il giusto equilibro tra il non ripetere mai del codice e l’avere dei template assurdamente piccoli.

Autentiche false interazioni server#section4

Se avete creato dei wireframe ad alta fedeltà che funzionano nel browser, sapete che fastidio sia avere solo delle parti di una pagina che sono interattive, dal momento che tutti i click comportano la creazione di una nuova view (anche se avete una serie di oggetti che condividono lo stesso comportamento quando vengono cliccati). Sapete anche cosa vuol dire copiare ed incollare gli stessi dati in posti differenti e aggiornare ciascuno di questi separatamente qualora la maniera di presentare i dati dovesse cambiare. Progettare la propria app con un server dietro rimuove queste frustrazioni.

Con il supporto di un server non ci sono problemi se gli stessi dati dovessero mostrarsi in visualizzazioni differenti per tutto il workflow che si sta progettando. Dal momento che i dati vivono sul vostro server Node, potete scriverli una volta e riutilizzarli nei modi in cui volete. Dovete ancora considerare come li sposterete dal server al client, però. Quando un utente clicca su uno dei molti oggetti di una lista, verrà portato in una nuova pagina o appariranno altri dai inline? Il primo rappresenta il fallback del secondo in caso di mancanza di JavaScript? Trovare la soluzione per la propria app vi dirà quale sia l’endpoint che occorre al server e quali parametri devono essere mandati in stringhe di query, form post o URL. Aiuterà anche definire l’API per quelle richieste, dicendo a tutti coloro i quali possono lavorare sul vostro server di produzione quali chiavi vi aspettate che corrispondano a quali pezzi di dati.

Avere un server con cui lavorare è particolarmente comodo se il vostro lavoro ha a che fare con la realizzazione di richieste asincrone. Ovviamente, potete avere i vostri dati di mockup, condizione eccellente, ma potete anche caricare degli asset come template o fogli di stile che consumino i dati. Testare il processo di passare dati e asset al client valida le vostre ipotesi riguardanti non solo il modo in cui li state impacchettando, ma anche il modo in cui li state memorizzando e strutturando. E, ovviamente, significa molto meno JavaScript client-side sprecato.

Un mockup che potete usare#section5

Il risultato finale di tutto questo dovrebbe essere quello di trasferire tutti i pezzi di mockup dal vostro JavaScript client-side e da HTML. Avete un server Node che potremmo non essere identico al framework di produzione, ma che ha davvero delle definizioni chiare di tutto quello che il client side si aspetta che esista, magari anche tutto visibile in un solo file. Avete template e richieste client-side che potrebbero richiedere delle sostituzioni ma che separano anche i dati da tutto il resto e sono come minimo facilmente convertibili a qualunque formato sia necessario per la produzione.

Potete fare lo stesso con un qualsiasi server già esistente? Certamente sì, ma se conoscete già JavaScript e non avete come obiettivo quello di diventare uno sviluppatore server-side, ha senso usare le conoscenze che avete già. Node lo rende piuttosto semplice e allo stesso tempo vi permette di approfondire quanto volete server sempre più complessi, nel caso dovessero cambiare le vostre ambizioni. È semplice incominciare con Node e lo si può estendere in maniera flessibile, caratteristiche che lo rendono un tool fantastico per progettare applicazioni.

Pronti per metter in pratica le vostre nuove conoscenze riguardanti Node? In “Node at Work: A Walkthrough,” vi guiderò in una demo live ed entreremo più nello specifico nei modi per rifinire i mockup.

Illustrazioni: {carlok}