Nell'anno precedente, il team di Polymer ha dedicato molto tempo all'insegnamento agli sviluppatori di come creare i propri elementi. Ciò ha portato a un ecosistema in rapida crescita, sostenuto in gran parte dagli elementi Core e Paper di Polymer e dagli elementi Brick creati dal team di Mozilla.
Man mano che gli sviluppatori acquisiscono familiarità con la creazione dei propri elementi e iniziano a pensare alla creazione di applicazioni, si aprono una serie di domande:
- Come devi strutturare l'interfaccia utente della tua applicazione?
- Come si esegue la transizione tra stati diversi?
- Quali sono alcune strategie per migliorare il rendimento?
- E come dovresti offrire un'esperienza offline?
Per il Chrome Dev Summit, ho cercato di rispondere a queste domande creando una piccola applicazione per i contatti e analizzando la procedura che ho seguito per realizzarla. Ecco cosa ho trovato:
Struttura
Suddividere un'applicazione in componenti modulari che possono essere combinati e riutilizzati è un principio fondamentale di Web Components. Gli elementi core-* e paper-* di Polymer consentono di iniziare facilmente con piccoli componenti, come paper-toolbar e paper-icon-button.
E, grazie alla potenza della composizione, puoi combinarli con un numero qualsiasi di elementi per creare uno scheletro dell'applicazione.
Una volta creato uno scheletro generico, puoi applicare i tuoi stili CSS per trasformarlo in un'esperienza unica per il tuo brand. Il vantaggio di farlo con i componenti è che ti consente di creare esperienze molto diverse sfruttando le stesse primitive per la creazione di app. Una volta creato lo scheletro, puoi passare a pensare ai contenuti.
Un elemento particolarmente adatto per gestire molti contenuti è core-list.
core-list può essere collegato a un'origine dati (in pratica un array di oggetti) e per ogni elemento dell'array stamperà un'istanza del modello. All'interno del modello puoi sfruttare la potenza del sistema di associazione dei dati di Polymer per collegare rapidamente i tuoi contenuti.
Transizioni
Dopo aver progettato e implementato le varie sezioni dell'app, devi capire come passare da una all'altra.
Anche se è ancora un elemento sperimentale, core-animated-pages fornisce un sistema di animazione plug-in che può essere utilizzato per passare da uno stato all'altro nella tua applicazione.
Ma l'animazione è solo la metà del problema: un'applicazione deve combinare queste animazioni con un router per gestire correttamente i suoi URL.
Nel mondo di Web Components, il routing è disponibile in due versioni: imperativa e dichiarativa. La combinazione di core-animated-pages con uno dei due approcci può essere valida a seconda delle esigenze del progetto.
Un router imperativo (ad esempio Director di Flatiron) può ascoltare un percorso corrispondente e poi indurre core-animated-pages ad aggiornare l'elemento selezionato.
Questo può essere utile se devi eseguire alcune operazioni dopo la corrispondenza di un percorso e prima del passaggio alla sezione successiva.
D'altra parte, un router dichiarativo (come app-router) può combinare il routing e core-animated-pages in un unico elemento, in modo che la gestione di entrambi sia più snella.
Se vuoi un controllo più granulare, puoi utilizzare una libreria come more-routing, che può essere combinata con core-animated-pages utilizzando il binding dei dati e offrirti il meglio di entrambi i mondi.
Prestazioni
Man mano che l'applicazione prende forma, devi tenere d'occhio i colli di bottiglia delle prestazioni, in particolare tutto ciò che è associato alla rete, poiché spesso è la parte più lenta di un'applicazione web mobile.
Un modo semplice per migliorare il rendimento è caricare i polyfill di componenti web in modo condizionale.
Non c'è motivo di sostenere tutti questi costi se la piattaforma ha già un'assistenza completa. In ogni release del nuovo repository webcomponents.js, i polyfill sono stati suddivisi anche in file autonomi. Questa operazione è utile se vuoi caricare in modo condizionale un sottoinsieme di polyfill.
<script>
if ('import' in document.createElement('link')) {
// HTML Imports are supported
} else {
document.write(
'<script src="bower_components/webcomponentsjs/HTMLImports.min.js"><\/script>'
);
}
</script>
Esistono anche vantaggi significativi per la rete dall'esecuzione di tutte le importazioni HTML tramite uno strumento come Vulcanize.
Vulcanize concatena le importazioni in un unico bundle, riducendo notevolmente il numero di richieste HTTP effettuate dalla tua app.
Offline
Tuttavia, creare un'app ad alte prestazioni non risolve il dilemma di un utente con una connettività scarsa o nulla. In altre parole, se la tua app non funziona offline, non è davvero un'app mobile. Oggi puoi utilizzare la famigerata cache dell'applicazione per mettere offline le risorse, ma in futuro i service worker dovrebbero rendere l'esperienza di sviluppo offline molto più piacevole.
Jake Archibald ha recentemente pubblicato un fantastico cookbook di pattern di worker di servizio, ma ti fornirò una guida rapida per iniziare:
L'installazione di un service worker è abbastanza semplice. Crea un file worker.js e registralo all'avvio dell'applicazione.
È importante che tu localizzi worker.js nella directory principale dell'applicazione, in modo che possa intercettare le richieste da qualsiasi percorso dell'app.
Nel gestore dell'installazione del worker, memorizzo nella cache un sacco di risorse (inclusi i dati che alimentano l'app).
In questo modo, la mia app può fornire all'utente almeno un'esperienza di riserva se accede offline.
Avanti!
I componenti web sono una grande aggiunta alla piattaforma web e sono ancora agli inizi. Man mano che vengono implementati in più browser, spetterà a noi, alla community di sviluppatori, capire le best practice per strutturare le nostre applicazioni. Le soluzioni sopra indicate ci forniscono un punto di partenza, ma c'è ancora molto da imparare. Ora puoi creare app migliori.