Zużycie pamięci redux [zamknięte]

Struktura Redux faworyzuje paradygmat stanu niezmiennego / funkcji czystej, który promuje tworzenie nowego stanu z poprzedniego stanu pod względem bieżącej akcji. Zastosowanie tego paradygmatu jest niepodważalne.

Mój główny problem dotyczy tego, że ponieważ reduktory Redux chętnie zwracają nowe, nowe stany z poprzednich stanów dla każdej wywoływanej akcji, masowy drenaż pamięci (nie mylić z przeciekami pamięci) stałby się częstym zjawiskiem w wielu rzeczywistych aplikacjach . Biorąc pod uwagę, że aplikacje Javascript zwykle działają w przeglądarce na urządzeniach przeciętnego użytkownika, które mogą również uruchamiać kilka innych aplikacji specyficznych dla urządzenia oraz kilka innych kart i okien przeglądarki, potrzeba oszczędzania pamięci staje się coraz bardziej oczywista.

Czy ktoś faktycznie porównał zużycie pamięci przez aplikację Redux do tradycyjnej architektury Flux? Jeśli tak, czy mogliby podzielić się swoimi odkryciami?

To jest ważny problem. Chociaż nie mierzyłem wykorzystania pamięci przez aplikacje Redux, myślę, że przed podjęciem korzystania z Redux (lub jakiegokolwiek innego frameworka w tej sprawie) powinieneś utworzyć testy warunków skrajnych, które emulują ilości danych, częstotliwość zmian i intensywność obliczeń aplikacji, którą ty zamierzają budować. Użyj tych testów warunków skrajnych przed podjęciem technologicznych decyzji dotyczących tego, czy przyjęcie niezmienności działa w twoim konkretnym przypadku.

Zauważ, że czasami ludzie mylą się z Redux i zakładają, że przy każdej akcji drzewo stanu musi być głęboko sklonowane. Absolutnie tak nie jest. Tylko zmienione części muszą zmienić swoje odniesienia. Na przykład, jeśli akcja spowoduje zmianę jednego elementu w tablicy, ten element i tablica będą musiały zostać skopiowane, jednak wszystkie inne elementy w tablicy zachowają swoją tożsamość. Ponieważ w większości przypadków akcje są bardzo ukierunkowane i wpływają na kilka kluczy stanu, a ponieważ Redux zachęca do normalizacji danych, aby struktury danych nie były głęboko zagnieżdżone, jest to o wiele mniej problem dla typowych aplikacji internetowych, niż można sobie wyobrazić.

Będziesz także chciał eksplorować za pomocą bibliotek takich jak Immutable.js, które skutecznie implementują niezmienne listy i mapy dzięki wewnętrznemu współużytkowaniu strukturalnemu. W ten sposób zmiana kilku pozycji na liście nie wymaga tak dużego kopiowania, ponieważ wewnętrznie większość pamięci jest dzielona między różne wersje struktury danych.

Ale w końcu jedynym sposobem, aby powiedzieć, jest napisanie testów warunków skrajnych, które ściśle naśladują zamierzone użycie aplikacji i zmierzą wydajność dla siebie.