Dlaczego warto wykorzystać Vue.js w projekcie open source

Kiedy zaczynaliśmy prace nad Vue Storefront, nie wiedzieliśmy jeszcze z jaką skalą problemu się mierzymy i jak bardzo będzie to wymagające zadanie. Chcieliśmy wziąć nowoczesny styl pisania aplikacji frontendowych i osadzić go w starym, dobrze znanym z platform CMS takich jak WordPress systemie szablonów i rozszerzeń. Takie podejście gwarantowało nam nowoczesny, ale stabilny i w pełni rozszerzalny framework. Nasze poszukiwania podobnych rozwiązań niestety okazały się bezowocne.

Artykuł przygotował dla nas Filip Rakowski. Front-End Developer Divante, współzałożyciel Vue Storefront. Pasjonat elektroniki użytkowej i programowania (głównie JavaScript). Od niedawna zafascynowany technologią Progressive Web Apps i skupiajacy się na popularyzowaniu jej w branży eCommerce. Wielki fan dobrego Developer Experience.

Musieliśmy stawić czoła masie nowych wyzwań, których nikt wcześniej w świecie Vue.js nie podejmował na taką skalę. W tym artykule chciałbym podzielić się motywacjami, które nami kierowały przy wyborze odpowiednich technologii i kilkoma ciekawymi problemami, które udało nam się dzięki podjęciu dobrych decyzji w elegancki sposób rozwiązać.

Mądrze wybieraj narzędzia

Stack technologiczny odgrywa kluczową rolę przy tworzeniu każdej aplikacji. Może zarówno bardzo uprościć, jak i utrudnić jej rozwój i utrzymanie. Przy wyborze technologii bardzo ważna jest jej dobra znajomość, aby już na etapie planowania stacku można było ocenić, który framework lub biblioteka rozwiązuje nasze problemy w najprostszy i najbardziej elegancki sposób, a który wymaga obejść i kombinowania.

Dwa kluczowe wybory, z których bardzo ciężko wycofać się w trakcie trwania, to wybór frontendowego frameworka i build toola. Do webpacka nikt nie musiał nas przekonywać. Jest to najbardziej popularny build tool wykorzystywany prawie w każdym nowoczesnym projekcie frontendowym. Duża popularność danej technologii znacznie zmniejsza barierę wejścia w projekt dla innych developerów, co przy projektach Open Source ma ogromne znaczenie.

Przy wyborze frameworka frontendowego sytuacja była już bardziej skomplikowana. O ile build tool da się jeszcze zmienić (chociaż jest to czasochłonne), o tyle zmiana frameworka jest praktycznie niemożliwa bez przepisania całości aplikacji na nowo. Wiedzieliśmy, że ta decyzja może być podjęta tylko raz.

Angular szybko wypadł z listy

Frameworków frontendowych jest mnóstwo. React, Vue, Angular, Aurelia, Ember, Polymer, Backbone to tylko kilka z tych popularniejszych. W naszym przypadku wybór ograniczał się do tych o najmocniejszej dynamice wzrostu i adopcji na rynku czyli: React, Vue i Angular.

Z racji tego, że projekt miał bazować na community, trzeba było bacznie przyjrzeć się temu, jak każdy z tych frameworków stoi ze społecznością Open Source. W ten sposób z zestawienia szybko wypadł Angular, który jest używany głównie w dużych korporacjach. Angularowa społeczność Open Source nie jest aż tak aktywna, jak ma to miejsce w przypadku Vue i Reacta, z racji tego, że ten framework jest w dużej mierze wykorzystywany przez Java/C# fullstack developerów, których głównym obszarem zainteresowań są właśnie te języki.

React vs Vue

Pozostał nam więc wybór pomiędzy Reactem a Vue. Oba frameworki mają bardzo aktywne community, są dojrzałe i szeroko zaadaptowane. React wygrywa pod względem popularności i dojrzałości ekosystemu, ale młodszy Vue szybko nadrabia zaległości i coraz częściej jest wybierany zamiast swojego starszego kolegi. Pomocnym narzędziem przy predykcji konsekwencji wyboru frameworka były raporty takie jak State of JS oraz statystyki z GitHuba i Google Trends, które pozwoliły nam zdobyć szerszy pogląd na to, jak będzie wyglądać świat frontendu w najbliższych latach.

