Co Ci się nie podoba w Reakcie?

Nie przeglądałem jeszcze tamtego tematu i nie wiem w jakim kierunku się ten rozwinie ale jest kilka minusów które niesie ze sobą React.

1. "Otwartość" - brzmi kuriozalnie ale już śpieszę z wyjaśnieniami. W React możesz pisać komponenty funkcyjnie, obiektowo. Możesz używac Hooksów, recompose etc. Co z jednej strony jest bardzo fajne bo daje dużą przestrzeń dla projektu ale z drugiej strony może być gwoździem do trumny dla projektu, jeśli nie sporządzi się odpowiedniego stacku dla danego projektu.

2. Pliki *.jsx które na początku mogą bardzo irytować (zwłaszcza po przesiadce z ng, ale później dostrzegasz walory tego rozwiązania)

3. Nieczytelność - W zasadzie tyczy się to również punktu pierwszego, gdzie pisałem o otwartości. W Angularze masz ładnie pogrupowane i oznaczone odpowiednimi dekoratorami serwisy, widoki, handlersy etc. W React defaultowo tego nie ma i chcąc napisać dobry projekt, ważne jest by trzymać się ściśle wytycznych projektowych, tak by połowa kodu nie wyglądała jak spaghetti. :)

Jak widać nawet nie ma co hejtować w react :D, mnie bolą dwie rzeczy:

• obsługa formularzy, obecne dostępne rozwiązania wymagają zdecydowanie za dużo kodu w porównaniu do reszty reacta, gdzie wszystko się robi prosto i przyjemnie, a formularze przez ten one way binding trzeba się sporo naklepać

• hype devlopment na skalę niespotykaną nigdzie indzie, był hype na reduxa, to wszędzie tego reduxa wpychano pomimo tego że większość projektów go nie potrzebuje. Obecnie jest hype na Apollo GraphQL i nagle się okazuje że wcale reduxa tak bardzo do szczęścia nie jest potrzebny. Jeszcze większy jest hype na hooki, gdzie ludzie na siłę próbują zastępować nim klasowe komponenty, które jakby nie było team reacta zamierza uczynić obiektami drugiej kategorii i zrobić z nich dodatek do reacta, a nie podstawę jaką są obecnie. Jak to się stanie to wracam do #teamAngular #teamSvelte.

I co, to tyle? :| wysilcie się no trochę..

Mi się nie podoba brak v-if (jak to jest w Vue) tylko trzeba pisać konstrukcje typu { costam ? <Component/> : null } - a może jest tylko nie wiem? ;)

React jest spoko jednak odleciał tak daleko od standardów przeglądarki, że trudno mu wrócić na ziemię. Swój własny system eventów oraz propertisów powoduje, że przy integracji z WC życie robi sie trudne:

https://custom-elements-everywhere.com/

Poza tym jest fajny. Pozdrawiam, programista Angulara.

Technicznie to programiści Facebooka robią, co mogą. Od kiedy dodali hooki, to się całkiem przyjemnie tego używa, więc do samej biblioteki się nie przyczepię.

Jednak ekosystem, społeczność, ludzie używający tej biblioteki, to są często patologie.

1. ignorancja - do Reacta siadają ludzie bez podstaw JavaScriptu. Albo ludzie, którym się nie chce zajrzeć do dokumentacji Reacta. Tak samo z Reduxem. Ludzie nie wiedzą, jak działają zmienne czy obiekty w JS, a biorą się za Reacta. Czyli React to nowe jQuery, biblioteka dla ludu, w której można pisać nie znając języka (tylko, że potem ludzie się dziwią, że im coś nie działa tak jak trzeba).

2. presja na sławę (czyli każdy chce jakoś się pokazać, napisać swój kurs Reacta albo stworzyć g**no-bibliotekę, każdy chce mieć coś swojego, albo stworzyć własny wydziwiony styl programowania i napisać o nim na Medium, że odkrył np. nowy sposób nazywania katalogów w projektach reactowych. Żeby tylko być na pierwszej stronie Reddita). Czyli social media driven programming. Ludzie piszą biblioteki open source tylko po to, żeby zabłysnąć w social media. Zabłysnąć... przez 2 dni może, do czasu aż ktoś wrzuci linka do kolejnej biblioteki.

3. hype driven development & cargo cult (czyli każdy wpycha na siłę tego Reduxa i inne biblioteki aktualnie na topie. i robi to całkowicie bezsensu, nie rozumiejąc przeznaczenia bibliotek i nie dopasowując tego pod siebie, a tylko wpycha, bo tak gdzieś wyczytał)

