gitWeb – branching cz.2

W dzisiejszym wpisie chciałbym omówić kolejne funkcjonalności modułu odpowiedzialnego za branching. W poprzednim wpisie opisałem następujące kwestie:

  • Lista branchy
  • Tworzenie nowego brancha

Dzisiaj skupię się na:

  • Checkout – przełączanie się pomiędzy branchami
  • Pobranie drzewa comitów dla aktualnego brancha
  • Opisanie na drzewie commitów, dostępnych branchy

Checkout

Git

Podstawowa funkcjonalność gita, bez której nie da się działać pracując w środowisku z wieloma branchami. Pozwala na przełączenie się pomiędzy dwoma branchami. W konsoli operacja dostępna pod komendą:

Najważniejsze kwestie jakie należy wziąć pod uwagę korzystając z tej komendy to:

  • Wszystkie zmiany, które posiadamy na aktualnym branchu przeniosą się na nowy branch. Oczywiście, jeżeli wystąpi konflikt to zostaniemy o tym poinformowani.
  • Przełączenie się na nowy branch powoduje, że HEAD repozytorium ustawi się na Tip danego brancha. Innymi słowy, zostanie pobrany stan repozytorium z najnowszego commita na nowym branchu.

Tip w branchu, jest to najnowszy commit zrobiony na danym branchu.

VueJs

Po stronie widoku za wiele się nie dzieje. Wywołane kolejne akcje, które na końcu wywołują API. Jedyną rzeczą, na którą chciałem zwrócić uwagę jest główny plik actions.js w sekcji store.

Generalnie chciałem zmodularyzować Vuex w obrębie głównych komponentów Vue. A więc, miałem moduł Vuex branchArea.js, który odpowiadał komponentowi branch.vue, itd.

Aby była możliwa komunikacja między tymi modułami, wydzieliłem nadrzędne miejsce, w którym akcje będą je spajać.

W tym konkretnym przypadku akcja checkout znajduje się w pliku nadrzędnym actions.js, a sama akcja prezentuje się następująco:

Wywołana sekwencja kolejnych akcji. W pierwszej kolejności wywoływany jest CHECKOUT_BRANCH na wskazanym przez użytkownika branchu. W momencie gdy operacja zakończy się sukcesem wywoływana jest akcja GET_COMMIT_TREE_FROM_HEAD, która pobiera listę commitów, zaczynając od HEAD „nowego” brancha. Na samym końcu wywoływane jest builder odpowiedzialny za kompozycję grafu.

Api

Aby przełączyć branch należy odwołać się do:

Sam kontroler wygląda tak samo jak w poprzednich wpisach, a więc przejdę od razu do właściwej implementacji przy pomocy libgit2sharp:

I pojawia się… Magiczne Commands. Z jakiegoś powodu autorzy biblioteki postanowili, że wydzielą część funkcjonalności do statycznych metod. Oczywiście, to jest OS projekt i rozumiem dlaczego wszystko co miało by trafić do commands, jeszcze tam nie trafiło. Ja mam z tym jeden problem, mianowicie dość ciężko do statycznych metod pisze się testy, trzeba je oklejać jakimiś wrapperami, żeby móc mockować takie wywołania.

Poza tym kawałek kodu dość standardowy, parę sprawdzeń warunków brzegowych, zwrócenie NullObject w momencie gdy branch nie istnieje i translacja do obiektu DTO.

Pobranie drzewa commitów dla aktualnego brancha

Tu sprawa wygląda bardzo prosto. Komenda:

pobiera zawszę listę commitów zaczynając od HEAD aktualnego brancha, na którym się znajdujemy.

Pobieranie listy commitów oraz budowanie z nich branchy opisałem we wpisie dotyczącym komendy git log –graph, serdecznie do niego zapraszam.

Opisanie na drzewie commitów branchy

Na powyższym gifie w prawej stronie widać skromnie wyglądające labele BRANCH. Reprezentują one „status” aktualnego brancha. A więc pokazują się tam wszystkie branche przypisane do commita „widocznego” z poziomu obecnego brancha.

