Jak się dalej rozwijać?

Odpowiedz Nowy wątek
2020-01-24 01:36

Rejestracja: 1 rok temu

Ostatnio: 4 godziny temu

0

Cześć, od jakiegoś czasu programuję we Vue, pracuję jako junior i niebawem dostanę w pracy pierwszy projekt we Vue (wcześniej robiłem mniejsze rzeczy). Póki co mam na koncie jeden średniej wielkości projekt inżynierski, napisałem go właśnie we Vue, backendem zajął się kolega. Podczas pisania apki inżynierskiej korzystałem również z Vuex, Vuetify oraz libek (m.in. Vuelidate), logowanie było zabezpieczone tokenami i zabezpieczone routy. Ogarniam podstawy Vue na tyle, by sprawnie się w nim poruszać, jednak chciałbym pójść odrobinę dalej w rozwoju i nauce tego frameworka. Jaki powinienem wykonać teraz krok naprzód? Mam parę pytań, może ktoś podzieli się wiedzą i dorzuci coś od siebie:

1) Nie rozumiem jeszcze do końca testów jednostkowych i nie wiem jak się je pisze
2) Jak zadbać o odpowiednią strukturę projektu (w sensie czy bezpośrednio z komponentu wysyłać zapytania do api? raczej nie chodzi mi o separację np. menadżera stanów od widoków czy routów)
3) Coś obiło mi się o uszy o storybook, ktoś mógłby napisać coś na ten temat?
4) Czy warto "rozbijać" komponent Vue na 3 osobne pliki (template, script, styles)?
5) Jakie technologie około-Vue warto jeszcze poznać?
6) Jakie "third-party-packages" warto jeszcze poznać?
7) Jakieś jeszcze uwagi, o których nie wspomniałem

Chciałbym zebrać w jednym poście uwagi i zalecenia dla tych "średnio-zaawansowanych", gdzie ruszyć dalej, jak już się, całkiem solidnie, przebrnęło przez większość podstaw i trochę bardziej zaawansowanych zagadnień Vue. Liczę na pomoc!

Pozostało 580 znaków

2020-01-24 01:49

Rejestracja: 5 lat temu

Ostatnio: 25 minut temu

Lokalizacja: Chorzów

4

Jak chcesz zrobić krok naprzód to zacznij być samodzielny. Poczytaj o ogólnych zasadach programowania, algorytmach, metodologiach tworzenia aplikacji.
Pytania, które zadałeś bardziej pasują do kopacza rowów który chce awansować na pomocnika murarza niż osoby, która chce zacząć samodzielnie projektować i budować domy.

ad 1.https://4programmers.net/Forum/Inzynieria_oprogramowania/219467-testyjednostkowe
https://helion.pl/ksiazki/tes[...]-osherove,tesjed.htm#format/e

ad 2. https://helion.pl/kategorie/webmasterstwo/api

ad 4. to zależy od całej masy czynników.

ad 5. Jak najwięcej.

ad 6. Jak najwięcej.

ad 7. Być samodzielnym, tworzyć własne projekty, realizować pomysły, czytać książki, gazety i fora branżowe.


Projektowanie i programowanie. Hobbystycznie elektronika i audio oszołom.

Pozostało 580 znaków

2020-01-24 07:54

Rejestracja: 6 lat temu

Ostatnio: 8 godzin temu

4

1) Nie rozumiem jeszcze do końca testów jednostkowych i nie wiem jak się je pisze

Zacznij je pisać w prawdziwych projektach utrzymywanych na przestrzeni miesięcy. Tu nie ma co teoretyzować, bo większość programistów nie rozumie testów, nawet jak o tym przeczyta gdzieś (też nie rozumiałem). Tzn. teoria się przydaje, ale i tak źle zrozumiesz na początku i będziesz testować nie to co trzeba, w zły sposób. Ale na tym polega nauka.

No i celowo wspominam o tym, żeby to był projekt co najmniej kilkumiesięczny, bo dopiero wtedy będzie widać, czy testy są dobre, czy przetrwają próbę czasu i liczne zmiany w projekcie. Natomiast złe testy to takie np. które trzeba ciągle zmieniać, albo które nie wykrywają błędów, albo takie, które dają fałszywe alarmy, albo takie, które działają raz tak, a raz inaczej. wtedy to jest patologia, bo testy przestają spełniać swoją rolę (a niestety tak się zdarza w niektórych projektach).

4) Czy warto "rozbijać" komponent Vue na 3 osobne pliki (template, script, styles)?

Spróbuj rozbijać i spróbuj nie rozbijać, i zobacz co się bardziej sprawdza.

5) Jakie technologie około-Vue warto jeszcze poznać?

React. Po to, żeby mieć porównanie.

6) Jakie "third-party-packages" warto jeszcze poznać?

https://github.com/vuejs/awesome-vue

w sensie czy bezpośrednio z komponentu wysyłać zapytania do api?

API będzie się zmieniać, więc jak będziesz trzymał w komponentach (w liczbie mnogiej! Pamiętaj, że zwykle komponentów jest wiele, tak jak endpointów do API też jest wiele), to po zmianie pierdółki API będziesz musiał latać po komponentach i szukać, który komponent korzysta z danego API).

Poza tym - co jeśli API się kompletnie zmieni, albo jak będziesz chciał przetestować komponent na sucho, bez połączenia z API?

A co jeśli będziesz chciał użyć tego samego endpointa API w kilku komponentach?

Czyli generalnie wrzucanie API do komponentu to słaby pomysł, takie niechlujne pisanie. Można od biedy tak pisać, jak się robi coś małego, ale im większy projekt, tym gorsze będą problemy z tym. Na większą skalę lepiej jest gdzieś wydzielić API (przez API rozumiem, że chodzi ci o zewnętrzne API np. odwołania do endpointów na serwerze? Bo w sumie API to to dość ogólna nazwa), np. zrobić wrapper, ewentualnie oddzielną warstwę.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 3x, ostatnio: LukeJL, 2020-01-24 08:01

Pozostało 580 znaków

2020-01-24 11:34

Rejestracja: 2 miesiące temu

Ostatnio: 1 tydzień temu

2

Odnośnie storybooka -
Jest to fajne narzędzie do przygotowywania sobie gotowych komponentów aplikacji takich jak buttony inputy lub wieksze fragmenty np card. Nie pisze w vue ale uzywam reacta i mysle ze to jest analogicznie wykorzystywane. Chodzi o to że masz sobie swój plik komponentu dla np buttona - button.js i obok dodajesz drugi plik button.stories.js, w ktorym importujesz sobie storybooka i konfigurujesz komponent button do wyswietlenia w oddzielnym odesparowanym srodowisku storybooka. Pozniej odpalasz sobie srodowisko sotrybooka i przegladasz wszystkie komponenty jakie stworzyles oraz patrzysz sobie jak sie prezentuja w roznych konfiguracjach (np motywu). Jest to bardzo fajne narzedzie jeśli na starcie projektu wiesz jak twoje komponenty beda wygladac :)

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0