4. brak umiaru. Czyli wrzucanie od groma bibliotek i innych śmieci bez myślenia o konsekwencjach, czy to będzie wydajne, czy łatwe w utrzymaniu itp.

Hooki, czyli "magia" jako sztandarowy element biblioteki. Coś jeszcze mi wadziło przez te parę ostatnich lat z Reactem, ale to najbardziej.

@dzek69 - Ale jaka magia? Jeżeli w takim, że nie wiesz jak to działa, to każda metoda to magia, bo przeciętny klepacz kodu nigdy nie zajrzał w kod dziesiątek metod, które używa.

@LukeJL - Ale to raczej zarzuty w kierunku całej społeczności/ekosystemu JS. React to nie jest chwilowa moda, tylko obecnie najpopularniejsza biblioteka w nowych projektach webowych, ponieważ najpopularniejsza biblioteka w ogóle to wciąż jQuery :)

Haskell napisał(a):

React to nie jest chwilowa moda, tylko obecnie najpopularniejsza biblioteka w nowych projektach webowych, ponieważ najpopularniejsza biblioteka w ogóle to wciąż jQuery :)

A Angular? Chyba, że zakładamy sztywno, Angular nie, bo to on przypiętą etykietę framework.

Nie znam się, to się wypowiem.
Jako oldskulowa JS-ica wszelkie JS-owe biblioteki postrzegałam zawsze jako sposób na to, żeby proste rzeczy robić w bardziej pokręcony sposób, angażując do tego wielokrotnie większe ilości kodu i tracąc kontrolę nad tym, co tam się właściwie dzieje.

A jedyną bibliotekę, którą uważałam nie tylko za pożyteczną ale wręcz genialną był Alladyn, który miał chyba ze 2KB i kilkanaście lat temu w świecie przeglądarek o 3 różnych, niekompatybilnych koncepcjach DOM pozwalał okiełznać elementy strony i nawet robić animacje z wykorzystaniem klatek kluczowych.

Freja Draco napisał(a):

A jedyną bibliotekę, którą uważałam nie tylko za pożyteczną ale wręcz genialną był Alladyn, który miał chyba ze 2KB

Szybszy i mniejszy jest framework http://vanilla-js.com/

Dobra @cerrato, napiszę dlaczego reakt jest dziwny :/
Zajrzałem do tego Reacta, mam zamiar pobawić się dłużej, ale po pierwszym zerknięciu w porównaniu z Angularem jest tam taki... burdel. Mylę się?

Kondziowsky napisał(a):

Dobra @cerrato, napiszę dlaczego reakt jest dziwny :/
Zajrzałem do tego Reacta, mam zamiar pobawić się dłużej, ale po pierwszym zerknięciu w porównaniu z Angularem jest tam taki... burdel. Mylę się?

IMHO React jest bardzo poukładany. Oczywiście kod można napisać spaghetti jak w każdej technologii. React podoba mi się, ze względu na stosunkowo niski próg wejścia. Wystarczy obejrzeć jakiś tutorial czy przeczytać początek dokumentacji i już można tworzyć bardzo szybko, bardzo fajne rzeczy.

@Haskell: Ale wcześniej trzeba zaciągnąć kilkanaście bibliotek, żeby tego spaghetti nie było. ;) Wydaje mi się, że obecnie twórcy Reacta robią wszystko, aby użytkownicy nie musieli używać słowa kluczowego class, jakby to było jakieś zło wcielone. IMO te hooki jedynie zmniejszają czytelność. O wiele bardziej wolę lifecycle methods w kompnentach klasowych niż jakieś sztuczne useEffect. Poza tym stan powinny raczej posiadać obiekty, a nie funkcje.

nobody01 napisał(a):

@Haskell: Ale wcześniej trzeba zaciągnąć kilkanaście bibliotek, żeby tego spaghetti nie było. ;)

Nie, nie trzeba zaciągać żadnych bibliotek. Wystarczy stosować dobre praktyki w kodzie tak jak w każdym innym języku, np. dzielić odpowiedzialność, pisać małe metody, nie wciskać wszystkiego do jednego pliku. Lubię korzystać ze styled-components, ale absolutnie nie musisz tego zaciągać, żeby pisać czysty kod. Podobnie nie musisz wcale korzystać z Reduxa, wystarczą hooki.

Wydaje mi się, że obecnie twórcy Reacta robią wszystko, aby użytkownicy nie musieli używać słowa kluczowego class, jakby to było jakieś zło wcielone.

Bo to jest zło wcielone, dodane do języka tylko po to, żeby jeszcze więcej code monkeys z backgroundem Java czy C# pisało w tym kod. W JS nie ma klas i jest to wyłącznie cukier składniowy, który przykrywa prototypy. Klasy w JS nie działają tak jak w normalnych językach, które były od początku tworzone z myślą o programowaniu obiektowym.

