IndexedDB ve popüler durum yönetimi kitaplıkları arasında uygulama durumunu senkronize etmeyle ilgili en iyi uygulamaları öğrenin.
Bir kullanıcı bir web sitesini veya uygulamayı ilk kez yüklediğinde genellikle kullanıcı arayüzünü oluşturmak için kullanılacak ilk uygulama durumunu oluşturmalıdır. Örneğin, bazen uygulamanın kullanıcı istemci tarafında kimliğini doğrulaması ve ardından sayfada görüntülemesi gereken veriler yer alır.
Uygulama durumunu şurada depolama: IndexedDB, performansı hızlandırmak için harika bir yol yükleme süresini kısaltabilirsiniz. Daha sonra uygulama arka planda herhangi bir API hizmetiyle senkronize edilebilir ve kullanıcı arayüzünü yeni verilerle gecikmeli olarak güncellemek, stale-when-re reValidate stratejisini kontrol edin.
IndexedDB'nin bir diğer iyi kullanım alanı da kullanıcı tarafından oluşturulan içeriği ya geçici bir mağaza olarak ya da önce sunucuya yüklenmeden veya uzak verilerin istemci tarafı önbelleği olarak (ya da tabii ki her ikisini de) destekler.
Bununla birlikte, IndexedDB'yi kullanırken göz önünde bulundurulması gereken bunu API’lerde yeni geliştiricilerin hemen fark etmesini sağlar. Bu makalede, sık sorulan soruların yanıtları ve .
Uygulamanızı tahmin edilebilir tutma
IndexedDB ile ilgili karmaşık durumların çoğunun nedeni, her bir müşterinin göz önünde bulundurması üzerinde herhangi bir denetimi yoktur. Bu bölümde aklınızda bulundurmanız gereken birçok sorun ile nasıl başlayabileceğinizi göstereceğim.
Her şey, tüm platformlarda IndexedDB'de depolanamaz
Kullanıcılar tarafından oluşturulan resim veya video gibi büyük boyutlu dosyalar depoluyorsanız
File veya Blob nesneleri olarak kabul edersiniz. Bu, bazı platformlarda işe yarar ancak bazılarında başarısız olur. Safari açık
Özellikle iOS, IndexedDB'de Blob depolayamaz.
Neyse ki Blob öğesini ArrayBuffer değerine (veya tam tersi) dönüştürmek çok zor değildir. Depolama
IndexedDB'deki ArrayBuffer öğeleri çok iyi desteklenmektedir.
Ancak, Blob MIME türüne sahipken ArrayBuffer türünün olmadığını unutmayın. Yapmanız gerekenler
doğru şekilde yapmak için türü tamponun yanında depolamalıdır.
ArrayBuffer öğesini Blob biçimine dönüştürmek için Blob oluşturucuyu kullanmanız yeterlidir.
function arrayBufferToBlob(buffer, type) {
return new Blob([buffer], { type: type });
}
Diğer yön ise biraz daha karmaşıktır ve eşzamansız bir süreçtir. URL parametrelerinin Google tarafından nasıl ele alınmasını istediğinizi belirtmek için
FileReader nesnesi tarafından blob'u ArrayBuffer olarak okuyacak. Okuma tamamlandığında loadend
etkinliği okuyucuda tetiklenir. Bu işlemi Promise içinde şu şekilde sarmalayabilirsiniz:
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);
});
}
Depolama alanına yazma işlemi başarısız olabilir
IndexedDB'ye yazarken hatalar çeşitli nedenlerle ortaya çıkabilir ve bazı durumlarda bu hatalar geliştirici olarak sizin kontrolünüz dışındadır. Örneğin, bazı tarayıcılar şu anda gizli tarama modundayken IndexedDB'ye yazma. Ayrıca, kullanıcının disk alanı bitmek üzere olan bir cihazda olma ihtimali de vardır. hiçbir şeyi saklamanızı kısıtlar.
Bu nedenle, IndexedDB kodu. Bu aynı zamanda uygulama durumunu bellekte tutmak iyi bir fikir olduğu anlamına gelir. (ör. saklamaya ek olarak) gizli tarama modunda çalışırken veya depolama alanı kullanılamaz (depolama alanı gerektiren diğer uygulama özelliklerinden bazıları iş) ekleyebilirsiniz.
error etkinliği için bir etkinlik işleyici ekleyerek IndexedDB işlemlerinde hataları yakalayabilirsiniz
her IDBDatabase, IDBTransaction veya IDBRequest nesnesi oluşturduğunuzda.
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ından farklı olarak, istemci tarafı veritabanları tarayıcı uzantıları ve geliştirici araçları tarafından erişilebilir ve kullanıcı tarafından silinebilir.
Kullanıcılar, yerel olarak depolanan verilerinde değişiklik yapmıyor olabilirler. Ancak bu, kullanıcılar için oldukça yaygın bir durumdur. tıklayın. Uygulamanızın bu durumların her ikisini de hata vermeden halledebilmesi önemlidir.
Depolanan veriler güncel olmayabilir
Önceki bölüme benzer şekilde, kullanıcı verileri değiştirmemiş olsa bile depoladıkları veriler kodunuzun eski bir sürümü tarafından yazılmış olabilir. sürümünü indirin.
IndexedDB, şema sürümleri için yerleşik desteğe sahiptir ve
IDBOpenDBRequest.onupgradeneeded()
yöntemini kullanarak Ancak yine de yükseltme kodunuzu, kullanıcının işine yarayacak şekilde yazmanız gerekir.
(hata içeren sürümler dahil).
Ünite testleri, mümkün olan tüm seçenekleri manuel olarak test etmek çoğu zaman uygun olmadığından burada çok faydalı olabilir. yeni sürüme geçiş yolları ve durumlar.
Uygulamanızın performansını koruma
IndexedDB'nin en önemli özelliklerinden biri, eşzamansız API'sidir ancak bunun sizi kandırmasına izin vermeyin. performansı konusunda endişelenmeniz gerekmediğini düşünüyorum. Bir dizi durum vardır: hatalı kullanım, ana iş parçacığını yine de engelleyebilir. Bu durum, olumsuzluklara ve yanıt vermemeye neden olabilir.
Genel bir kural olarak, IndexedDB'ye yapılan okuma ve yazma işlemleri veriler için gerekenden büyük olmamalıdır emin olun.
IndexedDB, iç içe yerleştirilmiş büyük nesnelerin tek bir kayıt olarak depolanmasını mümkün olsa da geliştirici açısından oldukça kullanışlı olduğu kabul edilir.) bu uygulamadan kaçınılmalıdır. İlgili içeriği oluşturmak için kullanılan Bunun nedeni, IndexedDB bir nesneyi depolarken önce bir yapılandırılmış klon ve yapılandırılmış klonlama süreci ana iş parçacığında gerçekleşir. Sayfa ne kadar büyükse engelleme süresi o kadar uzun olur.
Bu durum, uygulama durumunun IndexedDB'de nasıl tutulacağının planlanmasında bazı zorlukları beraberinde getirmektedir. popüler eyalet yönetimi kitaplıklarının (Redux gibi) bir kısmını tüm durum ağacını tek bir JavaScript nesnesi olarak ayarlar.
Durumu bu şekilde yönetmenin pek çok avantajı olsa da (ör. kodunuzda akıl yürütmeyi ve hata ayıklama) kullanır ve sadece tüm durum ağacını IndexedDB'de tek bir kayıt olarak depolarken, cazip ve kullanışlı olsa da, her değişiklikten sonra bunu yapmak (kısıtlanmış veya azaltılmış olsa bile) ana iş parçacığının gereksiz şekilde engellenmesi, yazma hatalarının olasılığını artırır ve bazı durumlarda tarayıcı sekmesinin kilitlenmesine veya yanıt vermemesine bile neden olabilir.
Durum ağacının tamamını tek bir kayıtta saklamak yerine ayrı ayrı bölümlere ayırmanız gerekir. yalnızca gerçekten değişen kayıtları güncelleyin.
Resim, müzik veya video gibi büyük öğeleri IndexedDB'de depoluyorsanız aynı durum geçerlidir. Her öğeyi depolayın büyük bir nesnenin içinde değil kendi anahtarı ile yapılır. Böylece yapılandırılmış verileri alabilirsiniz. İkili dosya alma maliyetini ödemez.
Çoğu en iyi uygulamada olduğu gibi, bu da ya hep ya hiç ya da hiç kuralı değildir. Mevcut olmayan durumlarda bir durum nesnesini parçalara ayırın ve yalnızca minimum değişiklik kümesini yazarak verileri alt ağaçlara bölün ve yalnızca bunları yazmak, her zaman eyalet ağacının tamamını yazmak yerine yine de tercih edilir. Çok az hiçbir iyileştirme yapılmamasından iyidir.
Son olarak, kampanyalarınızın performansa etkisini her zaman ölçmeniz bir kod snippet'i ekleyin. IndexedDB'ye yapılan küçük yazma işlemlerinin büyük çaplı yazmalardan daha iyi performans göstereceği doğru olsa da yazıyorsa bu yalnızca, uygulamanızın IndexedDB'ye yazması gerçekten uzun görevler ana ileti dizisini engelleyen ve kullanıcı deneyimini kötüleyen reklamlar içerir. Bir iş kırılım yapısı oluşturmak neden optimizasyon yaptığınızı anlayabilirsiniz.
Sonuçlar
Geliştiriciler, IndexedDB gibi istemci depolama mekanizmalarını kullanarak en iyi uygulamaların kullanıcı deneyimini iyileştirebilirler oturumlarda durumu devam ettirmekle kalmayıp, uygulama için harcanan süreyi kısaltarak da tekrar eden ziyaretlerde ilk durumu yükler.
IndexedDB'nin doğru şekilde kullanılması kullanıcı deneyimini önemli ölçüde iyileştirebilir ancak yanlış kullanmak veya hatalarla başa çıkmakta başarısız olmak, uygulamaların bozulmasına ve kullanıcıların mutsuz olmasına yol açabilir.
İstemci depolama alanı sizin kontrolünüz dışında birçok faktörü içerdiğinden, kodunuzun gerektiği gibi ilk başta gerçekleşmeyecek gibi görünseler bile bu hataları test edip gerektiği gibi ele alır.