quack : )

@pewnie-kaczka Jaką ma przewagę nad Apollo Graphql?

@Melonusk dla mniejszych projektów idealny bo jest bardzo szybki, nie trzeba wywoływać w useEffect przez co nie ma dodatkowych przerenderowań, i szereg dodatkowych narzędzi, w sumie jak apollo trzyma w cache dane ale gdy mamy określone endpointy to nie ma sensu bawić się w grapql

@pewnie-kaczka Jest i nie trzeba pchać tego w redux-a czy inne providery. Robisz custom hook-a gdzie parsujesz dane z backendu i po temacie.

@pewnie-kaczka jest w pyte, ale nie jest bez wad:

• brak normalized caching (jak na przykład w urql, ale to specyfika Rest API to powoduje), co generuje większą złożoność zarządzania danymi w cachu (i to jeszcze na bazie kluczy gdzie te same, pobrane dane, z tym samym id mogą istnieć w różnych miejscach w cachu)
  

• hook useQuery jest mocno boilerplaty, generuje mnóstwo szumu w kodzie z taką liczbą parametrów jakie zwraca: isFetched, isLoading, isPaused, isSuccess, itd. i jak masz do wykonania kilka requestów w jednym miejscu to robi sie syf, a parametry typu bool generują ilość ifów w funkcji renderującej
  

na plus:

kod źródłówy jest mega czysty, łatwo zrozumieć jak działa react-query pod maską, cała idea react-query jest oparta na bazie wzorca observera i z wykorzystaniem programowania reaktywnego, biblioteka również eksportuje te observery, tj. QueryObserver, InfiniteQueryObserver i MutationObsever, dzięki czemu można zbudować własną implementację pobierania danych (chociażby z wykorzystaniem wariantu AsyncData, żeby pozbyć się niepotrzebnego boilerplatu o którym wyżej wspomniałem) zachowując wszystkie funkcje z react-query