Zadanie do zrealizowania może brzmieć następująco:

Pokaż wszystkie branche których najnowszy commit znajduje się na grafie aktualnego brancha.

Powyższa metoda robi dwie rzeczy. W pierwszej kolejności pobrana jest lista commitów dla aktualnego brancha. Następnie pobrany jest Tip każdego dostępnego brancha. Mając te dwie informacje możemy w prosty sposób zmapować te dwie kolekcje.

Podsumowanie

Komponent zbudowany… ale nie kompletny. Brakuje w nim jeszcze wielu, wielu rzeczy. Między innymi zmiana nazwy, usuwanie, „śledzenie” branchy zdalnych. Operacja Checkout wiąże się również z konfliktami i mergowaniem. Jak widać sporo pracy jeszcze przede mną.

W tych dwóch wpisach opisałem budowę jednego z wielu komponentów, które będą budować moją aplikację. Oprócz samego opisywania kodu, chciałem również wrzucić troszkę teorii dotyczącej samego gita. Chciałbym w dalszym ciągu pisać w takiej konwencji. Dzięki temu mam zamiar wprowadzić trochę urozmaicenia i ciekawej wiedzy we wpisy.

W tym momencie kończę kolejny spory moduł. Jeszcze przed świętami chciałbym opisać część dotyczącą tworzenia commitów i podglądu zmian w plikach.

gitWeb – branching cz.1

W dzisiejszym wpisie opiszę jak zrealizowałem branchowanie w mojej aplikacji.

Na powyższym  gifie widzimy wszystkie funkcjonalności, które udało mi się do tej pory zrealizować. A są to:

  • Lista branchy
  • Stworzenie nowego brancha
  • Przełączenie się na inny branch
  • Pobranie drzewa comitów dla aktualnego brancha
  • Opisanie na drzewie commitów branchy

W tym wpisie opiszę kompletną ścieżkę implementacji od frontendu do wywołania biblioteki libgit2sharp. Podzielę to na 3 sekcje:

  • komenda jaką należy wykonać w konsoli gita
  • moduł VueJs
  • API wraz z implementacją libgit2sharp.

Jako, że każdy z elementów jest obszerny dzisiaj skupie się jedynie na opisie listy branchy i sposobie w jaki udało mi się zaimplementować dodanie nowego brancha.

Lista branchy

Za pomocą tej komendy w konsoli pokażą się wszystkie branche w repozytorium. Zarówno te lokalne jak i „śledzące” zdalne. Dodatkowo dostajemy informację na którym branchu obecnie się znajdujemy.

Komponent VueJs

Lista zaimplementowana została w komponencie o nazwie branch.vue. Nie chcę wklejać tu całego komponentu bo nie będzie to miało sensu. Wkleję jedynie najważniejsze kawałki odpowiedzialne za pobranie listy branych i ich wyświetlenie.

Pobranie danych odbywa się w następujący sposób:

Funkcja beforeMount wywoływana jest przed umieszczeniem komponentu na widoku. Jest to mój punkt wejściowy do aplikacji. Zostanie on nim dopóki nie wymyślę lepszego punktu wejściowego. Funkja jest bardzo prosta wywołuje ona akcję Vuex o nazwie GET_ALL_BRANCHES.

Jak widać akcja jest również prosta. Wywołany zostaje serwis, który odpytuje  WebApi. W przypadku poprawnego pobrania danych przekazywane są one do mutacji SET_ALL_BRANCHES. Ustawia ona stan aplikacji zgodnie z tym, jak powinno się to robić korzystając z Vuex. Tylko mutacje powinny zmieniać stan aplikacji.

Sam serwis do komunikacji wygląda następująco:

 

Jak widać wszystko jest dość przejrzyste i proste. Chciałbym aby cała aplikacja tak wyglądała 😉

API

Po stronie backendu funkcjonalności dotyczące branchy wystawione są za pomocą API w kontrolerze BranchController.cs.