IMO te hooki jedynie zmniejszają czytelność.

Znacznie mniej czytelny jest Redux, który dodatkowo posiada wysoki próg wejścia. Podobnie mało czytelne jest lawinowe przekazywanie stanu przez propsy. Hooki to wybawienie i jedna z najlepszych funkcjonalności w tej bibliotece.

O wiele bardziej wolę lifecycle methods w kompnentach klasowych niż jakieś sztuczne useEffect.

Nie wiem co jest fajnego w powtarzaniu kodu, albo używania wielu metod cyklu życia, żeby zrobić to samo co za pomocą jednego useEffect.

Poza tym stan powinny raczej posiadać obiekty, a nie funkcje.

JS to specyficzny język i ze względu na swoją budowę przechowywanie stanu w domknięciach jest bardzo często zbawienne.

@Haskell: Ja bym chętnie zobaczył jakąś niebanalną aplikację bez kilkunastu zaciągniętych bibliotek, bez Reduxa, z własnym systemem formularzy, opartą na hookach i w której komponenty nie miałyby kilkuset linii kodu. Widziałeś gdzieś taką na GitHubie?

A wytłumaczy mi ktoś o co chodzi w końcu z tym React Native? Bo był ogromny bum, wszyscy w tym pisali, a teraz coraz częściej spotykam się z opinią, że to jest be i lepszy chociażby flutter.

Nie wiem, jak ci, co wolą klasy + lifecycle methods, w ogóle je pamiętają.

Ja wolę hooki m.in. z tego powodu, że mogę czuć się mocny w React. Przy metodach zawsze mi się myliło wszystko. Po pierwsze - nazwy tych metod, ale to nie problem jeszcze (BTW twórcy Reacta celowo ponoć nazwali je w taki verbose sposób, żeby było łatwo je znaleźć w kodzie). Dużo gorzej zawsze mieć z tyłu głowy "która metoda do czego służy" i "która metoda, kiedy się odpalać" i śledzić zmiany z kolejnymi wersjami React.

Więc jeśli mam korzystać z lifecycle methods, to muszę ciągle wracać do dokumentacji czy ściąg. A działanie hooków mogę łatwiej spamiętać.

bez Reduxa

Bez Reduxa czy bez dodatkowej biblioteki do zmieniającego się stanu? Bo jak ktoś chce, to może Mobxa użyć choćby. Można Rx użyć (albo biblioteki stanu opartej o Rx). I tuzina innych popularnych reaktywno-stanowych bibliotek.

Z Reduxem to trochę paradoks, bo fenomen Reduxa polegał na tym, że był prosty i można było w nim pisać kod bez większych ceremonii (w 2015 standardem był Flux i inne biblioteki, które były bardziej skomplikowane od Reduxa).

Problem jednak pojawił się w tym, że w realnych aplikacjach prostota Reduxa okazała się niewystarczająca. Ludzie zaczęli się zastanawiać "gdzie włożyć skutki uboczne? jak zintegrować Reduxa z API?". Więc mimo, że React sam jest dodatkiem do Reacta*, to ludzie zaczęli robić kolejne dodatki, tym razem do Reduxa - choćby Redux Saga. Mało tego. Ludzie zaczęli robić dodatki do Redux Sagi. Czyli ludzie robią dodatki do dodatku do dodatku do Reacta.

Czyli taka fraktalizacja ekosystemu. Z jednej strony to dobrze, bo nie ma jednego frameworka, który coś wymusza, z drugiej strony źle, bo większość programistów nie ma na tyle doświadczenia i rozwagi, żeby umieć dobrać sobie te biblioteki. Po prostu idą za tłumem i robią to, co wszyscy, czyli np. wpieprzamy Reacta, Reduxa, Sagę, Redux Form i inne modne rozwiązania, bo to znają, nie chcą podejmować większych decyzji projektowych, nie wiedzieliby nawet jak.

No i oczywiście prostota Reduxa spaliła na panewce - bo mimo, że sama biblioteka jest prosta, to sposób jej używania zachęca do przeinżynierowywania aplikacji (i ludzie to bardzo często robią). To trochę jakby Redux był dobrą biblioteką, ale nie do tego, do czego ludzie ją używają. Jakby próbowali tego Reduxa na siłę wcisnąć.

*Redux technicznie jest niezależną biblioteką i można jej używać niezależnie od Reacta, ale jeśli chodzi o sposób korzystania, to najczęściej pewnie jest wykorzystywany z Reactem, więc skrótowo nazwę to dodatkiem do Reacta, mimo, że technicznie nim nie jest, a jedynie może być zintegrowany z Reactem.

