Sprawdzone metody korzystania z IndexedDB

Poznaj sprawdzone metody synchronizowania stanu aplikacji między IndexedDB popularnymi bibliotekami zarządzania stanami.

Philip Walton

Gdy użytkownik po raz pierwszy wczytuje witrynę lub aplikację, często wiąże się to z dużą ilością pracy tworząc początkowy stan aplikacji używany do renderowania interfejsu użytkownika. Na przykład czasami Aplikacja musi uwierzytelnić się po stronie klienta, a następnie wysłać kilka żądań do interfejsu API, zanim wszystko dane, jakie musi wyświetlić na stronie.

Przechowywanie stanu aplikacji w Interfejs IndexedDB może znacznie przyspieszyć czas wczytywania kolejnych wizyt. Aplikacja może wtedy synchronizować się z dowolnymi usługami interfejsu API w tle. i leniwie aktualizuje interfejs, dodając do niego nowe dane, nieaktualnych w czasie-ponownej weryfikacji.

Kolejnym dobrym zastosowaniem IndexedDB jest przechowywanie treści użytkowników jako magazyn tymczasowy przed przesłaniem na serwer lub jako pamięć podręczna po stronie klienta – albo, oczywiście, na oba te sposoby.

Podczas korzystania z IndexedDB należy jednak pamiętać o wielu ważnych kwestiach, które mogą nie być jest to oczywiste dla programistów, którzy dopiero zaczynają korzystać z interfejsów API. W tym artykule znajdziesz odpowiedzi na najczęstsze pytania. omawia najważniejsze kwestie, o których należy pamiętać w przypadku zachowywania danych w IndexedDB.

Zapewnienie przewidywalności aplikacji

Wiele zawiłości związanych z IndexedDB wynika z wielu czynników, (deweloper) nie ma nad nimi kontroli. W tej sekcji omawiamy wiele kwestii, o których należy pamiętać podczas pracy z bazą IndexedDB.

Nie wszystko można przechowywać w IndexedDB na wszystkich platformach

Jeśli przechowujesz duże, generowane przez użytkowników pliki, np. obrazy lub filmy, możesz spróbować zapisać je jako obiekty File lub Blob. Na niektórych platformach ta funkcja działa, ale na innych nie działa. Safari włączona Zwłaszcza w systemie iOS nie można zapisywać elementów Blob w IndexedDB.

Na szczęście przekonwertowanie pola Blob na ArrayBuffer i odwrotnie nie jest zbyt trudne. Przechowywanie Obiekty ArrayBuffer w IndexedDB są bardzo dobrze obsługiwane.

Pamiętaj jednak, że typ MIME Blob jest ograniczony, a ArrayBuffer – nie. Wykonaj zapisać typ w buforze, by przeprowadzić prawidłową konwersję.

Aby przekonwertować element ArrayBuffer na Blob, wystarczy użyć konstruktora Blob.

function arrayBufferToBlob(buffer, type) {
  return new Blob([buffer], { type: type });
}

Drugi kierunek jest nieco bardziej wymagający i jest procesem asynchronicznym. Za pomocą FileReader, aby odczytać obiekt blob jako ArrayBuffer. Po zakończeniu odczytu loadend na czytniku. Możesz zakończyć ten proces w Promise w następujący sposób:

function blobToArrayBuffer(blob) {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.addEventListener('loadend', () => {
      resolve(reader.result);
    });
    reader.addEventListener('error', reject);
    reader.readAsArrayBuffer(blob);
  });
}

Zapisywanie w pamięci może się nie udać

Błędy podczas zapisywania do IndexedDB mogą wystąpić z wielu powodów, a w niektórych przypadkach są poza Twoją kontrolą jako dewelopera. Na przykład niektóre przeglądarki obecnie nie zezwalają zapisu do IndexedDB w trybie przeglądania prywatnego. Istnieje też możliwość, że użytkownik korzysta z urządzenia, na którym kończy się miejsce na dysku. nie zezwala na zapisywanie żadnych danych.

Z tego powodu niezwykle ważne jest, aby zawsze wdrażać prawidłową obsługę błędów w plikach Kod IndexedDB. Oznacza to również, że dobrze jest zachować stan aplikacji w pamięci (w oprócz jej zapisania), dzięki czemu interfejs użytkownika nie będzie przestawał działać w trybie przeglądania prywatnego ani jest niedostępne (nawet jeśli niektóre inne funkcje aplikacji, które wymagają miejsca, praca).

Możesz wychwytywać błędy w operacjach IndexedDB, dodając moduł obsługi zdarzeń error za każdym razem, gdy utworzysz obiekt IDBDatabase, IDBTransaction lub IDBRequest.

