[NiewzruszonaMasa]

Mam pytanie, pewnie laickie do speców z branży.
Chodzi mi o sposoby przechowywania danych po stronie klienta.
Chodzi o samego Jsa, bez framworka i ich state manadżerów, bez contex api / nic.

Przypuśćmy że mamy prostą aplikację Crud. może to być stoper + jakiś task manadżer / dodaj / modyfikuj / usuń . Relacje między takim stoperem a taskami ( czyli np notatkami ), jakieś zachodzą. Mogą np przyjmować klasy active, zliczać liczbę wykonanego tasku po skończeniu odliczania.

Wiadomo można użyć jakieś zmiennej state i przechowywać tam po operacjach dane. Zachowując relację i odzwierciedlenie STATE = > DOM.

Ale czy pracowanie na samym domie to zła praktyka ? Przypuśćmy że chcę to napisać bez statu, bez localStorage. A funkcjonalność jest na tyle prosta że dom mi na to pozwala.

W state np mógłbym przechowywać listę elementów i renderować sobie kolejny nr id na podstawie poprzednich ( wiedząc ile ich jest ze state ).

To samo mógłbym zrobić tworząc funkcję która będzie zliczać to wszystko bezpośrednio z doma.

Wiem że pytanie banalne, i wszystko zależy od skomplikowania i późniejszego rozwoju apki. Ale dla samego treningu przerobiłem kilka podejść. Wiadomo tych funkcji zwracających nodeList będzie sporo, mamy jeszcze data-attr.

#javascript #data

[lobo]

@NiewzruszonaMasa: Jakbyś to lepiej napisał bo niezbyt zrozumiałem o co ci chodzi
Czy interesuje ciebie
1. przechowanie danych do czasu przeładowania fizycznego strony
2. przechowanie danych do czasu aż okno w przeglądarce zostanie zamknięte
3. przechowanie danych do czasu fizycznego i skasowania przez użytkownika

1. Możesz rozwiązać na dziesiątki sposobów i każdy ma swoje plusy/minusy zależnie od potrzeb tu kilka powszechnych
1.1 trzymanie danych w obiekcie który jest dostępny dla wszystkich

[zackson]

@NiewzruszonaMasa: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Client-side_storage

[NiewzruszonaMasa]

@zackson: czytałem właśnie ten link. Myślałem że coś pominąłem. Najwidocznie muszę się wziąć za Reacta/Reduxa, bo przy sporej apce się taki syf robi w utrzymaniu że kosmos. Sensowny model i najbardziej czytalny to mvc + state w modelu i trzymanie wszystkiego w osobnych widokach. Mówię tu z perspektywy amatora. Jak czytam to React/Redux wszystkie powstałe problemy by mi rozwiązał.

[anghelus]

@NiewzruszonaMasa: nie musisz od razu zaprzęgać Reduxa. Jeśli zmiany nie są częste i nie potrzebujesz super optymalizacji (ograniczenia rerenderów) to zwykły Context Reactowy wystarczy. Zamiast Contextu możesz też użyć np. Zustanda. Bardzo fajny w użyciu global state manager.

Jednak jeśli zależy Ci na reduxie to zerknij na redux toolikit. Lepiej się pracuje i mniej boilerplatu. Nie zaleca się już stosowania starego reduxa a tego typu materiałów jest najwięcej w sieci.