Het afgelopen jaar heeft het Polymer-team veel tijd besteed aan het leren van ontwikkelaars hoe ze hun eigen elementen kunnen creëren. Dit heeft geleid tot een snelgroeiend ecosysteem, grotendeels gevoed door de Core- en Paper-elementen van Polymer, en de Brick-elementen die het team van Mozilla heeft ontwikkeld.
Naarmate ontwikkelaars meer vertrouwd raken met het creëren 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 stadia heen ?
- Wat zijn enkele strategieën om prestaties te verbeteren?
- En hoe zorg je voor een offline ervaring?
Voor de Chrome Dev Summit probeerde ik deze vragen te beantwoorden door een kleine contactenapplicatie te bouwen en het proces te analyseren dat ik daarvoor heb doorlopen. Dit is wat ik heb bedacht:
Structuur
Het opsplitsen van een applicatie in modulaire onderdelen die gecombineerd en hergebruikt kunnen worden, is een centraal principe van webcomponenten. De core-* en paper-* elementen van Polymer maken het gemakkelijk om met kleine onderdelen te beginnen, zoals paper-toolbar en paper-icon-button .
En door de kracht van compositie kunt u ze combineren met een willekeurig aantal elementen om een applicatieplatform te creëren.
Zodra je een generieke scaffold hebt, kun je je eigen CSS-stijlen toepassen om deze te transformeren tot een ervaring die uniek is voor jouw merk. Het mooie van dit met componenten doen, is dat je hiermee heel verschillende ervaringen kunt creëren met gebruikmaking van dezelfde app-bouwprincipes. Met een scaffold kun je verder met nadenken over de content.
Een element dat bijzonder geschikt is voor het verwerken van grote hoeveelheden content is de core-list .
De core-list kan worden gekoppeld aan een gegevensbron (in principe een array van objecten) en voor elk item in de array wordt een sjablooninstantie gegenereerd. Binnen de sjabloon kunt u de kracht van Polymers databindingssysteem gebruiken om uw content snel te koppelen.
Overgangen
Nadat u de verschillende onderdelen van uw app heeft ontworpen en geïmplementeerd, is de volgende taak om uit te zoeken hoe u daadwerkelijk tussen de onderdelen kunt navigeren.
Hoewel het nog een experimenteel element is, biedt core-animated-pages een plug-in animatiesysteem dat kan worden gebruikt voor overgangen tussen verschillende toestanden in uw toepassing.
Animatie is echter slechts de helft van de puzzel. Een applicatie moet die animaties combineren met een router om de URL's op de juiste manier te beheren.
In de wereld van webcomponenten kent routing twee varianten: imperatief en declaratief. Het combineren van core-animated-pages met beide benaderingen kan zinvol zijn, afhankelijk van de behoeften van uw project.
Een imperatieve router (zoals Flatiron's Director ) kan luisteren naar een overeenkomende route en vervolgens core-animated-pages opdracht geven om het geselecteerde item bij te werken.
Dit kan handig zijn als u nog wat werk moet doen nadat een route is gekoppeld en voordat het volgende gedeelte is begonnen.
Aan de andere kant kan een declaratieve router (zoals app-router ) routing en core-animated-pages daadwerkelijk combineren in één element, waardoor het beheer van beide gestroomlijnder wordt.
Als u meer gedetailleerde controle wilt, kunt u kijken naar een bibliotheek als more-routing . Deze kan worden gecombineerd met core-animated-pages met behulp van databinding en biedt u mogelijk het beste van beide werelden.
Prestatie
Terwijl uw applicatie vorm krijgt, moet u goed op prestatieknelpunten letten. Dit geldt met name voor alles wat met het netwerk te maken heeft. Dit is namelijk vaak het traagste onderdeel van een mobiele webapplicatie.
Een eenvoudige prestatieverbetering komt voort uit het voorwaardelijk laden van de polyfills van webcomponenten.
Er is geen reden om al die kosten te maken als het platform al volledige ondersteuning biedt! In elke release van de nieuwe webcomponents.js repository zijn de polyfills ook opgesplitst in zelfstandige bestanden. Dit is handig als je 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 netwerkvoordelen te behalen als u al uw HTML-imports uitvoert via een tool als Vulcanize.
Vulcanize voegt uw imports samen in één bundel, waardoor het aantal HTTP-verzoeken van uw app aanzienlijk wordt verminderd.
Offline
Maar het bouwen van een performante app lost het dilemma van een gebruiker met weinig of geen connectiviteit niet op. Met andere woorden: als je app niet offline werkt, is het niet echt een mobiele app. Tegenwoordig kun je de veelbesproken applicatiecache gebruiken om je resources offline te zetten, maar met het oog op de toekomst zou Service Worker de offline ontwikkelervaring aanzienlijk moeten verbeteren.
Jake Archibald heeft onlangs een geweldig kookboek met patronen voor dienstverleners gepubliceerd, maar ik zal je alvast een korte introductie geven om je op weg te helpen:
Het installeren van een service worker is vrij eenvoudig. Maak een worker.js -bestand aan en registreer het wanneer je applicatie opstart.
Het is belangrijk dat u uw worker.js in de hoofdmap van uw applicatie plaatst, zodat deze verzoeken vanaf elk pad in uw app kan onderscheppen.
In de installatiehandler van de worker cache ik een heleboel bronnen (inclusief de gegevens die de app aansturen).
Hierdoor kan mijn app de gebruiker in ieder geval een terugvalervaring bieden als hij de app offline gebruikt.
Vooruit!
Webcomponenten zijn een belangrijke toevoeging aan het webplatform en staan nog in de kinderschoenen. Naarmate ze in meer browsers beschikbaar komen, is het aan ons, de ontwikkelaarscommunity, om de beste werkwijzen voor het structureren van onze applicaties te vinden. Bovenstaande oplossingen geven ons een startpunt, maar er valt nog veel te leren. Op naar het bouwen van betere apps!