Jeżeli chodzi o samo API wybrałem REST ze względu na to, że jest teraz super fancy i modny. A tak na serio to dzięki tej aplikacji chciałbym poznać to podejście. Jego wady, zalety, ograniczenia.

No więc lista branchy dostępna jest pod:

a sam kontroler jest zaimplementowany maksymalnie prosto:

Jak widać nic szczególnego, wstrzyknięty jedynie odpowiedni provider odpowiedzialny za obsługę branchów. Sam provider wygląda tak:

Ot i pierwsze spotkanie z libgit2Sharp. Jeszcze nie opisywałem tej biblioteki. Do providera wstrzykiwany jest obiekt typu IRepository. Jest to interfejs pochodzący właśnie z tej biblioteki. Stanowi on swoiste serce całego frameworka. Reprezentuje on repozytorium gita. Dzięki temu obiektowi mamy dostęp do prawie wszystkich (opiszę w kolejnych wpisach) operacji i zasobów, które możemy wywołać na repozytorium.

W tym konkretnym  przypadku pobranie listy branchy sprowadza się do zwykłej projekcji w Linq na kolekcji Branches. Klasa Branch jest moją klasą. Chciałem ograniczyć ilość zależności w aplikacji do minimum. Dlatego postanowiłem, że nie będę korzystał z dostępnych w bibliotece typów tylko stworze własne obiekty DTO. Dzięki temu podejściu zależność do libgit2Sharp mam wyłącznie w projekcie gitWeb.Core. Kontrolery nic nie wiedzą jaki provider do gita czy innego typu repozytorium jest wykorzystywany. Otwiera to furtkę do implementacji innych systemów kontroli wersji jak np Mercurial czy SVN bez konieczności większych zmian w aplikacji.

Nowy branch

Podstawowa komendą do stworzenia nowego brancha jest:

Oczywiście jest całe mnóstwo opcji, które można wykorzystać do jego stworzenia, ale w obecnej fazie wykorzystuję tą podstawową.

Dodatkowo, tworzone branche nie odwołują się do żadnego zdalnego brancha. Tą funkcjonalność dorobię w ramach Push i Pull.

Komponent VueJs

Do komponentu branch.vue musiałem dodać mini formularz który umożliwi mi wpisanie nazwy nowego brancha.

 

Po stronie komponentu do obsługi tworzenia nowego brancha mamy 2 funkcję:

clearCreationForm – prosta funkcja do czyszczenia stanu.

createBranch – tak jak w przypadku listy branchy, komponenty delegują całą logikę dotyczącą komunikacją z API do Vuex. A więc w tym przypadku wywołujemy akację CREATE_NEW_BRANCH. Przyjmuje ona jako parametr nazwę nowego brancha. Jeżeli operacja tworzenia przebiegnie pomyślnie, czyszczona jest forma z danymi.

Sama akcja w Vuex jest już bardziej skomplikowana:

Więc co tu się dzieje? Tak jak wspomniałem wcześniej, na początku wywoływana jest akcja CREATE_NEW_BRANCH. Akcja ta wywołuje serwis który z kolei wywołuje metodę API do stworzenia brancha. Jeżeli wszystko pójdzie zgodnie z planem to wywoływana jest akcja CHECKOUT_BRANCH.

W tej fazie projektu nowy branch jest automatycznie checkoutowany. I tak samo, jeżeli wszystko będzie w porządku to wywoływana jest (opisana wcześniej) akcja GET_ALL_BRANCHES.

W tym wpisie nie będę opisywał procesu checkoutowania., poświecę na niego osobny wpis.

Serwis odpowiedzialny za odwołanie się do API został zaimplementowany następująco:

API

Stworzyć nowy branch możemy odwołując się do poniższego zasobu:

Szybkie spojrzenie na kontroler oraz branchProvider:

W podstawowej formie żeby stworzyć branch należy jedynie wywołać metodę CreateBranch na obiekcie repozytorium oraz przekazać nazwę jako parametr.

