Po co context i redux w react native, gdy jest navigation.params

W projektach pracy zdarzało mi się pracować z reduxem i mobx. Obecnie wszyscy szaleją za react context, a ja powiem szczerze, że w prywatnych projektach zupełnie tego nie używam.
Jak robię jakąś apkę na boku, to zawsze korzystam z react navigation, a ewentualny globalny stan aplikacji trzymam w navigation.params. W ten sposób mam praktycznie najmniej boilerplatu, bo nie muszę tworzyć kontekstu, a tym bardziej całej struktury reduxa. przechowuje w params dwa obiekty - temp, i persistent, w których trzymam wszystkie potrzebne globalne informacje i nigdy nie trafiłem na żaden problem z tym związany. Temp nadpisuje przy każdej zmianie ekranu, persistant przenoszę. Po co komplikować?

Czy są jakieś obiektywne przewagi korzystania z reduxa, mobxa, czy kontekstu nad navigation.params?
Zdaje sobię sprawę, że potencjalnie jakieś przewagi optymalizacyjne można odnaleźć, ale to kwestia przemyślenia struktury danych.
Najbardziej mnie rozbraja jak widzę w projektach połączenie prop drilling, reduxa, contextu i navigation.params i to jest niby takie pro, bo wszystkie nowinki zostały wykorzystane - 4 sources of thruth.

Jak się robi same aplikacje ToDo, gdzie ma się 3 ekrany na krzyż to nawet i React nie potrzebny.

Zawsze w projektach ograniczałem się do React z Redux i to w zupełności wystarczyło. Nawet nie wiedziałem że jest coś takiego jako Context przed przeczytaniem tego wątku! Ale wydaje mi się (niech mnie ktoś poprawi jeśli się mylę) że zarówno Redux jak i Context można stosować wspólnie w innych celach. Redux zajmuje się danymi dostępnymi centralnie, natomiast Context można zastosować lokalnie, w ograniczonej skali. Łatwo mi sobie wyobrazić jakiś element rodzic który wewnętrznie ma kilka elementów dzieci. Wtedy rodzic może być podpięty do stanu Redux i wyciągnąć z niego potrzebne dane, a następnie udostępniać te dane dzieciom za pomocą kontekstu. Dzieci nie muszą się podpinać w ogóle pod stanu Redux, a dzięki użyciu Context nie trzeba propagować parametrów kilka poziomów w dół. Czy takie połączenie przynosi więcej pożytku niż szkody i czyni kod czytelniejszym? Nie wiem.

Wszystko zależy tak naprawdę od złożoności aplikacji i tego jak skomplikowane struktury danych musi obsługiwać.

Aventus napisał(a):

Zawsze w projektach ograniczałem się do React z Redux i to w zupełności wystarczyło. Nawet nie wiedziałem że jest coś takiego jako Context przed przeczytaniem tego wątku! Ale wydaje mi się (niech mnie ktoś poprawi jeśli się mylę) że zarówno Redux jak i Context można stosować wspólnie w innych celach. Redux zajmuje się danymi dostępnymi centralnie, natomiast Context można zastosować lokalnie, w ograniczonej skali. Łatwo mi sobie wyobrazić jakiś element rodzic który wewnętrznie ma kilka elementów dzieci. Wtedy rodzic może być podpięty do stanu Redux i wyciągnąć z niego potrzebne dane, a następnie udostępniać te dane dzieciom za pomocą kontekstu. Dzieci nie muszą się podpinać w ogóle pod stanu Redux, a dzięki użyciu Context nie trzeba propagować parametrów kilka poziomów w dół. Czy takie połączenie przynosi więcej pożytku niż szkody i czyni kod czytelniejszym? Nie wiem.

Wszystko zależy tak naprawdę od złożoności aplikacji i tego jak skomplikowane struktury danych musi obsługiwać.

Redux ma tylko jedną zaletę nad context API. A są nią middleware. Jeśli nie używasz middleware czy też innych dodatków do reduxa to bez sensu jest go używać.

MasterOf napisał(a):

Redux ma tylko jedną zaletę nad context API. A są nią middleware. Jeśli nie używasz middleware czy też innych dodatków do reduxa to bez sensu jest go używać.

Komercyjnie w pracy ich używam, ale jak robie projekt prywatnie za ustaloną cenę, to żal mi na to czasu na takie rzeczy odkąd są hooki.
Całą magię middleware skutecznie odwzorowuje customowym hookiem i jest to prostsze. Muszę faktycznie przyznać, że przed hookami byłby to dobry argument.

renderme napisał(a):

MasterOf napisał(a):

Redux ma tylko jedną zaletę nad context API. A są nią middleware. Jeśli nie używasz middleware czy też innych dodatków do reduxa to bez sensu jest go używać.

Komercyjnie w pracy ich używam, ale jak robie projekt prywatnie za ustaloną cenę, to żal mi na to czasu na takie rzeczy odkąd są hooki.
Całą magię middleware skutecznie odwzorowuje customowym hookiem i jest to prostsze. Muszę faktycznie przyznać, że przed hookami byłby to dobry argument.

A jak testujesz swój kod?

Redux ma tylko jedną zaletę nad context API. A są nią middleware. Jeśli nie używasz middleware czy też innych dodatków do reduxa to bez sensu jest go używać.

Nie wiem, nie znam Context żeby się wypowiadać nad wadami jednego nad drugim, chociaż z tego co na szybko znalazłem to Context nie jest zoptymalizowany pod częste aktualizowanie. Ponadto kolejne co przychodzi mi na myśl to czy Context wspiera debugowanie tak jak Redux, i ma coś podobnego do Redux DevTools? W tym możliwość przewijania historii zmian? Bo to również duża zaleta Reduxa kiedy pracuje się przy dużych aplikacjach.

Aventus napisał(a):

Nie wiem, nie znam Context żeby się wypowiadać nad wadami jednego nad drugim, chociaż z tego co na szybko znalazłem to Context nie jest zoptymalizowany pod częste aktualizowanie. Ponadto kolejne co przychodzi mi na myśl to czy Context wspiera debugowanie tak jak Redux, i ma coś podobnego do Redux DevTools? W tym możliwość przewijania historii zmian? Bo to również duża zaleta Reduxa kiedy pracuje się przy dużych aplikacjach.

Możesz używać narzędzi do reduxa z context API.
https://medium.com/better-programming/how-to-debug-a-react-context-api-app-547b75818754

Anyway, kto ci takich głupot nagadał że context API jest wolne?

A gdzie ja napisałem że jest wolne? Serio, co z ludźmi jest nie tak na tym forum że nagminnie przekręcają słowa?

Tutaj masz cytat członka teamu od React: https://github.com/facebook/react/issues/14110#issuecomment-448074060

Znalazłem jeszcze coś takiego żeby nie było że opieram się tylko na starych informacjach:

Although React Context is simple to implement and great for certain types of apps, it’s built in such a way that every time the value of the context changes, the component consumer rerenders.
*
So far, this hasn’t been a problem for our app because if the component doesn’t rerender whenever the value of the context changes, it will never get the updated value. However, the rerendering will not be limited to the component consumer; all components related to the context will rerender.*
[źródło]

Poza tym jeszcze jedno co mi przychodzi do głowy to fakt że z React masz po prostu wszystko centralnie, natomiast z Context musisz się trochę pobawić w mikro zarządzanie kontekstami bo jeśli dobrze rozumiem główną ideę to należy stosować konteksty zależnie od... kontekstu, czyli określonej grupy powiązanych ze sobą komponentów.