W zeszłym roku zespół Polymer spędził sporo czasu na uczeniu programistów, jak tworzyć własne elementy. Doprowadziło to do szybkiego rozwoju ekosystemu, którym bazują w dużej mierze elementy Core i Papier oraz elementy cegieł utworzone przez zespół Mozilla.
Gdy programiści zapoznają się z procesem tworzenia własnych elementów i zaczynają myśleć o tworzeniu aplikacji, pojawia się szereg pytań:
- Jak utworzyć interfejs użytkownika aplikacji?
- Jak przechodzić przez różne stany?
- Jak poprawić skuteczność?
- Jak zapewnić wrażenia offline?
Z okazji wydarzenia Chrome Dev Summit staram się odpowiedzieć na te pytania, tworząc niewielką aplikację do obsługi kontaktów i analizując proces jej tworzenia. Oto co udało mi się znaleźć:
Struktura
Głównym najemcą komponentów Web jest podzielenie aplikacji na modułowe elementy, które można łączyć i ponownie wykorzystywać. Rdzeń* Polymer i papier* sprawiają, że można łatwo rozpocząć pracę od małych elementów, takich jak core-toolbar (pasek narzędzi) i paper-icon-button...
...dzięki mocy kompozycji połącz je z dowolną liczbą elementów, aby stworzyć rusztowanie dla aplikacji.
Po skonfigurowaniu ogólnego rusztowania możesz zastosować własne style CSS, aby stworzyć wrażenia charakterystyczne dla Twojej marki. Dzięki komponentom można tworzyć całkowicie różne środowiska przy jednoczesnym wykorzystaniu tych samych podstawowych zasad budowania aplikacji. Mając gotowe rusztowanie, możesz zacząć myśleć o treściach.
Jednym z elementów, który szczególnie nadaje się do obsługi dużej ilości treści, jest core-list.
Element core-list może zostać połączony ze źródłem danych (czyli tablicą obiektów) i dla każdego elementu w tablicy oznacza wystąpienie szablonu. W szablonie możesz wykorzystać możliwości systemu wiązania danych firmy Polymer, aby szybko powiązać treść ze swoim materiałem.
przejścia.
Po zaprojektowaniu i zaimplementowaniu różnych sekcji aplikacji kolejnym zadaniem jest określenie, jak się między nimi poruszać.
Chociaż nadal jest to element eksperymentalny, core-animated-pages udostępnia wbudowany system animacji, który może służyć do przechodzenia między różnymi stanami aplikacji.
Animacja to jednak tylko połowa łamigłówki. Aby prawidłowo zarządzać adresami URL, aplikacja musi połączyć te animacje z routerem.
W świecie komponentów internetowych routing może występować na 2 sposoby: imperatywny i deklaratywny. Połączenie metody core-animated-pages z dowolnym podejściem może być odpowiednie w zależności od potrzeb projektu.
Router imperatywny (np. Flatiron's Director) może nasłuchiwać pasującej trasy, a następnie nakazać core-animated-pages zaktualizowanie wybranego elementu.
Jest to przydatne, jeśli musisz wykonać pewne czynności po dopasowaniu trasy, ale przed przeniesieniem następnej sekcji.
Z drugiej strony router deklaratywny (taki jak app-router) może połączyć routing i core-animated-pages w jeden element, co upraszcza zarządzanie nimi.
Aby uzyskać bardziej precyzyjną kontrolę, możesz skorzystać z biblioteki takiej jak more-routing, którą można połączyć z core-animated-pages za pomocą wiązania danych. Być może zapewnia to połączenie obu formatów.
Występy
W miarę pojawiania się aplikacji musisz zwracać szczególną uwagę na wąskie gardła wydajności, zwłaszcza te związane z siecią, ponieważ często jest to najwolniejsza część mobilnej aplikacji internetowej.
Łatwa poprawa wydajności wynika z warunkowego wczytywania elementów polyfill komponentów Web.
Jeśli platforma ma już pełną obsługę, nie ma powodu ponosić takich kosztów. W każdej wersji nowego repozytorium webcomponents.js elementy polyfill również zostały podzielone na samodzielne pliki. Jest to przydatne, gdy chcesz warunkowo wczytać podzbiór elementó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>
Wykonywanie wszystkich importów HTML za pomocą takiego narzędzia jak Vulcanize może się również znacząco zwiększyć skuteczność sieci.
Narzędzie Vulkanize połączy zaimportowane dane w jeden pakiet, znacznie zmniejszając liczbę żądań HTTP, które Twoja aplikacja wysyła.
Offline
Samo stworzenie wydajnej aplikacji nie rozwiąże problemu użytkownika, który ma ograniczone połączenie internetowe lub jego brak. Inaczej mówiąc, jeśli aplikacja nie działa w trybie offline, nie jest to w rzeczywistości aplikacja mobilna. Obecnie możesz korzystać z bardzo złożonej pamięci podręcznej aplikacji do przechowywania zasobów offline, ale w przyszłości dzięki skryptowi service worker, praca w trybie offline powinna być znacznie przyjemniejsza.
Jake Archibald opublikował niedawno wspaniałą książkę kucharską z wzorcami pracowników service worker, ale od razu pokażę, jak możesz zacząć z niej korzystać:
Instalacja mechanizmu service worker staje się łatwa. Utwórz plik worker.js i zarejestruj go po uruchomieniu aplikacji.
Ważne jest, aby zlokalizować worker.js w katalogu głównym aplikacji, ponieważ umożliwi to przechwytywanie żądań z dowolnej ścieżki w aplikacji.
W module obsługi instalacji instancji roboczej buforuję zasoby (w tym dane wykorzystywane przez aplikację) w pamięci podręcznej.
Dzięki temu moja aplikacja będzie miała przynajmniej alternatywne działanie, gdy korzysta z niej offline.
Na przód!
Komponenty internetowe stanowią duże uzupełnienie platformy internetowej, a wciąż są na wczesnym etapie rozwoju. Wraz z pojawianiem się coraz większej liczby przeglądarek to właśnie od nas, społeczności programistów, zależy, czy będziemy mogli opracować sprawdzone metody tworzenia struktury aplikacji. Powyższe rozwiązania stanowią punkt wyjścia, ale musimy się jeszcze wiele nauczyć. Teraz czas na tworzenie lepszych aplikacji.