Podsumowanie

Dzisiejszym wpisem rozpocząłem serię dotyczącą implementacji poszczególnych elementów projektu. Już powoli zaczyna coś działać! Strasznie mnie to nakręca do dalszego działania.

Widać wyraźnie, że biblioteka libgit2sharp jest naprawdę prosta w użyciu. Samo opisujące się metody i prosty interfejs sprawia, że bardzo dobrze się z niego korzysta. Dodatkowo community (github, stackOverflow) jest dość potężne, więc nie ma też problemu z rozwiązywaniem ewentualnych problemów czy błędów w samej bibliotece.

W kolejnym wpisie opisze kolejne części branchingu – a więc checkout brancha, zmianę nazwy oraz usunięcie.

Vuex – getters – enkapsulacja logiki

W dzisiejszym krótkim wpisie opiszę jak wykorzystałem getters w Vuex do implementacji pobrania statusu repozytorium.

Stara wersja

Powyższy kod wykonuje trzy czynności, w pierwszej kolejności wysyła POST na serwer, informując, że dany plik musi przejść na stage. Kolejne dwie to wywołanie akcji, które pobierają status repozytorium w stage unstage.

Widać bardzo duże podobieństwo i niepotrzebne powielenie kodu. Po stronie serwera, pobranie odbywa się poprzez odpytanie tej samej metody RetriveStatus, różnicą jest jedynie typ statusu.

Warto by zmienić lekko podejście, zlikwidować duplikację.

Nowsza wersja

No ok, dwa odpytania serwera po „te same” dane. Zmieńmy to:

Jak widać spore zmiany, pozbyliśmy się dwóch wywołań. Zastąpione one zostały jednym wywołaniem funkcji fetch_repository_status, pobiera ona nie filtrowane dane. Przypisuje je następnie do jednego stanu, repositoryStatus.

Ok, to teraz wyświetlmy to na widoku:

Działa? Działa pięknie. Jest tylko jeden problem z tym rozwiązaniem. Jeżeli będę chciał wykorzystać taka listę w innym miejscu , będę musiał powielić kod. Zobaczmy jak będzie wyglądała implementacja z wykorzystaniem getters.

Najnowsza wersja

Getters w Vuex, są koncepcyjnie tożsame z computted we Vue. Generalnie chodzi o to, że jest to miejsce w którym możemy poddać filtracji nasze dane. Co warto zauważyć, filtracji, a więc procesowi który nie zmienia nam stanu aplikacji.

a teraz wykorzystanie w komponencie Vue:

Korzyści są oczywiste, wydzielenie logiki do osobnego miejsca. Dzięki temu użycie plików ze stage lub ustage sprowadza się do wywołania powyższej linijki. Dodatkowo jakiekolwiek modyfikacje w przyszłości będą znacznie łatwiejsze. Jedno miejsce gdzie jest logika = jedno miejsce do zmiany.

Podsumowanie

Tym rozbudowanym wpisem opisałem dość prosty mechanizm gettersVuex. Jednakże chciałem również nakreślić problem wydzielania logiki i powielania kodu. Powyższy przykład można zastosować do każdego innego frameworka czy języka. Odpowiednie oddzielenie zależności znacznie ułatwi nam pracę oraz utrzymanie kodu, pamiętajmy o tym!

Vuex – wstęp

Postępy

Szybkie spojrzenie na to co wykreowało się w aplikacji. Na chwilę obecną są 4 komponenty:

unstagedFiles – komponent odpowiedzialny za wyświetlanie wszystkich plików, które nie mają wejść do kolejnego commita,

stagedFiles – analogicznie- komponent, który wyświetla pliki, które chcemy włączyć do commita,

commitDetails –  komponent odpowiedzialny za „budowanie” commita, na razie jest tylko nazwa oraz przycisk,

fileChangePreview  –  duży komponent odpowiedzialny za podgląd aktualnych zmian w plikach, zarówno tych w stage jak i unstage. W komponencie tym będziemy mieli możliwość podejrzenia zmian jak i wyłączenia z danego commita.