Kondziowsky napisał(a):

A wytłumaczy mi ktoś o co chodzi w końcu z tym React Native?

Mam nieszczescie w tym pracowac.
Idea byla taka, ze do vdomu mozna podpiac dom z przegladarki, ale przeciez mozna podpiac natywne komponenty z dowolnego systemu, np. Android, ios, windows, windows phone. Jak sie rozwiaze pare problemow, to bedzie jsowy wraper natywnego ui. Pomysl dobry, wykonanie zle. Bazowanie na zewnetrznych paczkach w przegladarce stwarza problemy, ale bazowanie na node modules zawierajacych bridge do natywnych funkcji, tworzonych pod okreslone konfiguracje stworzylo pieklo.

nobody01 napisał(a):

Wydaje mi się, że obecnie twórcy Reacta robią wszystko, aby użytkownicy nie musieli używać słowa kluczowego class, jakby to było jakieś zło wcielone. IMO te hooki jedynie zmniejszają czytelność. O wiele bardziej wolę lifecycle methods w kompnentach klasowych niż jakieś sztuczne useEffect. Poza tym stan powinny raczej posiadać obiekty, a nie funkcje.

Prawda, że początkowo wygląda to dziwnie i nienaturalnie, ale można się do tego przyzwyczaić, a zawsze to mniej boilerplatu.

No ok, ale dalej chętnie bym zobaczył jakiś kod. Bo na razie jedynie filozofujemy. ;)

W Angularze nietrudno jest znaleźć przykładowe repozytorium, na którym można się wzorować, chociażby to: https://github.com/tomastrajan/angular-ngrx-material-starter Fakt, techniki zastosowane tu są overkillem dla większości aplikacji, ale nic nie stoi na przeszkodzie, żeby np. wywalić ngrxa. Jaka jest odpowiedź społeczności Reacta? Jest jakakolwiek?

Dla mnie problemem jest flux. To problem bardzo wielu frameworków. Jako, że we frontend wszedłem później, a zaczynałem w gamedevie, a poźniej backend, to pachnie mi to podobnie do niepotrzebnego, przebudowanego singletonu. Singletony stosować można, ale np. jako listenery, obserwery itp, które dalej komunikują się z odpowiednimi elementami MVC. Tym czasem widzę, że do reduxa pcha się całą logikę. W efekcie każda aplikację trzeba pisać od nowa i praktycznie nie da się wykorzystać nic poza efektami graficznymi.

nobody01 napisał(a):

W Angularze nietrudno jest znaleźć przykładowe repozytorium, na którym można się wzorować, chociażby to: https://github.com/tomastrajan/angular-ngrx-material-starter Fakt, techniki zastosowane tu są overkillem dla większości aplikacji, ale nic nie stoi na przeszkodzie, żeby np. wywalić ngrxa. Jaka jest odpowiedź społeczności Reacta? Jest jakakolwiek?

Żartujesz sobie? Do każdego możliwego framworka powstały takie example repo: https://github.com/gothinkster/realworld

Aplikacja React & Redux ma prawie 3 lata. Sporo się od tego czasu zmieniło :P Poza tym wygląda na bardzo uproszczoną. Nie ma chyba nawet walidacji formularzy (błędy idą z serwera), jak tak patrzę na komponent rejestracji: https://react-redux.realworld.io/#/register?_k=k3bhkx

Spojrzałem sobie też na ich repo dotyczące ASP.NET Core i słabo to wygląda. Jest encja na twarz, rzucanie wyjątków gdzie popadnie, nieoddzielone konfiguracje ORMa od encji. Do tego sama domena jest bardzo prosta.

Także uważałbym na te repozytoria.

renderme napisał(a):

Kondziowsky napisał(a):

A wytłumaczy mi ktoś o co chodzi w końcu z tym React Native?

Mam nieszczescie w tym pracowac.

Co za mało mądry tech lead zdecydował, żeby wybrać bibliotekę w wersji < 1.0 ? :D

mechanix napisał(a):

renderme napisał(a):

Kondziowsky napisał(a):

A wytłumaczy mi ktoś o co chodzi w końcu z tym React Native?

Mam nieszczescie w tym pracowac.

Co za mało mądry tech lead zdecydował, żeby wybrać bibliotekę w wersji < 1.0 ? :D

To głupie pytanie! :P

Co za mało mądry tech lead zdecydował, żeby wybrać bibliotekę w wersji < 1.0 ? :D

To był diabeł z piekła.
Jedyna zaleta jest taka, że gorzej już być nie może.
Wszystkie zależności mamy w package.json wpisane na sztywno, a jak jakaś wersja zniknie z npm to jest afera.