const request = db.open('example-db', 1);
request.addEventListener('error', (event) => {
  console.log('Request error:', request.error);
};

Przechowywane dane mogły zostać zmodyfikowane lub usunięte przez użytkownika

W przeciwieństwie do baz danych po stronie serwera, do których można ograniczyć nieautoryzowany dostęp, bazy danych po stronie klienta są są dostępne dla rozszerzeń przeglądarki i narzędzi dla programistów, ale użytkownik może je usunąć.

Choć użytkownicy rzadko modyfikują swoje dane przechowywane lokalnie, w przypadku użytkowników aby ją usunąć. Ważne jest, aby aplikacja bez problemu poradziła sobie z obu tych przypadkach.

Zapisane dane mogą być nieaktualne

Podobnie jak w poprzedniej sekcji, nawet jeśli użytkownik sam nie zmodyfikował danych, dane przechowywane w pamięci zostały zapisane przez starszą wersję kodu, wersji z błędami.

IndexedDB ma wbudowaną obsługę wersji schematu i uaktualnia za pomocą IDBOpenDBRequest.onupgradeneeded() ; jednak nadal musisz napisać kod uaktualnienia w taki sposób, aby obsługiwał on pochodzące z poprzedniej wersji (w tym wersji z błędem).

Bardzo pomocne mogą być tu testy jednostkowe, ponieważ często nie ma możliwości ręcznego przetestowania wszystkich możliwych ścieżek konwersji i zgłoszeń.

Dbanie o wydajność aplikacji

Jedną z kluczowych funkcji IndexedDB jest asynchroniczny interfejs API, ale nie daj się zwieść. i nie trzeba się martwić o jej wydajność. Istnieje wiele przypadków, w których nieprawidłowe użycie może nadal blokować wątek główny, co może prowadzić do zacinania się i braku reakcji.

Ogólnie wartość liczby odczytów i zapisów w IndexedDB nie powinna przekraczać wymagana w przypadku tych danych na dostęp do danych.

IndexedDB umożliwia przechowywanie dużych, zagnieżdżonych obiektów jako pojedynczego rekordu jest dość wygodne z perspektywy programistów), należy tego uniknąć. dlatego, że gdy baza IndexedDB przechowuje obiekt, musi najpierw utworzyć klon strukturalny i ustrukturyzowany proces klonowania odbywa się w wątku głównym. Im większa tym dłuższy będzie czas blokowania.

Wiąże się to z pewnymi wyzwaniami przy planowaniu sposobu zachowywania stanu aplikacji w IndexedDB, bo większość z popularnych bibliotek zarządzania stanowego (takich jak Redux) działają, zarządzając całe drzewo stanu jako pojedynczy obiekt JavaScriptu.

Ten sposób zarządzania stanem przynosi wiele korzyści (np. ułatwia rozumowanie kodu debugowanie), a przechowywanie całego drzewa stanu jako pojedynczego rekordu w IndexedDB może jest kuszące i wygodne, ale rób to po każdej zmianie (nawet jeśli ruch jest ograniczony lub pozbawiony wartości). niepotrzebne blokowanie wątku głównego, zwiększa ryzyko błędów zapisu W niektórych przypadkach może nawet doprowadzić do awarii karty przeglądarki lub braku reakcji.

Zamiast przechowywać całe drzewo stanu w pojedynczym rekordzie, należy podzielić je na kilka osobnych rekordów i tylko te, które rzeczywiście się zmieniają.

To samo dotyczy zasobów IndexedDB, jeśli przechowujesz w indeksie IndexedDB duże elementy, takie jak obrazy, muzyka czy filmy. Przechowywanie każdego elementu z własnym kluczem, a nie wewnątrz większego obiektu. Dzięki temu można pobrać uporządkowane dane bezpłatnie pobierania pliku binarnego.

Podobnie jak w przypadku większości sprawdzonych metod, nie jest to zasada „wszystko albo nic”. W sytuacjach, gdy nie da się zrealizować podzielić obiekt stanu i zapisać minimalny zestaw zmian, dzieląc dane na mniejsze drzewa i dalej lepiej jest zapisywać całe drzewo stanu. Małe lepsze efekty niż w ogóle.

Pamiętaj też, aby zawsze mierzyć wpływ na skuteczność. w całym napisanym kodzie. Chociaż to prawda, małe zapisy w IndexedDB będą działać lepiej niż duże zapisy, ma to znaczenie tylko wtedy, gdy zapisy w IndexedDB przez aplikację faktycznie prowadzą do długie zadania które blokują wątek główny i pogarszają wrażenia użytkowników. Ważne jest, by mierzyć zrozumieć, pod kątem czego optymalizujesz kampanię.

Podsumowanie

Deweloperzy mogą wykorzystywać mechanizmy przechowywania danych klientów, takie jak IndexedDB, by poprawić wrażenia użytkowników ich zastosowanie przez zachowywanie stanu między sesjami, ale także przez skrócenie czasu by wczytać stan początkowy przy kolejnych wizytach.

Prawidłowe użycie bazy danych IndexedDB może znacząco poprawić wrażenia użytkowników, nieprawidłowe użycie brak obsługi zgłoszeń błędów może prowadzić do awarii aplikacji i niezadowolenia użytkowników.

Przechowywanie danych klienta zależy od wielu czynników, na które nie masz wpływu, dlatego ważne jest, aby kod i prawidłowo obsługuje błędy, nawet te, które na początku wydają się mało prawdopodobne.