Każdą z tych operacji opiszę jeszcze dokładnie w kolejnym wpisie. W tym chciałbym się skupić na krótkiej relacji z mojej przygody z Vuex.

Vuex

W każdej aplikacji, w której nacisk położony jest na wysoką modularyzację (a takie są aplikacje pisane w VueJs), przychodzi potrzeba komunikacji pomiędzy komponentami. Zarówno komponentami w konfiguracji rodzic-dziecko, jak i w równoległej konfiguracji dziecko-dziecko. VueJs dostarcza nam wbudowany mechanizm komunikacji, lecz wraz ze wzrostem ilości elementów aplikacji, złożoność oraz narzut na jej implementację znacznie rośnie. Dodatkowo chcielibyśmy zapewnić „czystość” komponentom. Chcielibyśmy uniknąć tworzenia sztucznych komponentów służących wyłącznie jako pośrednicy w komunikacji.

Teoretycznie mogłem stworzyć komponent root dla powyższych komponentów i zaimplementować prostą „szynę”, ale patrząc trochę do przodu, zdaje sobie sprawę, że takich szyn i komponentów pomocniczych może być znacznie więcej. No więc co?

Rozwiązać ten problem chce Vuex. Czym jest Vuex ? Dla mnie Vuex to mechanizm zarządzania stanem aplikacji, przypomina mi trochę taki globalny singleton. Oczywiście z możliwością pełnej modularyzacji i ograniczeniem kontekstów działania.

Instalacja

Na samym początku instalujemy wszystko za pomocą npm.

Struktura plików Vuex w aplikacji jest prosta, wszystkie pliki znajdują się w folderze store.

Poniżej przestawiłem cały kod jaki jest wymagany aby uruchomić Vuex w swojej aplikacji VueJs.

W pliku main.js importujemy sobie instancję Vuex znajdującą się w pliku index.js i przekazujemy do konstruktora Vue.

Sam plik index.js również wygląda bardzo prosto. Pokrótce, na samym początku importujemy sobie wymagane referencje oraz akcję i mutację (o nich później). Jak widać zostały one wydzielone do osobnych plików ale nic nie stoi na przeszkodzie, żeby na początku umieć je w taki sposób jak state.

Należy zwrócić uwagę na tą linię:

Ważne jest aby ona była umieszczona przed inicjalizacją Vuex.

Implementacja

Poniżej opiszę poszczególne elementy, które wchodzą w skład instancji Vuex. Za przykład wezmę instancję z mojej aplikacji.

state– Nic innego jak stan naszej aplikacji.

W powyższym przykładzie, chcemy aby w skład stanu naszej aplikacji wchodziły dwie kolekcje plików.

Przekazując store do instancji Vue automatycznie mamy do niej dostęp, jako globalny obiekt, pod zmienną $store.  Jeżeli w którymś z komponentów chcielibyśmy się odwołać do tych zmiennych, należy to zrobić tak:

Naprawdę proste. Ale czym w takim razie rożni się od zwykłego globalnego obiektu zawierającego zmienne? W Vuex mamy ściśle określone zasady jakimi powinniśmy się kierować, aby zmieniać stan.

mutations- aby poprawnie zmienić stan naszej aplikacji musimy zaimplementować tzw. mutacje. Są to funkcje, które operują na stanie. Tylko w tych funkcjach implementujemy logikę, która ten stan zmienia. I teraz jeżeli mamy potrzebę zmienić stan, wywołujemy daną mutację:

Poniżej implementacja mutacji APPLY_UNSTAGED_FILES

Strict Mode – No dobra ,ale zaraz ktoś spyta

a co mi szkodzi  żeby wywołać ten kod

W tym przypadku czyścimy listę plików poza funkcją mutacji. Oczywiście to przejdzie, ale łamiemy tym samym całą ideę Vuex, równie dobrze moglibyśmy go wywalić.

