Het afgelopen jaar heeft het Polymer-team veel tijd besteed aan het leren van ontwikkelaars hoe ze hun eigen elementen konden maken. Dit heeft geleid tot een snelgroeiend ecosysteem, grotendeels ondersteund door de Core- en Paper-elementen van Polymer, en de Brick-elementen gemaakt door het team van Mozilla.
Naarmate ontwikkelaars meer vertrouwd raken met het maken van hun eigen elementen en beginnen na te denken over het bouwen van applicaties, roept dit een aantal vragen op:
- Hoe moet u de gebruikersinterface van uw applicatie structureren ?
- Hoe ga je door verschillende staten heen?
- Wat zijn enkele strategieën om de prestaties te verbeteren?
- En hoe zorg je voor een offline ervaring?
Voor Chrome Dev Summit heb ik geprobeerd deze vragen te beantwoorden door een kleine contactenapplicatie te bouwen en het proces te analyseren dat ik heb doorlopen om deze te bouwen. Dit is wat ik bedacht heb:
Structuur
Het opdelen van een applicatie in modulaire stukken die gecombineerd en hergebruikt kunnen worden is een centrale huurder van Web Components. De kern-* en papier-*-elementen van Polymer maken het gemakkelijk om met kleine onderdelen te beginnen, zoals de papierwerkbalk en de papierpictogramknop .
En dankzij de kracht van compositie kunt u ze combineren met een willekeurig aantal elementen om een toepassingsscaffold te creëren.
Zodra u over een generiek platform beschikt, kunt u uw eigen CSS-stijlen toepassen om deze te transformeren in een ervaring die uniek is voor uw merk. Het mooie van dit doen met componenten is dat je heel verschillende ervaringen kunt creëren terwijl je dezelfde primitieven voor het bouwen van apps gebruikt. Als er een steiger staat, kun je verder nadenken over de inhoud.
Een element dat vooral geschikt is voor het omgaan met veel inhoud is de core-list .
De core-list kan worden verbonden met een gegevensbron (in feite een array van objecten), en voor elk item in de array wordt een sjablooninstantie uitgeroeid. Binnen de sjabloon kunt u de kracht van het gegevensbindingssysteem van Polymer benutten om uw inhoud snel aan te passen.
Overgangen
Nu de verschillende secties van uw app zijn ontworpen en geïmplementeerd, is de volgende taak het uitzoeken hoe u ertussen kunt navigeren.
Hoewel het nog steeds een experimenteel element is, biedt core-animated-pages een inplugbaar animatiesysteem dat kan worden gebruikt om over te schakelen tussen verschillende statussen in uw applicatie.
Maar animatie is slechts de helft van de puzzel; een applicatie moet deze animaties combineren met een router om de URL's goed te kunnen beheren.
In de wereld van webcomponenten bestaat routering in twee smaken: imperatief en declaratief. Het combineren van core-animated-pages met beide benaderingen kan geldig zijn, afhankelijk van uw projectbehoeften.
Een imperatieve router (zoals Flatiron's Director ) kan luisteren naar een overeenkomende route en vervolgens core-animated-pages instrueren om het geselecteerde item bij te werken.
Dit kan handig zijn als u wat werk moet doen nadat een route overeenkomt en voordat het volgende gedeelte is overgegaan.
Aan de andere kant kan een declaratieve router (zoals app-router ) routing en core-animated-pages in één enkel element combineren, waardoor het beheer van de twee gestroomlijnder wordt.
Als je meer fijnmazige controle wilt, kun je naar een bibliotheek zoals more-routing kijken, die kan worden gecombineerd met core-animated-pages met behulp van databinding en je mogelijk het beste van twee werelden geeft.
Prestatie
Terwijl uw applicatie vorm krijgt, moet u prestatieknelpunten in de gaten houden, vooral alles wat met het netwerk te maken heeft, aangezien dit vaak het langzaamste onderdeel van een mobiele webapplicatie is.
Een gemakkelijke prestatiewinst komt voort uit het voorwaardelijk laden van de polyfills van Web Components.
Er is geen reden om al die kosten te maken als het platform al volledige ondersteuning heeft! In elke release van de nieuwe webcomponents.js repository zijn de polyfills ook opgesplitst in zelfstandige bestanden. Dit is handig als u een subset van de polyfills voorwaardelijk wilt laden.
<script>
if ('import' in document.createElement('link')) {
// HTML Imports are supported
} else {
document.write(
'<script src="bower_components/webcomponentsjs/HTMLImports.min.js"><\/script>'
);
}
</script>
Er zijn ook aanzienlijke netwerkwinsten te behalen door al uw HTML-imports via een tool als Vulcanize uit te voeren.
Vulcanize voegt uw imports samen in één bundel, waardoor het aantal HTTP-verzoeken dat uw app doet aanzienlijk wordt verminderd.
Offline
Maar alleen het bouwen van een performante app lost het dilemma van een gebruiker met weinig of geen connectiviteit niet op. Met andere woorden: als uw app niet offline werkt, is het niet echt een mobiele app. Tegenwoordig kunt u de veel verguisde applicatiecache gebruiken om uw bronnen offline te zetten, maar als we naar de toekomst kijken, zou Service Worker de offline ontwikkelervaring binnenkort veel leuker moeten maken.
Jake Archibald heeft onlangs een geweldig kookboek met patronen voor servicemedewerkers gepubliceerd, maar ik zal je een snelle start geven om je op weg te helpen:
Het installeren van een servicemedewerker is heel eenvoudig. Maak een worker.js bestand en registreer dit wanneer uw toepassing opstart.
Het is belangrijk dat u uw worker.js in de hoofdmap van uw toepassing plaatst, zodat deze aanvragen van elk pad in uw app kan onderscheppen.
In de installatiehandler van de werknemer cache ik een hele reeks bronnen (inclusief de gegevens die de app aandrijven).
Hierdoor kan mijn app de gebruiker op zijn minst een terugvalervaring bieden als deze deze offline gebruikt.
Voorwaarts!
Webcomponenten zijn een grote toevoeging aan het webplatform en staan nog in de kinderschoenen. Naarmate ze in meer browsers terechtkomen, is het aan ons, de ontwikkelaarsgemeenschap, om de best practices te bedenken voor het structureren van onze applicaties. De bovenstaande oplossingen geven ons een startpunt, maar er valt nog veel meer te leren. Op naar het bouwen van betere apps!