W ciągu ubiegłego roku zespół Polymer poświęcił dużo czasu na nauczenie programistów tworzenia własnych elementów. Doprowadziło to do szybkiego rozwoju ekosystemu, który w dużej mierze opiera się na elementach Core i Paper w Polymerze oraz elementach Brick stworzonych przez zespół Mozilli.
Gdy deweloperzy poznają już lepiej tworzenie własnych elementów i zaczynają myśleć o tworzeniu aplikacji, pojawia się kilka pytań:
- Jak uporządkować interfejs aplikacji?
- Jak przechodzić między stanami?
- Jakie są strategie zwiększania skuteczności?
- Jakie funkcje offline należy udostępnić?
Na dorocznym spotkaniu programistów Chrome Dev Summit próbowałem odpowiedzieć na te pytania, tworząc małą aplikację do obsługi kontaktów i analizując proces jej tworzenia. Oto, co udało mi się znaleźć:
Struktura
Dzielenie aplikacji na moduły, które można łączyć i wykorzystywać wielokrotnie, to podstawowa zasada komponentów sieciowych. Dzięki elementom core-* i paper-* w Polymerze możesz łatwo zacząć od małych elementów, takich jak paper-toolbar i paper-icon-button.
Dzięki możliwościom kompozycji możesz łączyć je z dowolną liczbą elementów, aby tworzyć szkielety aplikacji.
Gdy już przygotujesz uniwersalny szablon, możesz zastosować własne style CSS, aby stworzyć unikalną stronę dla swojej marki. Zaletą korzystania z komponentów jest to, że umożliwiają one tworzenie bardzo różnych doświadczeń przy użyciu tych samych podstawowych elementów aplikacji. Gdy już przygotujesz szkielet, możesz zacząć myśleć o treści.
Jednym z elementów, który szczególnie dobrze radzi sobie z dużą ilością treści, jest core-list.
Funkcja core-list może być połączona ze źródłem danych (czyli tablicą obiektów), a następnie dla każdego elementu w tabeli tworzy instancję szablonu. W szablonie możesz wykorzystać potężny system wiązania danych w Polymer, aby szybko połączyć treści.
Przejścia
Po zaprojektowaniu i wdrożeniu różnych sekcji aplikacji musisz jeszcze zadbać o to, aby użytkownicy mogli się między nimi przełączać.
Chociaż core-animated-pages to nadal element eksperymentalny, zapewnia system animacji, który można podłączać i wykorzystywać do przechodzenia między różnymi stanami w aplikacji.
Animacja to jednak tylko połowa sukcesu. Aplikacja musi połączyć te animacje z routerem, aby prawidłowo zarządzać ich adresami URL.
W świecie komponentów internetowych kierowanie może być imperatywne lub deklaratywne. W zależności od potrzeb projektu możesz połączyć core-animated-pages z dowolnym z tych podejść.
Router imperatywu (np. Flatiron Director) może nasłuchiwać dopasowanej trasy, a potem zlecić core-animated-pages zaktualizowanie wybranego elementu.
Może to być przydatne, jeśli po dopasowaniu trasy musisz wykonać jakąś pracę, zanim rozpocznie się następna sekcja.
Z kolei router deklaratywny (np. app-router) może łączyć routing i core-animated-pages w jednym elemencie, dzięki czemu zarządzanie tymi elementami staje się bardziej efektywne.
Jeśli chcesz mieć większą kontrolę, możesz skorzystać z biblioteki takiej jak more-routing, którą można połączyć z core-animated-pages za pomocą powiązania danych.
Wyniki
W miarę jak aplikacja nabiera kształtu, musisz zwracać uwagę na wąskie gardła w zakresie wydajności, zwłaszcza na elementy związane z siecią, ponieważ często jest to najwolniejsza część aplikacji internetowej na urządzenia mobilne.
Łatwym sposobem na poprawę wydajności jest warunkowe wczytywanie polyfilli komponentów internetowych.
Nie ma powodu, aby ponosić takie koszty, jeśli platforma jest już w pełni obsługiwana. W każdej wersji nowego repozytorium webcomponents.js polyfille zostały również podzielone na osobne pliki. Jest to przydatne, jeśli chcesz warunkowo wczytywać podzbiór polyfilli.
<script>
if ('import' in document.createElement('link')) {
// HTML Imports are supported
} else {
document.write(
'<script src="bower_components/webcomponentsjs/HTMLImports.min.js"><\/script>'
);
}
</script>
Możesz też uzyskać znaczne korzyści w sieci, wykonując wszystkie importy HTML za pomocą narzędzia takiego jak Vulcanize.
Vulcanize połączy importowane pliki w jeden pakiet, co znacznie zmniejszy liczbę żądań HTTP wysyłanych przez aplikację.
Offline
Jednak stworzenie wydajnej aplikacji nie rozwiązuje problemu użytkownika, który ma słabe lub żadne połączenie z internetem. Innymi słowy, jeśli aplikacja nie działa offline, nie jest to tak naprawdę aplikacja mobilna. Obecnie możesz używać często krytykowanej pamięci podręcznej aplikacji do przechowywania zasobów offline, ale w przyszłości lepszym rozwiązaniem może być skrypt service worker.
Jake Archibald opublikował niedawno świetny poradnik dotyczący wzorów usług działających w tle. Aby Ci pomóc, podam Ci krótkie wprowadzenie:
Instalacja usługi jest bardzo prosta. Utwórz plik worker.js i zarejestruj go podczas uruchamiania aplikacji.
Pamiętaj, aby umieścić plik worker.js w katalogu głównym aplikacji. Pozwoli to przechwytywać żądania z dowolnej ścieżki w aplikacji.
W obsługniku instalacji workera umieszczam w pamięci podręcznej mnóstwo zasobów (w tym dane, które obsługują aplikację).
Dzięki temu moja aplikacja może zapewnić użytkownikowi co najmniej alternatywną wersję, jeśli korzysta z niej offline.
Do przodu!
Komponenty internetowe to ważna nowość na platformie internetowej, która dopiero się rozwija. Gdy pojawią się w większej liczbie przeglądarek, to my, czyli społeczność deweloperów, będziemy musieli znaleźć najlepsze metody strukturyzowania naszych aplikacji. Opisane powyżej rozwiązania stanowią punkt wyjścia, ale nadal jest wiele do zrobienia. Czas na tworzenie lepszych aplikacji.