Nell'anno precedente, il team di Polymer ha dedicato molto tempo a insegnare agli sviluppatori come creare i propri elementi. Questo 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 maggiore familiarità con la creazione dei propri elementi e iniziano a pensare alla creazione di applicazioni, vengono aperte una serie di domande:
- Come dovresti strutturare l'UI della tua applicazione?
- Come si effettua la transizione attraverso 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 il processo che ho svolto per crearla. Ecco cosa ho scoperto:
Struttura
La suddivisione di un'applicazione in parti modulari che possono essere combinate e riutilizzate è un tenant centrale di Web Componenti. Gli elementi core-* e paper-* di Polymer facilitano l'avvio da piccoli pezzi, come core-barra degli strumenti e paper-icon-button...
...e, attraverso il potere della composizione, combinali con un numero qualsiasi di elementi per creare un'impalcatura dell'applicazione.
Una volta realizzato uno scaffold generico, puoi applicare i tuoi stili CSS per trasformarlo in un'esperienza unica per il tuo brand. L'aspetto positivo di questa operazione con i componenti è che ti consente di creare esperienze molto diverse sfruttando le stesse primitive di sviluppo dell'app. Con un'impalcatura fissa puoi passare a pensare ai contenuti.
Un elemento particolarmente adatto a gestire molti contenuti è core-list.
core-list può essere collegato a un'origine dati (sostanzialmente un array di oggetti) e, per ogni elemento nell'array, verrà eliminata l'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
Con le varie sezioni della tua app progettate e implementate, l'attività successiva è capire come spostarsi da una all'altra.
Sebbene sia ancora un elemento sperimentale, core-animated-pages fornisce un sistema di animazione modulare che può essere utilizzato per passare da uno stato all'altro nell'applicazione.
Tuttavia, l'animazione è solo metà del puzzle e un'applicazione deve combinare queste animazioni con un router per gestire correttamente i propri URL.
Nel mondo dei componenti web, il routing può essere di due tipi: imperativo e dichiarativo. La combinazione di core-animated-pages con uno dei due approcci può essere valida a seconda delle esigenze del tuo progetto.
Un router imperativo (come Flatiron's Director) può rimanere in ascolto di un percorso corrispondente e quindi indicare a core-animated-pages di aggiornare l'elemento selezionato.
Questo può essere utile se devi svolgere qualche lavoro dopo la corrispondenza di un percorso e prima della transizione della sezione successiva.
D'altra parte, un router dichiarativo (come app-router) può effettivamente combinare il routing e core-animated-pages in un unico elemento, in modo da semplificare la gestione dei due dispositivi.
Per un controllo più granulare, puoi utilizzare una libreria come more-routing, che può essere combinata con core-animated-pages utilizzando l'associazione di dati e possibilmente ti offrono il meglio di entrambi i mondi.
Esibizione
Mentre la tua applicazione sta prendendo forma, devi tenere d'occhio i colli di bottiglia delle prestazioni, in particolare qualsiasi cosa associata alla rete, poiché questa è spesso la parte più lenta di un'applicazione web mobile.
Un facile risultato in termini di prestazioni deriva dal caricamento condizionale dei polyfill dei componenti web.
Non c'è motivo di sostenere tutti quei costi se la piattaforma ha già il supporto completo. In ogni release del nuovo repository webcomponents.js, i polyfill sono stati suddivisi 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>
L'esecuzione di tutte le importazioni HTML tramite uno strumento come Vulcanize consente inoltre di ottenere notevoli vantaggi in termini di rete.
Vulcanizza concatena le importazioni in un unico bundle, riducendo in modo significativo il numero di richieste HTTP effettuate dalla tua app.
Offline
Tuttavia, la creazione di un'app ad alte prestazioni non risolve il dilemma di un utente con connettività scarsa o assente. In altre parole, se la tua app non funziona offline, non si tratta davvero di un'app mobile. Oggi puoi utilizzare la cache delle applicazioni per offline le risorse, ma guardando al futuro il service worker dovrebbe presto rendere molto più piacevole l'esperienza di sviluppo offline.
Jake Archibald ha pubblicato di recente un incredibile libro di ricette sui pattern dei service worker, ma ecco un modo rapido per iniziare:
L'installazione di un service worker è facilissima. Crea un file worker.js e registralo all'avvio dell'applicazione.
È importante localizzare worker.js nella directory principale dell'applicazione, in modo che possa intercettare le richieste da qualsiasi percorso dell'app.
Nel gestore dell'installazione del lavoratore, memorizzi nella cache un carico di risorse (inclusi i dati su cui si basa l'app).
Ciò consente alla mia app di fornire almeno un'esperienza di riserva all'utente se vi accede offline.
Avanti!
I componenti web rappresentano una grande aggiunta alla piattaforma web e sono ancora agli albori. Quando arrivano su più browser, spetta a noi, la community degli sviluppatori, capire le best practice per strutturare le nostre applicazioni. Le soluzioni illustrate sopra ci danno un punto di partenza, ma c'è ancora molto da imparare. A partire dalla creazione di app migliori.