Oczywiście taka implementacja może być mniej lub bardziej świadoma. Dlatego przychodzi nam z pomocą strict. Jeżeli ustawimy tę flagę na true, to Vuex podczas każdej zmianie stanu z „zewnątrz”, wyrzuci nam wyjątkiem.

Bardzo pomocne, szczególnie w przypadku gdy uczymy się Vuex lub do zespołu dołącza mniej doświadczony programista.

Akcje – główna zasada w Vuex mówi, mutacje wykonujemy synchronicznie. Oczywiście świat, jak i pewnie większość framworków w JS są asynchroniczne, ale nie chcemy z nich rezygnować. W odróżnieniu od mutacji, akcje mogą wywoływać operacje asynchroniczne.

Oczywiście, jeżeli po wykonanej akcji chcemy wywołać mutację to nic nie stoi na przeszkodzie. Wywołujemy poprostu metodę commit z odpowiednimi parametrami.

W powyższym przykładzie, zadeklarowałem akcję, która asynchronicznie odpytuje API o wszystkie pliki, a następnie wywołuje mutację i aktualizuje pliki.

Samo wywołanie akcji w komponencie również jest trywialne, wystarczy wywołać funkcję dispatch oraz przekazać nazwę akcji, którą chcemy wywołać.

W powyższym pliku możemy zwrócić uwagę na jeszcze jedną rzecz. Mianowice import pliku types.

W pliku  types.js znajdują się wszystkie nazwy akcji i mutacji jakie mamy zadeklarowane. Dzięki temu zabiegowi z kodu znikają nam wszystkie „magic strings”. Prosty rozwiązanie, ale niezwykle pomocne.

Podsumowanie

Generalnie sam mechanizm mi się podoba, jak się go opanuje to naprawdę ułatwia komunikację pomiędzy komponentami. Bardzo przydał mi się StrictMode, dzięki niemu wyłapałem nie jeden kardynalny błąd.

Oczywiście, przedstawione rozwiązanie z podziałem implementacji Vuex na osobne pliki nie uchroni nas przed zbytnim ich rozrośnięciem. Potrzebne są nam jakieś moduły. Oczywiście Vuex dostarcza nam taką możliwość. W kolejnym wpisie z tej serii opiszę ten mechanizm.

VueJS daj się poznać

Długo się zastanawiałem jaki framework dla frontendu wybrać. Na rynku mamy wielu kandydatów m.in: Angulara 1.x, Angulara 2.x, Aurelię, VueJs i klasyk- React. Oczywiście to nie wszystkie i pewnie nie wspomniałem o jakichś ważnych, ale tylko tymi miałem jakąkolwiek styczność, czy to przez petprojects czy też na prezentacjach. Jeżeli chodzi o Angulara 1.x, pisałem w nim drobne aplikacje i całkiem nieźle mi się z nim pracowało. Przyjemna separacja zależności, wsparcie dla DI, serwisy, fabryki itp. To co lubię. Wiele złych rzeczy można na jego temat wyczytać, ale ja ich nie odczułem, może dlatego, że nie robiłem w nim żadnego większego projektu.

No ale mamy przecież Daj Się Poznać i fajnie byłoby nauczyć się czegoś nowego. Angular 2.x i Aurelię widziałem na kilku prezentacjach i wydają mi się zbyt „ciężkie”. Szukałem czegoś bardziej finezyjnego, lżejszego. Został React oraz VueJs. Reacta kojarzę tylko za sprawą Facebooka, a VueJs dlatego, że od jakiegoś czasu stał się dosyć modny. Długo nie mogłem się zdecydować. Po spotkaniu na gliwickiej grupie DevDuck postawiłem na VueJs.
Tym postem z przydługim wstępem chciałbym rozpocząć „mikro” serię wpisów na temat mojej męki w świecie frontendu.
Początki? To zawsze jest trudne. A w froncie? To jest coś niesamowitego… Dla osoby, która dość długi czas siedzi w backendzie, przestawienie się jest co najmniej trudne. Ilość rzeczy, które trzeba ogarnąć jest naprawdę spora.