Jak pewnie domyślacie się po tytule artykułu — wybraliśmy Vue. Kwestia przetrwania i adopcji nie jest już czymś o co muszą martwić się adopterzy tego frameworka, a fakt, że nie posiada on za sobą żadnej wielkiej firmy i jest w pełni community-driven, jest jednym z głównych argumentów, dla których jest to najlepszy wybór dla projektu open source. Bardzo istotna była dla nas szybkość developmentu i niska bariera wejścia w czym Vue deklasuje konkurentów dzięki prostej składni i najlepszej w branży dokumentacji. Jest to jeszcze bardziej istotne w świecie eCommerce, gdzie developerzy bardzo często nie mają dużego doświadczenia z JavaScriptowymi frameworkami. Dla wielu z nich React ma zbyt duży próg wejścia, aby móc swobodnie zaangażować się w projekt, który im się spodobał. W przypadku Vue widzieliśmy w firmie juniorów, którzy w ciągu jednego-dwóch dni byli w stanie płynnie posługiwać się nim w swoich projektach.

Teraz kiedy zrozumiałe są powody, dla których wybraliśmy te a nie inne technologie, pora przyjrzeć się temu, jak poradziły sobie one w boju. Już teraz mogę zdradzić, że poradziły sobie świetnie.

Jak umożliwić aktualizację aplikacji?

Pierwszym z wyzwań, z którym musieliśmy się zmierzyć było umożliwienie bezbolesnej aktualizacji aplikacji przy jednoczesnym zachowaniu prostoty i łatwości korzystania z jego funkcjonalności. Naturalnie musieliśmy wydzielić część softu, która będzie tej aktualizacji podlegać i odseparować ją od reszty aplikacji.

Aby zdecydować co powinno znaleźć się w core, trzeba umieć przewidzieć sposoby użycia go przez innych programistów i zidentyfikować potencjalne ograniczenia. Zdecydowaliśmy się na wydzielenie podstawowych modułów odpowiedzialnych za stan aplikacji (Vuex), kluczowych mechanizmów (m.in obsługa szablonów, wtyczek, Server Side Rendering) oraz logiki JavaScriptowej podstawowych komponentów, takich jak widok produktu, kategorii czy koszyk. Dlaczego tylko logiki JavaScriptowej? O tym za chwilę.

Wyobraźmy sobie następujący scenariusz: Klient (niech będzie to agencja) chce użyć naszego produktu – chce zbudować swój sklep w oparciu o stworzony przez nas system. Zazwyczaj standardowym początkiem dyskusji są pytania o to, co na danej platformie można zrobić i co ważniejsze – czego nie można, czyli jakie są ograniczenia architekturalne.

Przydatne komponenty Vue

Oczywiście każdy twórca aplikacji stara się, aby takich ograniczeń było jak najmniej. Vue dostarcza prostego, ale bardzo potężnego mechanizmu mixinów. W skrócie są to komponenty, które możemy “wstrzyknąć” do innych komponentów i odziedziczyć po nich pola, metody a nawet lifecycle hooksy. Ten mechanizm pozwala w bardzo elegancki sposób udostępniać innym developerom funkcjonalności, które mogą wstrzyknąć w dowolne miejsce, nadpisać lub rozszerzyć.

Skupiliśmy się na zgrupowaniu samej logiki biznesowej pozbawionej stylowania i markupu HTML w core komponentach tak, aby można było je wstrzyknąć w dowolny inny komponent w swoim szablonie i ostylować według stylistyki zgodnej z danym sklepem. Jedyne o co trzeba było zadbać to niezmienne API (czyli pola i metody udostępniane przez core komponenty) i voila – mamy niezależny, niemodyfikowalny i prosty w aktualizacji core aplikacji oparty o Vue.js, który jednocześnie w żaden sposób nie ogranicza developera i nic nie wymusza. To jak użyje danego core komponentu, z jakich jego funkcji skorzysta i czy w ogóle będzie go wstrzykiwał zależy tylko od niego. Dzięki takiemu podejściu każdy szablon jest tak naprawdę samodzielną aplikacją Vue.js, która może korzystać z core’a jak ze zwykłej biblioteki.

Oferty pracy z

Szablony

Wspominałem już kilka razy o szablonach, ale nie wytłumaczyłem jak właściwie u nas działają. W Vue Storefront każdy szablon jest oddzielną aplikacją instalowaną przez NPM. Ma własne zależności i jedynie korzysta z tego, co udostępnia przy okazji core. W teorii nie licząc kilku podstawowych funkcji takich jak cacheowanie statycznych plików w Service Workerze szablon mógłby działać w całkowitej separacji od core.

