React - pytanie o react hooki

Hej, mam kilka pytań odnośnie webhooków w funkcyjnych komponentach:

1. Czy robienie wewnętrznych metod w funkcyjnym komponencie to dobra praktyka ? Czy zawsze muszę je opakowywać w useCallback() ? Czy w tablicy zależności powinienem podawać w tych metodach wszystkie propsy i stany z których ta funkcja korzysta ?

2. Jeśli w useEffect korzystam z inner metody, którą owrapowałem w useCallback() to w zależnościach muszę ją podać ? Miałem taką sytuację, że inner metoda owrapowana useCallbackiem nasłuchiwała na propsy, a useEffect nasłuchiwał na tą metodę i mi się zapętliło.

3. Jeżeli w propsach mam jakiś obiekt z dwoma polami i chciałbym wywołać useEffect na zmianę któregoś z tych pól to powinienem w tablicy zależności dać tylko [props.someObject] czy [props.someObject.a, props.someObject.b] ?

Bambo napisał(a):

Hej, mam kilka pytań odnośnie webhooków w funkcyjnych komponentach:

1. Czy robienie wewnętrznych metod w funkcyjnym komponencie to dobra praktyka ? Czy zawsze muszę je opakowywać w useCallback() ? Czy w tablicy zależności powinienem podawać w tych metodach wszystkie propsy i stany z których ta funkcja korzysta ?

Funkcje nazywają się metodami tylko wewnątrz klasy, we wewnątrz funkcji masz już tylko funkcje.
Nie musisz zawsze opakowywać, używa się tego w celach poprawiania wydajności, dopóki nie masz problemu z wydajnością idź w nieopakowane funkcje.
Powinieneś podać tylko te które powodują zmianę definicji funkcji, czyli te które są używane wewnątrz ciała funkcji, bynajmniej nie argumenty funkcji.

2. Jeśli w useEffect korzystam z inner metody, którą owrapowałem w useCallback() to w zależnościach muszę ją podać ? Miałem taką sytuację, że inner metoda owrapowana useCallbackiem nasłuchiwała na propsy, a useEffect nasłuchiwał na tą metodę i mi się zapętliło.

nie musisz podawać, tam podajemy tylko te zależności których zmiana ma wywołać efekt uboczny, równie dobrze można tam podać te same propsy które powodują zmianę owrapowanej funkcji

3. Jeżeli w propsach mam jakiś obiekt z dwoma polami i chciałbym wywołać useEffect na zmianę któregoś z tych pól to powinienem w tablicy zależności dać tylko [props.someObject] czy [props.someObject.a, props.someObject.b] ?

Jeśli nie mutujesz stanu opcja pierwsza powinna działać tak samo jak druga, jak mutujesz tylko druga zadziała, opcja pierwsza jest preferowana.

@neves:

A są jakieś dobre praktyki/zasady używania useEffect() ?

Ja jestem backendowcem, robię reacta od miesiąca może i o ile jakieś proste casy są z definicji easy, tak mam teraz ekran, w którym się dużo dzieje, ma wiele stanów, od których zależy to co pobieram z backendu i dodatkowo z paginacją. I jeszcze od każdego stanu zależy jego wygląd itd .. i trochę zacząłem się gubić :/

A czytałeś dokumentację? React w przeciwieństwie do Angulara ma bardzo przystępnie napisaną i znacznie przyjemniejszą dokumentację, wszystko można w niej znaleźć:
Using the Effect Hook

A jeśli coś się staje dobrą praktyką/wzorcem, to zwykle też ląduje w dokumentacji, tak było chociażby z render propsami.

React jest prosty, zabawa się właśnie zaczyna kiedy trzeba zarządzać stanem i komunikować się pomiędzy komponentami :)

@neves:

Poczytałem sobie blogi i dokumentację reactową, ale nadal nie mogę znaleźć pewnej odpowiedzi, która mnie męczy.

Czy w funkcjach wewnętrznych w naszym funkcyjnym komponencie jest bezpieczne odwoływanie się tak bezpośrednio do stanu ? To nie jest czasem tak, że jak chcemy użyć zmiennej ze stanu to powinniśmy na nią nasłuchiwać useEffectem ?

Bo zastanawiałem się dlaczego np jak mamy metodę fetchMore() podpiętą pod FlatList to w niej raczej w jakiś artykułach ludzie inkrementują sobie page:

setPage(prev => prev + 1)

I potem nasłuchują na page w useEffect.

Bo można by po prostu w fetchMore() zrobić

api.get(page + 1)

i inkrementować page jak dostaneimy sucess.

Czy tu jest jakaś zasada ?
Wiem, że dzięki 1 podejściu mamy pewność, że page jest takie jak chcemy a tutaj niekoniecznie.

Jest względnie bezpieczne, pomijając delikatny race condition jeśli jakieś eventy przyjdą bardzo szybko po sobie (w praktyce prawie w ogóle nie występuje) to możemy operować na nieświeżym stanie i stracić jakąś inkrementację w tym przypadku. Pomijając to, nie ma żadnych przeszkód by w dowolnym miejscu czytać bezpośrednio ze stanu w obrębie komponentu, jedynie modyfikować stanu nie można bezpośrednio.

Natomiast pierwszy sposób jest bardziej idiomatyczny dla reacta, i jest to też drobne odwrócenie sterowania, masz jeden fragment kodu który modyfikuje zmienną i drugi fragment kodu którego nie obchodzi kto zmodyfikował zmienną tylko robi swoje wczytuje dane, i na dodatek całość zajmie mniej linijek.

Drugi sposób też będzie działał, może zostać utracona jakaś modyfikacja czym bym się nie przejmował, zajmie więcej linijek, tyle że tak się zwykle nie pisze w reacice z hookami. React z hookami skręca bardzo mocno w kierunku reaktywnego funkcyjnego programowania.