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

Odpowiedz Nowy wątek
2020-09-06 21:57

Rejestracja: 1 rok temu

Ostatnio: 20 godzin temu

0

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.

overengineering to chyba jedyna odp taki jest hype i tak ma byc ;) - marcio 2020-09-07 11:14

Pozostało 580 znaków

2020-09-07 11:23

Rejestracja: 2 lata temu

Ostatnio: 7 godzin temu

1

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

Pozostało 580 znaków

2020-09-07 11:27

Rejestracja: 4 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: UK

0

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ć.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2020-09-07 11:28

Pozostało 580 znaków

2020-09-07 11:28

Rejestracja: 2 lata temu

Ostatnio: 7 godzin temu

0
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ć.

edytowany 1x, ostatnio: MasterOf, 2020-09-07 11:29

Pozostało 580 znaków

2020-09-07 11:36

Rejestracja: 1 rok temu

Ostatnio: 20 godzin temu

0
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.

Pozostało 580 znaków

2020-09-07 11:43

Rejestracja: 2 lata temu

Ostatnio: 7 godzin temu

0
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?

mokka/chai lub jest. Ja mam takie podejście, że możliwie mało logiki przechowuje w aplikacji; posługuje się nią raczej do wyświetlania i przez to pokrycie testami aplikacji mobilnej wynosi u mnie z 10% jeżeli sam ją robię. Dla mnie bardziej ekstensywne testowanie frontendu, to przepalanie pieniędzy i jak mam x kasy za zlecenie, to nie piszę testów, których nie potrzebuję. W pracy, to zależne od budżetu i wymagań waha się poziom pokrycia testami, do 100%. Zdaje sobię sprawę, że redux wygodnie się testuje i też przyjemnie odtwarza, bo wszystko znajduje się w jednym miejscu. - renderme 2020-09-07 11:55
@renderme: Czyli mówisz, że twoje componenty nie wyświetlają różnych rzeczy w zależności od state? Jeśli tak to jest tak jak mówiłem. Piszesz proste aplikacje, więc bez sensu tobie jakieś lepsze narzędzia :) - MasterOf 2020-09-07 12:00
Prywatnie piszę raczej małe aplikacje, to fakt. W pracy zdarzało mi się też pisać ogromne kobyły, w których faktycznie testów było może więcej, ale głównie robiłem je dlatego, że projekt mógł przejąć ktoś inny/ w zespole były osoby różnie kumate itp. To jest podstawa sensu testowania i ogólnie szeroko pojętego TDD - współpraca i utrzymanie. Temat testowania frontendu to jest ogólnie temat rzeka i to na osobną dyskusję. Nie wiem jaki ma związek z wyborem pomiędzy hookiem obsługującym navigation.params, a reduxem. - renderme 2020-09-07 12:05

Pozostało 580 znaków

2020-09-07 11:44

Rejestracja: 4 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: UK

1

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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2020-09-07 11:50
Debugowanie w redux jest bardzo przyjemne, ale sam redux jest też bardzo czasochłonny. Co do optymalizacji, to temat dla mnie trochę niezrozumiały, bo nigdy nie trafiłem na żaden problem optymalizacyjny w R-N. Trzeba mocno nakomplikować i bez sensu renderować, żeby przepalić zasoby. - renderme 2020-09-07 11:58

Pozostało 580 znaków

2020-09-07 11:58

Rejestracja: 2 lata temu

Ostatnio: 7 godzin temu

0
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-pro[...]-context-api-app-547b75818754

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

No to też jest ciekawa filozofia, że można z context API zrobić reduxa bez reduxa. Jaki z tego zysk? Parę KB oszczędności? - renderme 2020-09-07 12:00
Sporo oszczędności i swoboda. Po co zapinać bibliotekę do czegoś co można szybko zrobić samemu? - MasterOf 2020-09-07 12:01
Jak wchodziło context API to faktycznie miało swoje problemy i redux nam nim przeważał. Teraz już nawet nie pamiętam, ale coś tam się za dużo razy renderowało. To dotyczyło jednak wersji alpha/beta. Teraz nie ma takich rzeczy, a przeciez redux jest oparty na context api :P - renderme 2020-09-07 12:13

Pozostało 580 znaków

2020-09-07 12:03

Rejestracja: 4 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: UK

1

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/r[...]/14110#issuecomment-448074060


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
Przecież to cytat z 2018 xddd - MasterOf 2020-09-07 12:04
To prawda, ale skąd ja mam wiedzieć co się zmieniło? - Aventus 2020-09-07 12:09

Pozostało 580 znaków

2020-09-07 12:25

Rejestracja: 4 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: UK

0

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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2020-09-07 12:26
No tak jest - trzeba użyć purecomponent/memo, albo własnego hooka jak chce się to optymalizować podobnie do automatycznej optymalizacji w redux. - renderme 2020-09-07 12:37

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0