W ubiegłym roku zespół Polymer spędził dużo czasu na uczenie programistów tworzenia własnych elementów. Doprowadziło to do szybkiego rozwoju ekosystemu. Gwarantują go elementy Core i Papier firmy Polymer oraz elementy klocków utworzone przez zespół Mozilli.
W miarę jak programiści zaczynają lepiej tworzyć własne elementy i zaczynają myśleć o tworzeniu aplikacji, pojawia się szereg pytań:
- Jak zaprojektować strukturę interfejsu Twojej aplikacji?
- Jak przejście przez różne stany?
- Jakie strategie mogą poprawić skuteczność?
- Jak zadbać o możliwość korzystania z funkcji offline?
Aby znaleźć odpowiedź na te pytania podczas wydarzenia Chrome Dev Summit, stworzyłem małą aplikację do obsługi kontaktów i przeanalizowałem proces jej utworzenia. Oto co wymyśliłam:
Struktura
Głównym najemcą komponentów sieciowych jest podzielenie aplikacji na moduły, które można łączyć i ponownie wykorzystywać. Elementy podstawowe* i papier-* w aplikacji Polymer ułatwiają rozpoczęcie pracy od mniejszych elementów, takich jak core-Tool i paper-icon-button...
...a dzięki mocy kompozycji możesz połączyć je z dowolną liczbą elementów, aby stworzyć rusztowanie aplikacji.
Po utworzeniu ogólnego rubryka możesz zastosować własne style CSS, aby przekształcić je w doświadczenie charakterystyczne dla Twojej marki. Dzięki komponentom możesz tworzyć bardzo różne funkcje, jednocześnie korzystając z tych samych podstawowych elementów tworzenia aplikacji. Mając surowe zasady, możesz przejść do myślenia o treściach.
Elementem, który szczególnie sprawdza się w przypadku dużej ilości treści, jest core-list.
Element core-list można połączyć ze źródłem danych (zasadniczo tablicą obiektów) i dla każdego elementu w tablicy oznacza wystąpienie szablonu. Szablon pozwala szybko tworzyć materiały dzięki systemowi wiązania danych Polymer.
Przejścia
Po zaprojektowaniu i zaimplementowaniu różnych sekcji aplikacji kolejnym zadaniem jest ustalenie, jak rzeczywiście poruszać się między nimi.
Chociaż nadal jest to element eksperymentalny, core-animated-pages zawiera możliwy do podłączenia system animacji, którego można używać do przełączania się między różnymi stanami aplikacji.
Animacja to jednak tylko połowa układanki – aplikacja musi połączyć te animacje z routerem, aby prawidłowo zarządzać swoimi adresami URL.
W świecie komponentów sieciowych kierowanie ruchu ma 2 sposoby: imperatywny i deklaratywny. Połączenie zasady core-animated-pages z dowolną metodą może być skuteczne w zależności od potrzeb projektu.
Router imperatywny (np. Flatiron's Director) może nasłuchiwać pasującej trasy, a następnie nakazywać usłudze core-animated-pages zaktualizowanie wybranego elementu.
Jest to przydatne, gdy musisz wykonać pewne czynności po dopasowaniu trasy, ale przed przeniesieniem następnej sekcji.
Z drugiej strony router deklaratywny (np. app-router) może połączyć w jeden element routing i core-animated-pages, dzięki czemu zarządzanie tymi 2 elementami stanie się prostsze.
Jeśli potrzebujesz bardziej precyzyjnej kontroli, możesz skorzystać z biblioteki takiej jak większa częstotliwość routingu, którą można połączyć z ustawieniem core-animated-pages za pomocą wiązania danych i być może w obu rozwiązaniach.
Wyniki
W miarę rozwoju aplikacji musisz zwracać uwagę na wąskie gardła wydajności, zwłaszcza te związane z siecią, ponieważ jest to często najwolniejszy element aplikacji internetowej na komórki.
Łatwą poprawę wydajności wynika z warunkowego wczytywania elementów uzupełniających komponentów sieciowych.
Nie ma sensu ponosić tylu kosztów, jeśli platforma ma już w pełni wsparcie. W każdej wersji nowego repozytorium webcomponents.js elementy polyfill dzielimy też na samodzielne pliki. Jest to przydatne, gdy chcesz warunkowo wczytywać podzbiór zasobów 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>
Uruchamianie wszystkich importów HTML za pomocą takich narzędzi jak Vulcanize może przynieść znaczne korzyści sieciowe.
Vulcanize połączy zaimportowane dane w jeden pakiet, znacznie ograniczy liczbę żądań HTTP wysyłanych przez aplikację.
Offline
Jednak samo stworzenie wydajnej aplikacji nie rozwiązuje problemu użytkownika, który ma połączenie z internetem lub nie ma go wcale. Innymi słowy, jeśli aplikacja nie działa w trybie offline, to nie jest aplikacją mobilną. Obecnie możesz używać w bardzo niedopracowanej pamięci podręcznej aplikacji do wyłączania zasobów. W przyszłości użycie skryptu service worker powinno wkrótce ułatwić proces programowania w trybie offline.
Jake Archibald opublikował niedawno niesamowitą książkę kucharską z opisem wzorców pracowników usługowych, ale poniżej znajdziesz kilka wskazówek, które ułatwią Ci zadanie:
Instalacja mechanizmu Service Worker nie jest już prosta. Utwórz plik worker.js i zarejestruj go po uruchomieniu aplikacji.
Ważne jest, aby znaleźć worker.js w katalogu głównym aplikacji – pozwoli to na przechwytywanie żądań z dowolnej ścieżki w aplikacji.
W module instalacyjnym instancji roboczej zapisuję w pamięci podręcznej masę zasobów (w tym danych, które zasilają aplikację).
Dzięki temu moja aplikacja będzie zapewniać użytkownikowi co najmniej działanie zastępcze, jeśli korzysta on z trybu offline.
Na przód!
Komponenty sieciowe stanowią duże uzupełnienie platformy internetowej, a to wciąż jest w fazie rozwoju. W miarę jak użytkownicy będą trafiać do coraz większej liczby przeglądarek, to od nas, społeczności programistów, zależy, jakie sprawdzone metody utworzą strukturę naszych aplikacji. Powyższe rozwiązania stanowią punkt wyjścia, ale wciąż można się jeszcze nauczyć. Dalej do tworzenia lepszych aplikacji!