Nell'ultimo anno, il team di Polymer ha dedicato molto tempo a insegnare agli sviluppatori come creare i propri elementi. Ciò ha portato a un ecosistema in rapida crescita, sostenuto in gran parte dagli elementi Polymer Core e Paper 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 pongono diverse domande:
- Come dovresti strutturare la UI della tua applicazione?
- Come puoi eseguire 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 provato a rispondere a queste domande creando una piccola applicazione per i contatti e analizzando il processo che ho seguito per crearla. Ecco cosa ho trovato:
Struttura
La suddivisione di un'applicazione in componenti modulari che possono essere combinati e riutilizzati costituisce un tenant centrale dei componenti web. Gli elementi Polymer* Core-* e Paper-* permettono di iniziare con facilità con parti piccole, come core-barra degli strumenti e carta-icona-pulsante...
...e, grazie al potere della composizione, combinali con un numero qualsiasi di elementi per creare uno scaffold applicativo.
Dopo aver creato 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 consente di creare esperienze molto diverse sfruttando al contempo le stesse primitive di creazione delle app. Con uno scaffold attivo, puoi passare direttamente ai contenuti.
Un elemento particolarmente adatto alla gestione di una grande quantità di contenuti è core-list.
core-list può essere collegato a un'origine dati (sostanzialmente un array di oggetti) e, per ogni elemento nell'array, esclude un'istanza di 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, il compito successivo è capire come passare da una all'altra.
Sebbene sia ancora un elemento sperimentale, core-animated-pages fornisce un sistema di animazione collegabile che può essere utilizzato per la transizione tra diversi stati nell'applicazione.
Tuttavia, l'animazione è solo la metà del puzzle: un'applicazione deve combinare queste animazioni con un router per gestire correttamente i propri URL.
Nel mondo del routing dei componenti web, sono disponibili due versioni: imperativa e dichiarativa. La combinazione di core-animated-pages con entrambi gli approcci può essere valida a seconda delle esigenze del progetto.
Un router imperativo (come Direttore di Flatiron) può ascoltare una route corrispondente e chiedere a core-animated-pages di aggiornare l'elemento selezionato.
Questo può essere utile se devi svolgere del lavoro dopo la corrispondenza di un percorso e prima che venga eseguita la transizione della sezione successiva.
Invece, un router dichiarativo (come router app) può effettivamente combinare il routing e core-animated-pages in un singolo elemento, semplificando la gestione dei due elementi.
Per avere un controllo più granulare, puoi utilizzare una libreria come più percorsi, che può essere combinata con core-animated-pages tramite l'associazione di dati e che potrebbe offrirti il meglio di entrambi i mondi.
Prestazioni
Mentre la tua applicazione prende forma, devi fare attenzione ai colli di bottiglia delle prestazioni, in particolare a tutto ciò che è associato alla rete, poiché questa è spesso la parte più lenta di un'applicazione web mobile.
Un facile vantaggio in termini di prestazioni deriva dal caricamento condizionale dei polyfill di Web Components.
Non c'è motivo di sostenere tutti questi costi se la piattaforma dispone già del supporto completo. In ogni versione 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>
Inoltre, l'esecuzione di tutte le importazioni HTML tramite uno strumento come Vulcanize offre notevoli vantaggi di rete.
Sense concatena le importazioni in un singolo bundle, riducendo significativamente il numero di richieste HTTP effettuate dalla tua app.
Offline
Ma la sola 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 in realtà di un'app mobile. Oggi puoi utilizzare la cache delle applicazioni molto diffusa per offline le tue risorse, ma guardando al futuro, il service worker dovrebbe presto rendere molto più piacevole l'esperienza di sviluppo offline.
Jake Archibald ha recentemente pubblicato un fantastico libro di ricette sui modelli per i service worker, ma ecco un rapido esempio:
Installare un service worker è piuttosto semplice. Crea un file worker.js e registralo all'avvio dell'applicazione.
È importante che il tuo worker.js si trovi nella directory principale della tua applicazione, in modo che possa intercettare le richieste da qualsiasi percorso nella tua app.
Nel gestore delle installazioni del worker, eseguo la memorizzazione nella cache di un carico di risorse (inclusi i dati alla base dell'app).
In questo modo la mia app può fornire almeno un'esperienza di riserva all'utente se vi accede offline.
Avanti!
I componenti web sono una grande aggiunta alla piattaforma web e sono ancora agli inizi. Poiché saranno disponibili su più browser, spetterà a noi, la community degli sviluppatori, stabilire le best practice per strutturare le nostre applicazioni. Le soluzioni illustrate sopra sono un punto di partenza, ma c'è ancora molto da imparare. È il momento di creare app migliori.