Redux a lokalny stan

Chcę zintegrować Reduxa z Formikiem. Za sugestią autora Formika mam coś takiego:

export const login = ({ email, password }, setErrors, setSubmitting, history) => async dispatch => {
  try {
    await firebase.auth().signInWithEmailAndPassword(email, password)
    dispatch({ type: types.LOGIN, payload: null /* todo */ })
    history.push(HOME)
  } catch (e) {
    setErrors({"general": messages[e.code]})
  } finally {
    setSubmitting(false)
  }
}

Z jednej strony OK, bo wszystko ładnie działa, kod jest krótki i zrozumiały, a w globalnym stanie trzymam tylko to, co ma znaczenie dla aplikacji (nie mam tam milion razy isLoading i error). Z drugiej strony wydaje mi się, że nie powinienem zarządzać stanem formularza z akcji. Czy powinno się tak robić?

Nim dojdziesz do tego jak powinno się robić, daj znać jakie w tym przypadku masz priorytety.

Na ogół kod akcji/handlera/kontrolera będzie bardziej złożony jeśli będziesz bezpośrednio go wołać w testach.

Nie wiem, jakie mam priorytety, dopiero poznaję Reacta i czuję się jak dziecko we mgle. :( Nie chcę przeinżynierować tej aplikacji, ale jednocześnie chcę, żeby była napisana w miarę zgodnie z przyjętymi praktykami (są w ogóle takie w Reakcie?).

Z resztą zobacz, co setSubmitting robi pod spodem:

  const setSubmitting = React.useCallback((isSubmitting: boolean) => {
    dispatch({ type: 'SET_ISSUBMITTING', payload: isSubmitting });
  }, []);

Jak widać jest to funkcja, która wrapuje dispatch. Dzięki temu samo testowanie funkcji login może być łatwiejsze, ponieważ w testach wystarczy sprawdzić czy wstrzyknięte funkcje (np. setSubmitting) zostały odpowiednio zawołane. Taka rzecz powoduje, że nie musisz stosować reduxa do testów.

Także jeśli chcesz iść w tym kierunku to też powinieneś opakować wywołanie:

dispatch({ type: types.LOGIN, payload: null /* todo */ })

i wstrzyknąć je do tej funkcji login.

PS1, Osobiście chociaż nie programuje w javascript (może dlatego właśnie) powiem Ci, że testowanie akcji login za bardzo nie ma sensu. Nie ma tu za bardzo logiki więc sprawdzałbyś tylko czy funkcja wywołała funkcję. Jak dla mnie takie testy są mało wartościowe i powiem więcej, one zbyt szybko się psują, gdy ktoś wnieznaczny sposób zmieni Twoją akcję.

PS2, w ogóle dla mnie dziwne jest to, że do tak prostej rzeczy jak pokazywanie błędów używana jest kolejna biblioteka oraz to, że ta biblioteka jest trochę inwazyjna, ponieważ narzuca technikę wstrzykiwania. Automatyczna nauka i używanie takich rzeczy to właśnie elementy, które wskazujące na brak myślenia przy programowaniu.

Pamiętaj, zawsze myślenie jest lepsze niż automatyczne best practices ;-)

Eh, chyba poczekam, aż wyjdzie Blazor. Chcę podłączyć głupi formularz do Reduxa i widzę milion sposobów jak to zrobić (wiele osób uważa jeszcze, że Redux jest niepotrzebny, bo jest Context API), a najpopularniejsza biblioteka do walidacji okazuje się być inwazyjną. Anyway, dziękuję, że Ci się chciało, po prostu nie jestem na odpowiednim poziomie, by to ogarnąć.

A potrzebujesz w ogóle tego Reduxa? Hajp na Reduxa obecnie pikuje w dół, bo środowisko reactowe dostało nową zabawkę jaką są hooki.

Spoiler alert 1: ani jednego, ani drugiego nie potrzebujesz do pisania przyzwoitych aplikacji w Reacie

Spoiler alert 2: globalny stan to zło, w szczególności jeśli jest to lokalny stan wyniesiony do miana globalnego.

@neves: Zauważyłem, ale tu w komentarzach przeczytałem, że:

Context API jest stworzony głównie do rozwiązania problemu przekazywania propsów (prop drilling). Redux jest natomiast bardziej zaawansowanym narzędziem, które rozwiązuje znacznie więcej problemów. Redux wraz z odpowiednimi dodatkami (redux-thunk, redux-saga, redux-persist) + ogólne wspracie dla middleware pozwala zrobić następujące rzeczy:

• łatwe przekazywanie propsów pomiędzy komponentami
• zarządzanie logiką biznesową poza kodem komponentów
• narzędzia do debugowania
• łatwe "zrzucanie" stanu do localStorage i innych miejsc
• wsparcie dla server-side renderingu stanu (możemy zaserwować stronę użytkownikowi razem ze stanem)
• łatwe pisanie własnych middleware

Więc na wszelki wypadek użyłem, szczególnie że to i tak w ramach nauki.

Ad. 2: Co proponujesz w zamian?

Czysty react bez globalnego stanu jeśli on nie jest do niczego potrzebny i zwykłe przesyłanie danych za pomocą propsów a nie context api. Natomiast jeśli chodzi o obsługę formularzy to tu jest prawdziwy dziki zachód i ból, żadne z dostępnych rozwiązań mi się nie podoba, napisałem dwa własne ale też mi się nie podobają :D

Jakoś trudno mi to sobie wyobrazić. Gdzie trzymałbyś np. dane użytkownika (id, token itd.)? W stanie najwyższego komponentu? I co Ci się nie podoba w takim Formiku? Boilerplate? ;)

nobody01 napisał(a):

Jakoś trudno mi to sobie wyobrazić. Gdzie trzymałbyś np. dane użytkownika (id, token itd.)? W stanie najwyższego komponentu? I co Ci się nie podoba w takim Formiku? Boilerplate? ;)

A takie rzeczy to raczej storage bo wydaje mi się, że po nacisnięciu F5 to wszystko zniknie z ze stanu globalnego

Musze to zobaczyc. Ma ktos link do jakiegos przykladowego projektu?