Wstęp
Wyobraź sobie: klient dodaje produkt do koszyka, ale po chwili widzi, że koszyk jest pusty. Albo zmienia kolor buta, a strona przeskakuje do góry. Albo – najgorsze – finalizuje zamówienie, a system pokazuje inny stan magazynowy niż rzeczywisty. Każdy z tych scenariuszy to efekt jednego, często bagatelizowanego problemu: złego zarządzania stanem aplikacji.
W e-commerce, gdzie użytkownik oczekuje błyskawicznej reakcji i spójności danych, zarządzanie stanem to nie tylko kwestia kodu – to fundament UX i konwersji. Niestety, w praktyce widzę, że wiele sklepów (szczególnie tych zbudowanych na szybko, na gotowych szablonach lub rozwijanych przez lata bez refaktoringu) popełnia trzy konkretne błędy. Kosztują one nie tylko nerwy, ale prawdziwe pieniądze.
Błąd 1: Globalne stany, czyli jeden wielki worek
Pierwszy i najczęstszy błąd to przechowywanie wszystkiego w jednym, globalnym stanie. W praktyce wygląda to tak, że dane o użytkowniku, koszyku, produktach, filtrach, a nawet stanie UI (np. czy menu jest otwarte) lądują w jednym obiekcie. Brzmi znajomo? To klasyczny symptom braku architektury.
Dlaczego to problem?
Po pierwsze, każda zmiana w tym wielkim worku powoduje przerenderowanie całego drzewa komponentów. Nawet jeśli zmienił się tylko status zalogowania, odświeżają się listy produktów. To prosta droga do spadków wydajności i frustracji animacjami.
Po drugie, globalny stan to koszmar przy debugowaniu. Wyobraź sobie, że koszyk klienta pokazuje nieprawidłową liczbę sztuk. Gdzie szukać błędu? W akcjach koszyka, w reducerze, w efekcie ubocznym, a może w komponencie? Bez podziału na domeny (np. koszyk, produkty, użytkownik) tracisz kontrolę.
Realny przykład:
Spotkałem się z sytuacją, gdzie sklep odzieżowy używał Reduxa w sposób płaski – wszystkie stany w jednym reducerze. Przy dodawaniu produktu do koszyka, aplikacja przeliczała na nowo cały katalog, co trwało 300 ms. Klient myślał, że przycisk jest nieaktywny, więc klikał wielokrotnie. Efekt: 15% porzuconych koszyków.
Rozwiązanie:
Podziel stan na domeny. Użyj narzędzi takich jak Redux Toolkit (z createSlice) lub Zustand, które wymuszają izolację. Każda domena powinna mieć własny store (lub slice). Dzięki temu zmiana w koszyku nie wpływa na listę produktów. Dodatkowo, stosuj selektory z memoizacją (np. Reselect), aby uniknąć niepotrzebnych przerenderowań.
Błąd 2: Brak synchronizacji stanu z backendem (lub zbyt częsta synchronizacja)
Drugi błąd to albo całkowity brak synchronizacji stanu lokalnego z danymi z serwera, albo przesadna gorliwość – wysyłanie requestów przy każdej zmianie.
Scenariusz 1: Brak synchronizacji
Stan lokalny (np. koszyk) jest przechowywany tylko w Reduxie, a po odświeżeniu strony znika. Aby go odzyskać, trzeba ponownie pobrać dane z API. Jeśli użytkownik dodał produkt do koszyka, ale nie zapisał się on w bazie (bo np. nie został wysłany), po odświeżeniu koszyk jest pusty. Klient myśli, że system go oszukał.
Scenariusz 2: Zbyt częsta synchronizacja
Każda zmiana ilości w koszyku wysyła request do API. To niepotrzebne obciążenie serwera i potencjalne opóźnienia. Jeśli aplikacja czeka na odpowiedź przed zaktualizowaniem UI, użytkownik odczuwa lag. Jeśli aktualizuje UI optymistycznie (zakładając sukces), a request się nie powiedzie, powstaje niespójność.
Dlaczego to realny problem?
W branży widziałem sklep, który wysyłał żądanie API przy każdym kliknięciu przycisku „+” w koszyku. Serwer ledwo wyrabiał, a użytkownicy mieli wrażenie, że aplikacja zacina się. Po wdrożeniu lokalnego stanu z batchowym wysyłaniem co 2 sekundy (plus finalne zapisanie przy checkout), czas odpowiedzi spadł o 70%.
Rozwiązanie:
Stosuj strategię optymistycznego UI z debounce’em. Zaktualizuj stan lokalny natychmiast, a żądanie do API wyślij z opóźnieniem (np. 300 ms po ostatniej zmianie). Jeśli request się nie powiedzie, cofnij zmianę i poinformuj użytkownika. Do zarządzania stanem serwerowym używaj bibliotek takich jak React Query, RTK Query, SWR. Automatyzują one cache’owanie, odświeżanie i synchronizację.
Błąd 3: Ignorowanie stanów nieudanych i krawędziowych
Trzeci błąd to zakładanie, że wszystko działa idealnie. W praktyce stan aplikacji to nie tylko „dane załadowane” i „dane puste”. To także:
- Ładowanie (loading state)
- Błąd (error state)
- Pusta odpowiedź (empty state)
- Stan nieautoryzowany (np. wygasły token)
- Stan częściowo załadowany (np. dane użytkownika są, ale produkty jeszcze nie)
Większość sklepów skupia się tylko na dwóch pierwszych, ignorując resztę. Efekt? Użytkownik widzi biały ekran lub nieskończone spinner, gdy powinien dostać komunikat „Brak produktów w tej kategorii” lub „Nie masz uprawnień do tego zamówienia”.
Realny przypadek:
Sklep z elektroniką wyświetlał komunikat „Przepraszamy, wystąpił błąd” za każdym razem, gdy API zwróciło 401 (token wygasł). Użytkownik nie wiedział, że po prostu musi się zalogować ponownie. Po dodaniu logiki przechwytywania błędów i przekierowania na stronę logowania, wskaźnik porzuconych sesji spadł o 30%.
Rozwiązanie:
Zdefiniuj osobne stany dla każdej operacji asynchronicznej. Użyj patternu state machine (np. XState) lub prostego enum z trzema wartościami: idle, loading, error. Pamiętaj też o stanie pustym (gdy lista jest pusta) i stanie nieautoryzowanym. Dla każdego stanu przygotuj odpowiedni widok. Nie zostawiaj użytkownika w zawieszeniu.
Dodatkowo, implementuj obsługę błędów globalnych – np. interceptory w Axios lub middleware w Reduxie, które automatycznie odświeżają token lub przekierowują do loginu.
Podsumowanie
Złe zarządzanie stanem to nie tylko problem techniczny – to realne straty finansowe. Globalne worki danych spowalniają aplikację i utrudniają utrzymanie. Brak synchronizacji prowadzi do niespójności i frustracji. Ignorowanie stanów brzegowych psuje UX i obniża zaufanie.
Jeśli prowadzisz e-commerce, przyjrzyj się swojemu kodowi. Czy stan koszyka jest izolowany od reszty? Czy używasz narzędzi do zarządzania stanem serwerowym? Czy obsługujesz błędy i stany puste w widoczny sposób?
W JurskiTech na co dzień pomagamy firmom poprawiać wydajność i UX – zarządzanie stanem jest jednym z pierwszych elementów, które badamy. Często wystarczy refaktoring stanu, by konwersja wzrosła o kilkanaście procent. A to już realny wynik dla biznesu.
Jeśli widzisz u siebie opisane problemy – skontaktuj się. Pomożemy Ci posprzątać kod i sprawić, że sklep będzie latał.
