Bir kullanıcı bir web sitesini veya uygulamayı ilk kez yüklediğinde, genellikle kullanıcı arayüzünü oluşturmak için kullanılan ilk uygulama durumunu oluşturmakla ilgili makul miktarda iş vardır. Örneğin, bazen uygulamanın, sayfada görüntülemek için ihtiyaç duyduğu tüm verilere sahip olmadan önce kullanıcının istemci tarafında kimliğini doğrulaması ve ardından birkaç API isteğinde bulunması gerekir.
Uygulama durumunun saklanması IndexedDB tekrarlanan ziyaretler için yükleme süresini hızlandırmanın harika bir yolu olabilir. Uygulama daha sonra arka planda herhangi bir API hizmetiyle senkronize olabilir ve kullanıcı arayüzünü yeni verilerle yavaş yavaş güncelleyebilir. bayat-while- yeniden doğrulama strateji.
IndexedDB’nin bir başka iyi kullanımı da, kullanıcı tarafından oluşturulan içeriği, sunucuya yüklenmeden önce geçici bir depo olarak veya uzak verilerin istemci tarafı önbelleği olarak veya elbette her ikisi olarak depolamaktır.
Ancak IndexedDB kullanırken, API’lerde yeni olan geliştiriciler için hemen fark edilmeyebilecek birçok önemli nokta vardır. Bu makale sık sorulan soruları yanıtlar ve IndexedDB’de verileri kalıcı hale getirirken akılda tutulması gereken en önemli şeylerden bazılarını tartışır.
Uygulamanızı öngörülebilir tutma #
IndexedDB ile ilgili birçok karmaşıklık, sizin (geliştiricinin) üzerinde kontrol sahibi olmadığınız pek çok faktör olduğu gerçeğinden kaynaklanmaktadır. Bu bölüm, IndexedDB ile çalışırken aklınızda bulundurmanız gereken konuların çoğunu incelemektedir.
Her şey, tüm platformlarda IndexedDB’de saklanamaz. #
Görüntüler veya videolar gibi kullanıcı tarafından oluşturulan büyük dosyaları saklıyorsanız, bunları şu şekilde saklamayı deneyebilirsiniz: File veya Blob nesneler. Bu, bazı platformlarda çalışır, ancak diğerlerinde başarısız olur. Özellikle iOS’ta Safari depolayamaz BlobIndexedDB’de.
Neyse ki dönüştürmek çok zor değil Blob Içine ArrayBufferve tersi. depolama ArrayBufferIndexedDB’deki s çok iyi desteklenir.
Ancak unutmayın ki bir Blob bir MIME türüne sahipken bir ArrayBuffer değil. Dönüştürmeyi doğru şekilde yapmak için türü arabellek yanında saklamanız gerekir.
dönüştürmek için ArrayBuffer bir Blob basitçe kullanırsın Blob yapıcı
function arrayBufferToBlob(buffer, type) {
return new Blob([buffer], { type: type });
}
Diğer yön biraz daha karmaşıktır ve eşzamansız bir süreçtir. kullanabilirsiniz FileReader Blobu şu şekilde okumak için nesne ArrayBuffer. Okuma bittiğinde bir loadend olay okuyucuda tetiklenir. Bu işlemi bir Promise şöyle:
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);
});
}
Depolamaya yazma başarısız olabilir #
IndexedDB’ye yazarken çeşitli nedenlerle hatalar meydana gelebilir ve bazı durumlarda bu nedenler geliştirici olarak sizin kontrolünüz dışındadır. Örneğin, bazı tarayıcılar şu anda izin vermiyor gizli tarama modundayken IndexedDB’ye yazma. Ayrıca, bir kullanıcının neredeyse boş disk alanı olan bir cihazda olması ve tarayıcının herhangi bir şey depolamanızı kısıtlaması olasılığı da vardır.
Bu nedenle, IndexedDB kodunuzda her zaman doğru hata işleme uygulamanız çok önemlidir. Bu ayrıca, uygulama durumunu bellekte tutmanın (depolamaya ek olarak) genellikle iyi bir fikir olduğu anlamına gelir; bu nedenle, özel tarama modunda çalışırken veya depolama alanı mevcut olmadığında (diğerlerinin bir kısmı olsa bile) kullanıcı arabirimi bozulmaz. depolama gerektiren uygulama özellikleri çalışmaz).
İçin bir olay işleyici ekleyerek IndexedDB işlemlerindeki hataları yakalayabilirsiniz. error bir etkinlik oluşturduğunuzda IDBDatabase, IDBTransaction veya IDBRequest nesne.
const request = db.open('example-db', 1);
request.addEventListener('error', (event) => {
console.log('Request error:', request.error);
};
Depolanan veriler kullanıcı tarafından değiştirilmiş veya silinmiş olabilir #
Yetkisiz erişimi kısıtlayabileceğiniz sunucu tarafı veritabanlarının aksine, istemci tarafı veritabanlarına tarayıcı uzantıları ve geliştirici araçları tarafından erişilebilir ve bunlar kullanıcı tarafından temizlenebilir.
Kullanıcıların yerel olarak depolanan verilerini değiştirmesi alışılmadık bir durum olsa da, kullanıcıların bu verileri temizlemesi oldukça yaygındır. Uygulamanızın bu iki durumu da hata vermeden halledebilmesi önemlidir.
Saklanan veriler eski olabilir #
Önceki bölüme benzer şekilde, kullanıcı verileri kendisi değiştirmemiş olsa bile, depoladıkları veriler kodunuzun eski bir sürümü tarafından, muhtemelen içinde hatalar olan bir sürüm tarafından yazılmış olabilir.
IndexedDB, şema sürümleri için yerleşik desteğe sahiptir ve IDBOpenDBRequest.onupgradeneeded() yöntem; ancak yine de yükseltme kodunuzu önceki bir sürümden (hatalı bir sürüm dahil) gelen kullanıcıyı işleyebilecek şekilde yazmanız gerekir.
Tüm olası yükseltme yollarını ve durumlarını manuel olarak test etmek genellikle mümkün olmadığından, birim testleri burada çok yardımcı olabilir.
Uygulamanızın performansını koruma #
IndexedDB’nin en önemli özelliklerinden biri, eşzamansız API’sidir, ancak bunun, onu kullanırken performans konusunda endişelenmenize gerek olmadığını düşünmenize izin vermeyin. Yanlış kullanımın ana ileti dizisini engellemeye devam edebileceği, bu da sarsıntıya ve yanıt vermemeye yol açabilecek bazı durumlar vardır.
Genel bir kural olarak, IndexedDB’ye okuma ve yazma işlemleri, erişilmekte olan veriler için gerekenden daha büyük olmamalıdır.
IndexedDB, büyük, iç içe geçmiş nesneleri tek bir kayıt olarak depolamayı mümkün kılsa da (ve bunu yapmak geliştirici açısından oldukça uygundur), bu uygulamadan kaçınılmalıdır. Bunun nedeni, IndexedDB bir nesneyi sakladığında, önce bir nesne oluşturması gerektiğidir. yapılandırılmış klon o nesnenin ve yapılandırılmış klonlama işlemi ana iş parçacığında gerçekleşir. Nesne ne kadar büyük olursa, engelleme süresi o kadar uzun olacaktır.
Popüler durum yönetimi kitaplıklarının çoğu (örneğin, Redux) tüm durum ağacınızı tek bir JavaScript nesnesi olarak yöneterek çalışır.
Durumu bu şekilde yönetmenin pek çok faydası olsa da (örneğin, kodunuzun üzerinde akıl yürütmeyi ve hata ayıklamayı kolaylaştırır) ve basitçe tüm durum ağacını IndexedDB’de tek bir kayıt olarak depolamak cazip ve uygun olabilirken, bunu her değişiklikten sonra yapmak (hatta kısılırsa/geri dönerse) ana ileti dizisinin gereksiz yere engellenmesine neden olur, yazma hatası olasılığını artırır ve hatta bazı durumlarda tarayıcı sekmesinin çökmesine veya yanıt vermemesine neden olur.
Tüm durum ağacını tek bir kayıtta depolamak yerine, onu ayrı kayıtlara ayırmalı ve yalnızca gerçekten değişen kayıtları güncellemelisiniz.
Görüntüler, müzik veya video gibi büyük öğeleri IndexedDB’de saklıyorsanız da aynı şey geçerlidir. Her öğeyi daha büyük bir nesne yerine kendi anahtarıyla depolayın, böylece ikili dosyayı da alma maliyetini ödemeden yapılandırılmış verileri alabilirsiniz.
Çoğu en iyi uygulamada olduğu gibi, bu bir ya hep ya hiç kuralı değildir. Bir durum nesnesini parçalamanın ve yalnızca minimum değişiklik kümesini yazmanın mümkün olmadığı durumlarda, verileri alt ağaçlara bölmek ve yalnızca bunları yazmak, her zaman tüm durum ağacını yazmaktansa tercih edilir. Küçük iyileştirmeler, hiç iyileştirme olmamasından daha iyidir.
Son olarak, yazdığınız kodun performans etkisini her zaman ölçmelisiniz. IndexedDB’ye küçük yazma işlemlerinin büyük yazmalardan daha iyi performans göstereceği doğru olsa da, bu yalnızca uygulamanızın IndexedDB’ye yaptığı yazma işlemlerinin aslında ana iş parçacığını engelleyen ve kullanıcı deneyimini bozan uzun görevlere yol açması durumunda önemlidir. Ne için optimize ettiğinizi anlamanız için ölçmek önemlidir.
Sonuçlar #
Geliştiriciler, yalnızca oturumlar arasında durumu sürdürerek değil, aynı zamanda tekrarlanan ziyaretlerde ilk durumu yüklemek için gereken süreyi azaltarak uygulamalarının kullanıcı deneyimini iyileştirmek için IndexedDB gibi istemci depolama mekanizmalarından yararlanabilir.
IndexedDB’yi düzgün bir şekilde kullanmak, kullanıcı deneyimini önemli ölçüde artırabilirken, yanlış kullanmak veya hata durumlarını ele almamak, bozuk uygulamalara ve mutsuz kullanıcılara yol açabilir.
İstemci depolaması, kontrolünüz dışında pek çok faktör içerdiğinden, kodunuzun iyi test edilmiş olması ve hataları, başlangıçta gerçekleşmesi pek olası görünmeyenler bile doğru şekilde işlemesi çok önemlidir.