Ważna dla nas była możliwość posiadania w aplikacji kilku szablonów jednocześnie, a ich zmiana nie wymagała wiele pracy ze strony programisty. Jak się pewnie domyślasz nie znaleźliśmy nigdzie rozwiązania, które spełniałoby nasze oczekiwania – tutaj z pomocą przyszedł Webpack, a dokładniej jedna z jego przydatniejszych funkcji, czyli aliasy. Wyobraźmy sobie taką prostą strukturę projektu:

themes
— theme1
—- themeEntry,js
— theme2
—- themeEntry.js appEntry.js

Chcielibyśmy w prosty sposób móc przełączać się między theme1 i theme2, bez wykonywania wielu zmian na plikach, które te szablony wykorzystują. Oprócz entry pointu każdy z szablonów ma w sobie pliki rozszerzające różne core’owe funkcjonalności, takie jak moduły Vuex czy Service Worker. Uciążliwe byłoby zmienianie wszystkich tych ścieżek przy każdej zmianie szablonu.

W webpacku zdefiniowaliśmy alias ‘theme’ wskazujący na plik {currentTheme}/themeEntry.js Zmienna currentTheme jest przechowywana w pliku JSON i wskazuje na nazwę folderu z danym szablonem. W pliku appEntry.js inicjalizuje aplikacje z entry pointu szablonu, na który wskazuje alias.

Dzięki temu możemy w bardzo prosty sposób zmienić aktualny szablon edytując tylko 1 linijkę w pliku konfiguracyjnym. Taki proces bardzo łatwo zautomatyzować i wykonać z poziomu CLI, co daje dodatkowe korzyści w postaci lepszego developer experience (u nas ta kwestia była kluczowa).

Prostsze zmiany

Zazwyczaj koncepcje i pomysły, które wykorzystamy w naszym projekcie nie będa “kuloodporne”. Z czasem aplikacja będzie się zmieniać a niektóre pomysły albo stracą rację bytu w nowym środowisku, albo po prostu wpadniemy na lepsze, bardziej efektywne i eleganckie rozwiązania. W Vue Storefront jesteśmy świadomi tego, że nasz projekt ciągle ewoluuje i zmienia się (w świecie Open Source jest to jeszcze bardziej dynamiczne) i chcieliśmy zminimalizować czasochłonność i potencjalne problemy wynikające z przyszłych zmian.

Oto dwa proste tricki, które znacząco usprawniły nam pracę i jestem pewny, że pomogą także Tobie:

1. Używaj aliasów – zrób listę wszystkich kluczowych ścieżek w Twoim projekcie i zamapuj je jako webpackowe aliasy. Dzięki temu w przyszłości, kiedy struktura katalogów się zmieni, wszystkie linkowania pomiędzy plikami pozostaną nietknięte i będą wymagały zmiany tylko w jednym miejscu. Ta technika zaoszczędziła nam masę czasu i potencjalnych bugów przy wydzielaniu wszystkich core’owych funkcjonalności do osobnego folderu.
2. Modularyzuj projekt – staraj się przestrzegać zasady pojedynczej odpowiedzialności i grupuj funkcjonalności w folderach. Dzięki temu pozbywając się albo zmieniając jakąś funkcjonalność projektu, mamy pewność, że zedytowaliśmy lub usunęliśmy wszystkie potrzebne pliki.

Te dwie proste zasady oszczędziły nam masę czasu, który zapewne poświęcilibyśmy na debugowanie aplikacji i drapanie się po głowie, zastanawiając się dlaczego coś nie działa. Bardzo dobrym dodatkiem do tych dwóch punktów jest pokrycie wszystkich kluczowych elementów aplikacji testami jednostkowymi. Wtedy oprócz łatwiejszego wprowadzania zmian mamy też pewność, że zostały przeprowadzone należycie.

Podsumowanie

Nowoczesny frontend oferuje masę narzędzi służących do rozwiązania tych samych problemów, które różnią się jedynie w detalach. Przy wyborze stacku technologicznego powinniśmy przede wszystkim zwrócić uwagę na to, jaki problem chcemy rozwiązać i która z technologii nam to najbardziej ułatwi, a nie kierować się osobistymi preferencjami. To co dla nas wydaje się wygodne, dla kogoś innego może być zbyt skomplikowane.

Warto dogłębnie poznać każdą z wykorzystywanych przez siebie technologii, aby podjąć właściwe decyzje i móc ułatwić życie sobie i innym. W naszym wypadku połączenie Vue i Webpacka dało fenomenalne rezultaty i bardzo gorąco zachęcam wszystkich do wypróbowania tego zestawu. Samo Vue jest zdecydowanie najciekawszym frameworkiem do obserwowania w tym roku z racji niesamowicie dynamicznego wzrostu.