Przechowywanie słowników w localStorage na podstawie np. Angulara

Witam, mam krótkie pytanie odnośnie localStorage/sessionStorage. Ostatnio zastanawiałem się czy nie warto zapisywać ściąganych słowników właśnie do wspomnianego localStorage? Pobieramy raz i potem już wszystko śmiga na sparsowanych JSON'ach. Nie wiem jak to wychodzi wydajnościowo, ale wiadomo, że i tak lepiej niż ściąganie słowników za każdym razem.

Pytanie jednak czy jest to dobra praktyka? Wcześniej spotkałem się z mniejszymi danymi, które przechowujemy, ale co w przypadku dużych tablic/obiektów? Może jednak lepiej używać *cache *w interceptorze, albo za pomocą Observable.of w danym requescie HTTP?

Pytanie ogólne, aczkolwiek przykłady podaję na podstawie Angulara bo mi najbliżej do niego.

Kondziowsky napisał(a):

Witam, mam krótkie pytanie odnośnie localStorage/sessionStorage. Ostatnio zastanawiałem się czy nie warto zapisywać ściąganych słowników właśnie do wspomnianego localStorage? Pobieramy raz i potem już wszystko śmiga na sparsowanych JSON'ach. Nie wiem jak to wychodzi wydajnościowo, ale wiadomo, że i tak lepiej niż ściąganie słowników za każdym razem.

Pytanie jednak czy jest to dobra praktyka? Wcześniej spotkałem się z mniejszymi danymi, które przechowujemy, ale co w przypadku dużych tablic/obiektów? Może jednak lepiej używać *cache *w interceptorze, albo za pomocą Observable.of w danym requescie HTTP?

Pytanie ogólne, aczkolwiek przykłady podaję na podstawie Angulara bo mi najbliżej do niego.

No na pewno lepiej coś przechować w pamięci niż ściągać za każdym razem. Niestety, localStorage przechowuje dane jako stringi. Więc parsowanie dalej cie nie ominie. Ale jest kilka rzeczy na które trzeba zwrócić uwagę.

1. Rozmiar - nie mam pojęcia jak wielkie są te twoje słowniki, ale właściwie bezpiecznie można w localStorage chować coś co ma po kilka megabajtów, większych rzeczy nie pomieści.
2. Aktualizacja - a co kiedy uaktualnisz któryś ze słowników? Trzeba będzie wywalić to co jest aktualnie w pamięci i zastąpić nowym. Jak dasz znać skryptowi kiedy ma to zrobić? Oczywiście to jest do zrobienia, ale nie takie proste jak się wydaje.
3. Przeglądarki są dobre w cachowaniu tego co dostają z sieci. Może po prostu lepiej ustawić cache header na tych swoich słownikach i pozwolić przeglądarce je przechować? Mniej skomplikowane, a działa równie dobrze. Oczywiście również trzeba dać znać przeglądarce kiedy ma coś uaktualnić. Ale na to są sprawdzone sposoby - np. zmiana nazwy pliku za każdym razem gdy coś zmieniasz (asset revisioning, są skrypty do tego).
4. Kiedy nie za bardzo ufasz cache przeglądarki, możesz też ten słownik samodzielnie umieścić w cache za pomocą service workerów. Działa to w zasadzie w każdej z rozwijanej przeglądarek. Trochę łatwiej jest to kontrolować (według mnie) niż za pomocą localStorage. Prościej uaktualniać i pobierać np. w przypadku gdy nie znajdzie niczego w cache. No i rozmiar tego cache jest większy. A do tego możesz bardzo łatwo sprawić by cała strona działała offline.
5. Angular czy react czy vue czy vanillajs. To akurat nie ma żadnego znaczenia dla tego problemu.

Tak na szybko dwie rzeczy mi przyszły do głowy:

1. nie podałeś rozmiaru takich słowników
2. słowniki na serwerze mogą się zmieniać. W związku z tym (zależy od tego, jak długo planujesz je trzymać - czy tylko podczas aktywnej sesji, czy przez dłuższy czas) musisz pomyśleć o pilnowaniu, żeby trzymana lokalnie wersja była zgodna z tym, co jest na serwerze. Bo inaczej może dojść do sytuacji, w której użytkownik zalogowany już jakiś czas będzie miał inne dane od kogoś, kto się zaloguje na świeżo.

Widzę, że jest zgodność :P faktycznie przeoczyłem przede wszystkim aktualizację takich słowników - to byłby trochę problem. Ogólnie pytam, bo testuję kilka rozwiązań dla przechowywania słowników, teraz widzę na co kompletnie nie zwróciłem uwagi :D Co do rozmiaru, to nie znam go w MB, aczkolwiek nie są to ogromne słowniki molochy - bardziej problem w tym, że może być ich 8-10 po dosłownie przejściu podstawowej ścieżki apki.

@m31 chyba nie zrozumiałem dokładnie punktu 3 :P aczkolwiek na pewno sprawdzę punkt 4 i zobaczę "live" jak to zadziała.

Jest jeszcze kwestia faktycznie przepuścić to przez HTTP interceptor (może dziś potestuję), ale także muszę w jakiś sposób sprawdzić aktualność i chyba z tym będzie największa zabawa.