Tak więc VueJs. Oj, ależ inne podejście od znanego mi AngularaJS. Przede wszystkim, odejście od klasycznego MVC i warstw na rzecz architektury „wertykalnej”, architektury luźno powiązanych komponentów.

Single File Components

W pierwszej kolejności podczas nauki szukałem sposobu na kopozycje projektu, zastanawiałem się jak rozdzielać te małe moduły w systemie plików. Jeżeli komponent ma zawierać swój template HTML, obsługę w JS oraz styl, to musi być coś co to „opakuje”. Tym czymś są pliki .vue. Tworzymy jeden plik per komponent:

Segregacja komponentów

Poniżej przykład prostego komponentu:

Mamy w nim trzy podstawowe elementy:

  • template – w ramach tego tagu piszemy cały kod HTML jaki ma być wyświetlony w miejsce naszego komponentu. Ważna rzecz, taki element może zawierać wyłącznie jeden nadrzędny element, także składnia poniżej będzie powodować błędy podczas budowania paczki w webpacku.

A poniżej poprawna implementacja:

  • script – w nim umieszczamy całą logikę komponentu. Jest ściśle określona struktura takiego skryptu. Opiszę go w kolejnym wpisie.
  • style – w nim możemy „upiększyć nasz komponent”. Zwrócić należy uwagę, że nie jesteśmy wcale zmuszeni pisać w czystym CSS. Jeżeli dołączymy atrybut z nazwą składni (w tym przypadku lang=scss) oraz dołączymy odpowiedni loader w webpacku, możemy porzucić pisanie czystego CSS na rzecz SCSS, LESS czy innych.

Ciekawym dodatkiem do tego fragmentu jest możliwość zamknięcia (ang. scoped) stylu na wyłącznie ten komponent, wystarczy, że umieścimy atrybut scoped w tagu.

Dzięki temu style zawarte w komponencie będą miały wyłącznie zasięg lokalny. Oczywiście nic nie stoi na przeszkodzie aby jednym komponencie dodać style lokalne oraz globalne.

Kolejną kwestią jaką należy mieć na uwadze korzystając z tych plików to fakt, że potrzebujemy czegoś co nam to zepnie je w całość. Ja w tym przypadku korzystam z webpacka. Aby wszystko działało, musimy dodać odpowiednią sekcję do rules :

Do uruchomienia aplikacji jeszcze potrzebna jest jedna rzecz. Punkt startowy:

W powyższym przykładzie tworzona jest instancja VueJs, w której jest wywoływany komponent App. Będzie on w moim przypadku głównym komponentem aplikacji, składającym się z mniejszych części.

Musimy to jeszcze zintegrować z ASP.MVC, na którym wszystko stoi. Tak jak w większości frameworków należy wywołać na głównym widoku komponent root’a, czyli w tym przypadku „app”.

Tym sposobem, jeżeli uruchomimy sobie webpacka, a następnie odpalimy projekt powinno na ekranie pojawić się nam piękne „Hello World”!

Postępy

Bardzo dużo czasu przeznaczyłem na wertowanie dokumentacji oraz tutoriali związanych z VueJs. Także czasu na stworzenie samej aplikacji nie zostało zbyt wiele.  Do momentu pisania tego posta widok mojej aplikacji prezentuje się tak jak na załączonym obrazku:

Jak widzimy, z lewej strony kreuje się już panel do zarządzania zmianami w repozytorium. Jako, że jestem kompletnie lewy w sprawach designu to paletę kolorów biorę z VSCode, w którym to piszę.

Co dalej

Do kolejnego wpisu dalej będę zgłębiał tajniki VueJsa, ponieważ jestem dopiero na szczycie góry lodowej. Na pewno chciałbym dokończyć to co mam oraz dołożyć prosty podgląd zmian dla pliku. Zostało mało czasu do końca tygodnia, także zabieram się do pracy.