Globalny stan - po co to komu?

0

Zacząłem ostatnio korzystać z NgRxa i to jest jakiś dramat. Do zwykłego CRUDa samego kodu infrastrukturalnego (efekty, selektory, reducer, akcje) jest jakieś 200 linii... Poziom boilerplate'u jest ogromny. I nie bardzo można to zmienić. No chyba że pobierze się kolejne N bibliotek.

Kiedy globalny stan ma sens? Kiedy warto tak komplikować architekturę, żeby osiągnąć te korzyści, o których można przeczytać na medium: mniej zapytań do API, mniej przepychania propsów? Ciekaw jestem Waszych opinii oraz doświaczeń. :)

1

Globalny state aplikacji jest bardzo pomocny przy większych aplikacjach, rzeczywiście jest tak jak piszesz przy mniejszej skali aplikacjach jest to przerost formy nad treścią natomiast przy większych jest na prawdę pomocny, unikamy emitowania, przekazywania propsów po 3-4 komponenty w dół i mam dostęp do stanu z każdego komponentu :)

2
Geforce napisał(a):

Globalny state aplikacji jest bardzo pomocny przy większych aplikacjach, rzeczywiście jest tak jak piszesz przy mniejszej skali aplikacjach jest to przerost formy nad treścią natomiast przy większych jest na prawdę pomocny, unikamy emitowania, przekazywania propsów po 3-4 komponenty w dół i mam dostęp do stanu z każdego komponentu :)

No wlasnie potem przy wiekszej aplikacji ogarnij w ktorym miejscu ci sie ten stan mutuje

1

Jeśli kogoś boli przepychanie propsów to wystarczy użyć Context bezpośrednio, a nie iść w globalny stan/redux.

Jak mamy jakąś aplikację która robi coś na tyle ważnego że musimy zająć się każdym najmniejszym problemem na froncie, to właśnie ten globalny stan/redux, który umożliwia time travelling, albo chociaż sam snapshot stanu aplikacji, bardzo przydaje się w analizie post-mortem.

Ale takich aplikacji jest bardzo mało, większość to CRUDy, a innych zalet globalnego stanu nie dostrzegam.

0
Geforce napisał(a):

Globalny state aplikacji jest bardzo pomocny przy większych aplikacjach, rzeczywiście jest tak jak piszesz przy mniejszej skali aplikacjach jest to przerost formy nad treścią natomiast przy większych jest na prawdę pomocny, unikamy emitowania, przekazywania propsów po 3-4 komponenty w dół i mam dostęp do stanu z każdego komponentu :)

Przekazywanie propsów 3-4 komponenty w dół jest upierdliwe, ale z drugiej strony nie wiem, czy to jest rozwiązywanie właściwego problemu. Jeśli w komponencie 4 poziomy w dół mamy potrzebę odwołania się do danych z góry, to ja bym się zastanowił, czy hierarchia komponentów jest dobrze zaprojektowania. Może to podłączanie globalnego stanu(ew. kontekstu) bywa po prostu krótkowzrocznym wygodnictwem, a nie faktyczną potrzebą?

Owszem, czasem mamy do czynienia z czymś, co faktycznie ma być globalne (np. wybrana wersja językowa strony, nazwa zalogowanego użytkownika, czy wybrano jasny/ciemny motyw), ale czasem ludzie nawet coś, co jest do bólu lokalne, traktują jako część globalnego stanu (np. dane jakiejś encji), którą trzeba zassać ze store'a za pomocą jakiegoś selektora. I kod się rozrasta.

Poza tym czasami przekazywanie propsów jest naturalne, jeśli np. mapujesz tablicę

function Todos({ todos } ) {
    return todos.map(todo => <Todo todo={todo} />
}

to takie coś będzie dla mnie bardziej naturalne niż wstrzykiwanie cząstki globalnego stanu do komponentu Todo.

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