Od niedawna zacząlem się uczyć reacta i zastanawia mnie to czy komponent główny aplikacji powinien być funkcyjny czy nie? Jaka jest rekomendacja? Przy komponentach funkcyjnych można wykorzystać hooki.
0
1
konewka85 napisał(a):
Od niedawna zacząlem się uczyć reacta i zastanawia mnie to czy komponent główny aplikacji powinien być funkcyjny czy nie? Jaka jest rekomendacja? Przy komponentach funkcyjnych można wykorzystać hooki.
Trendy są takie, że całą "nową" funkcjonalność pisze sie na hookach - są po wieloma wzgledami lepsze od klas. Zastanowiłbym się czy potrzebujesz w tym głównym komponencie trzymać stan, jeżeli tak, to zastosowanie klasy nie byłoby jakimś dużym błedem.
1
Dokumentacja Reacta mówi, że nie ma potrzeby robić na hookach i można na klasach, ale zalecają spróbowanie hooków:
https://reactjs.org/docs/hooks-faq.html#do-i-need-to-rewrite-all-my-class-components
Tutaj też rozwijają myśl:
https://reactjs.org/docs/hooks-faq.html#should-i-use-hooks-classes-or-a-mix-of-both
komponent główny aplikacji
To, że masz w ogóle jakiś "komponent główny aplikacji" to już może być problem, bo to przypuszczalnie jakiś "god object", do którego wrzucasz całą logikę, pełno event handlerów czy masę JSXa. Tak można robić coś na szybko, ale na dłuższą metę taki kod trudno utrzymywać.
Chyba, że to skrót myślowy (bo wiadomo, że któryś komponent musi być na górze - więc "główny"?), ale tak czy siak - im większy komponent i im więcej różnych rzeczy robi naraz, tym gorzej nad tym panować. Lepiej robić jakieś małe komponenty, bez nastawienia, że ma być jakiś "komponent główny". A przecież nawet ten komponent na samej górze nie musi być jakiś super rozbudowany.
0
Czyli stanu nie powinno się trzymać w głównym komponencie? Skoro komponent główny nie jest potrzebny to gdzie wrzucać poszczególne komponenty jak nie do głównego komponentu? I jeszcze jedno pytanie zakładając, że mam taki prosty komponent Header w którym znajduje się obrazek oraz nagłówek. Czy wartość dla tego nagłówka i src dla obrazka przekazywać po prostu przez atrybut do komponentu czy trzymać takie rzeczy w state?
0
ktoś coś?
0
konewka85 napisał(a):
Czyli stanu nie powinno się trzymać w głównym komponencie? Skoro komponent główny nie jest potrzebny to gdzie wrzucać poszczególne komponenty jak nie do głównego komponentu? I jeszcze jedno pytanie zakładając, że mam taki prosty komponent Header w którym znajduje się obrazek oraz nagłówek. Czy wartość dla tego nagłówka i src dla obrazka przekazywać po prostu przez atrybut do komponentu czy trzymać takie rzeczy w state?
"Głowny" kompnent jest najczęściej używany do podpinania providerów, raczej nie trzyma się tam stanu wprost.
Stan globalny trzyma się w reduxie/mobxie/context i accessuje sie w komponentach hookami albo hoc.
Nie ma sensu trzymać w state czegos co jest stałą.
1
Skoro komponent główny nie jest potrzebny to gdzie wrzucać poszczególne komponenty jak nie do głównego komponentu?
Dlatego napisałem, że zawsze jakiś komponent będzie na górze. Ale nie musi on być specjalnie rozbudowany, więc pytanie, czy potrzeba go nazywać "głównym". Chociaż przyznaję, łatwiej jest pisać wrzucając większość rzeczy do jednego komponentu, ale to raczej pisanie "na szybko", a na dłuższą metę jednak się nie sprawdzi.
Czyli stanu nie powinno się trzymać w głównym komponencie?
Stan to nie tylko dane, ale też sposób manipulacji tym stanem, czyli pewna logika.
Trzymając stan + logikę w jednym miejscu aplikacji masz pewne zalety (np. większa kontrola, synchronizacja między różnymi komponentami), ale masz też pewne wady (wszystkie komponenty stają się zależne od tego globalnego stanu).
Ale jest też podejście inne, czyli trzymanie stanu lokalnie, wtedy masz wady (bo każdy komponent sam sobie rzepkę skrobie), ale może to też być zaleta (niezależne od siebie komponenty, które działają bez podłączania pod stan).
Myślę, że odpowiedź na to, które podejście jest właściwe, brzmi "to zależy". Nawet w jednej aplikacji można mieszać podejścia i pewne rzeczy trzymać w jednym miejscu (np. w komponencie na samej górze* albo w Redux, Mobx itp.), a inne rzeczy trzymać w stanie lokalnym.
Przy czym nawet trzymając/dostarczając stan w komponencie X, wcale nie musimy całego kodu wrzucać tam (np. możemy wydzielić jakąś część kodu do oddzielnych plików, tworząc sobie własne hooki. Albo przy używaniu Redux również funkcje zmieniające stan mogą być zupełnie gdzie indziej, w innym pliku, niż sam komponent, który będzie ten stan pobierał...). Chodzi o to, żeby był porządek, a nie wszystko napaćkane (czyli "zasada pojedynczej odpowiedzialności").
* w sumie dziwnie to brzmi, "główny komponent" jakoś bardziej ładnie brzmi, ale jednak kojarzy się z jakąś kobyłą, do której się wrzuca wszystko...
0
Nalhin napisał(a):
konewka85 napisał(a):
Czyli stanu nie powinno się trzymać w głównym komponencie? Skoro komponent główny nie jest potrzebny to gdzie wrzucać poszczególne komponenty jak nie do głównego komponentu? I jeszcze jedno pytanie zakładając, że mam taki prosty komponent Header w którym znajduje się obrazek oraz nagłówek. Czy wartość dla tego nagłówka i src dla obrazka przekazywać po prostu przez atrybut do komponentu czy trzymać takie rzeczy w state?
"Głowny" kompnent jest najczęściej używany do podpinania providerów, raczej nie trzyma się tam stanu wprost.
Stan globalny trzyma się w reduxie/mobxie/context i accessuje sie w komponentach hookami albo hoc.Nie ma sensu trzymać w state czegos co jest stałą.
@Nalhin czyli po prostu src dla obrazka oraz wartość dla nagłówka najlepiej przekazać za pomocą atrybutów do komponentu Header i w oddzielnych atrybutach podać wartość dla src i nagłówka?
0
konewka85 napisał(a):
Nalhin napisał(a):
konewka85 napisał(a):
Czyli stanu nie powinno się trzymać w głównym komponencie? Skoro komponent główny nie jest potrzebny to gdzie wrzucać poszczególne komponenty jak nie do głównego komponentu? I jeszcze jedno pytanie zakładając, że mam taki prosty komponent Header w którym znajduje się obrazek oraz nagłówek. Czy wartość dla tego nagłówka i src dla obrazka przekazywać po prostu przez atrybut do komponentu czy trzymać takie rzeczy w state?
"Głowny" kompnent jest najczęściej używany do podpinania providerów, raczej nie trzyma się tam stanu wprost.
Stan globalny trzyma się w reduxie/mobxie/context i accessuje sie w komponentach hookami albo hoc.Nie ma sensu trzymać w state czegos co jest stałą.
@Nalhin czyli po prostu src dla obrazka oraz wartość dla nagłówka najlepiej przekazać za pomocą atrybutów do komponentu Header i w oddzielnych atrybutach podać wartość dla src i nagłówka?
Nie ma czegoś takiego jak "najlepiej". Wszystko zależy jaki design chcesz mieć. Jednakże lepiej nie robić za dużo "opcji" (jako propsów) w komponentach, dla rzeczy które można spokojnie zhardcodować (chyba, że chcesz mieć uniwersalny komponent).
0
Nalhin napisał(a):
konewka85 napisał(a):
Nalhin napisał(a):
konewka85 napisał(a):
Czyli stanu nie powinno się trzymać w głównym komponencie? Skoro komponent główny nie jest potrzebny to gdzie wrzucać poszczególne komponenty jak nie do głównego komponentu? I jeszcze jedno pytanie zakładając, że mam taki prosty komponent Header w którym znajduje się obrazek oraz nagłówek. Czy wartość dla tego nagłówka i src dla obrazka przekazywać po prostu przez atrybut do komponentu czy trzymać takie rzeczy w state?
"Głowny" kompnent jest najczęściej używany do podpinania providerów, raczej nie trzyma się tam stanu wprost.
Stan globalny trzyma się w reduxie/mobxie/context i accessuje sie w komponentach hookami albo hoc.Nie ma sensu trzymać w state czegos co jest stałą.
@Nalhin czyli po prostu src dla obrazka oraz wartość dla nagłówka najlepiej przekazać za pomocą atrybutów do komponentu Header i w oddzielnych atrybutach podać wartość dla src i nagłówka?
Nie ma czegoś takiego jak "najlepiej". Wszystko zależy jaki design chcesz mieć. Jednakże lepiej nie robić za dużo "opcji" (jako propsów) w komponentach, dla rzeczy które można spokojnie zhardcodować (chyba, że chcesz mieć uniwersalny komponent).
@Nalhin czyli byś sugerował aby mój komponent header miał wszystko zahardkodowane już bezpośrednio w komponencie (zarówno nagłówek i src do obrazka) ? I czy chcąc zrobić prostą strone statyczną w reacie w której będzie jedynie header, footer oraz niewielka ilość contentu czy w ogóle powinienem używać reduxa?
0
Raczej nie używałbym reduxa w tego typu aplikacji. Przy małych/prostych projektach reduxa można spokojnie zastąpić portalami/context + useReducer. Nie zmienia to faktu, że warto się go nauczyć, chociażby po to, żeby wiedzieć kiedy opłaca się go zastosować, a kiedy nie.
0
@Nalhin: tylko właśnie w mojej prostej stronie statycznej nic nie będzie zmieniane, więc czy w ogóle przechowywanie stanu mi jest potrzebne czy po prostu wszystko zahardkodować? Będzie jedynie header, footer oraz content strony.
0
konewka85 napisał(a):
@Nalhin: tylko właśnie w mojej prostej stronie statycznej nic nie będzie zmieniane, więc czy w ogóle przechowywanie stanu mi jest potrzebne czy po prostu wszystko zahardkodować? Będzie jedynie header, footer oraz content strony.
Tak, w stanie powinno trzymać się tylko rzeczy które mogą się zmieniać.
0
@Nalhin: czyli u mnie Provider również nie jest potrzebny? Jakbyś sugerował zrobić aplikacje tego prostego typu (prosta strona statyczna)? Po prostu w App komponencie dodać komponenty z headerem, footerem i contentem?
1
konewka85 napisał(a):
@Nalhin: czyli u mnie Provider również nie jest potrzebny? Jakbyś sugerował zrobić aplikacje tego prostego typu (prosta strona statyczna)? Po prostu w App komponencie dodać komponenty z headerem, footerem i contentem?
React jest "unopinionated" bibioteka, nie ma czegoś takiego jak strikte lepsze/gorsze rozwiazanie. Zrób jak uważasz, przy malych stronkach nie zrobi to jakiejkolwiek różnicy.
0
@Nalhin: a czy w ogóle mają strone statyczną na której jest na prawde mało contentu to czy powinno wtedy to się dzielić na komponenty czy wszystko powinno zostać wrzucone do app komponentu? Nic na tej stronie się nie zmienia