Wpis z mikrobloga

#programowanie #frontend #react #vuejs #vue #reactjs #javascript

od dziś mam przyjemność dłubania w vuejs.
moje pierwsze wrażenia w porównaniu do reacta:
- większość błędów, których szukasz to chińskie/japońskie znaczki w google
- błędy w konsoli nawet nie dają informacji, która to linia kodu. o nazwie funkcji zapomnij.
- #!$%@? dokumentacja, jeden temat rozbity pomiędzy dwa działy, jeden da się wygooglać, drugi trzeba grzebać nie wiadomo jak głęboko gdzie oba są niezbędne do zrozumienia zagadnienia
- tragiczny support typescripta z zerową dokumentacją
- mieszanie templatki, stylów i jsa w jednym pliku (no dobra, można rozdzielać, ale mówię o 1. wrażeniu)


szczerze, czym ludzie się jarają w tym vue? chętnie usłyszę konstruktywne opinie zaawansowanych użytkowników

osoby, które miały styczność zarówno z reactem jak i z vue tymbardziej mile widziane <3
  • 11
  • Odpowiedz
@WydajnaJednostkaIndywidualna: Kwestia przyzwyczajenia, generalnie jest więcej podobieństw niż różnic. Ja np. dużo bardziej wolę single file components niż JSX, jest przejrzyściej (chociaż Vue też wspiera JSX). Nie ma przekombinowanych nazw hooków jak np. componentWillMount o_O zamiast tego: created, mounted, destroyed, itd. Zarządzanie stanem komponentów w Vue też dużo bardziej ludzkie niż przez setState Reacta. Vuex to jest praktycznie to samo co Redux, tylko prostszy, z globalnymi mutacjami zamiast reducerami. Raportowanie błędów
  • Odpowiedz
@Folmi: dzięki, czyli najwidoczniej po prostu mam dysonans poznawczy :D

chyba głównie te problemy z typescriptem i brak dobrych doców do komponentów klasowych mnie tak uprzedziły.

oby trochę popracowali w tym kierunku.
  • Odpowiedz
@Folmi: same propsy i staty własnie nie sa do konca dla mnie jasne bo jest lipa z dokumentacją dla class components.

w jednym miejscu mówią o propsach, w innym mówią, żeby bindować, w innym, żeby robić data. nigdzie nie jest to jasno rozpisane.

w react to jakieś takie intuicyjne było i docsy mowiły kiedy najlepiej czegoś uzywać. brakuje mi takiego best-practices
  • Odpowiedz
@WydajnaJednostkaIndywidualna: No bo to zależy od zastosowania, a dokładnie od przepływu danych... propsy są do komunikacji parent component -> child, data binding (v-model czy eventy) gdy potrzebujesz child -> parent, data tylko do stanu lokalnego komponentu. Dla mnie ogólnie większość docsów jest mało praktyczna i w ogóle nie umiem się uczyć przez czytanie, może tobie taka metoda też się nie sprawdza.
  • Odpowiedz
może tobie taka metoda też się nie sprawdza.


@Folmi: sprawdza się jak docsy są dobrze napisane, np. symfony czy react :D
tutaj jakoś to wszystko pomieszane i do tego zero przykładów z klasowymi komponentami
  • Odpowiedz
propsy są do komunikacji parent component -> child, data binding (v-model czy eventy) gdy potrzebujesz child -> parent, data tylko do stanu lokalnego komponentu.


@Folmi: czyli jak potrzebujesz komunikację w obie strony, żeby robić jak najwięcej SRP to tak naprawdę musisz robić wszystkie 3?
  • Odpowiedz
@WydajnaJednostkaIndywidualna: Niestety tak, ale jak masz dużo takich komponentów które są ze sobą powiązane w jednym widoku to łatwiej może być korzystać z globalnego store'a (Vuexa) zamiast się tak rozdrabniać. Wtedy komponent używa tylko propsów, getterów i ew. danych lokalnych edytowanych przez mutacje, których efekt automatycznie jest odświeżany na pozostałych komponentach.
  • Odpowiedz
to łatwiej może być korzystać z globalnego store'a (Vuexa) zamiast się tak rozdrabniać.


@Folmi: tak też myślałem, ale jednak state w reactie poniekąd pozwala na odejście od reduxa nawet w tych średnio-skomplikowanych projektach.

chyba jednak jutro bedzie przemyslenie tematu i wdrożenie vuexa
  • Odpowiedz