IndexedDB ile popüler durum yönetimi kitaplıkları arasında uygulama durumunu senkronize etmeyle ilgili en iyi uygulamaları öğrenin.
Kullanıcı bir web sitesini veya uygulamayı ilk kez yüklediğinde, kullanıcı arayüzünü oluşturmak için kullanılan ilk uygulama durumunu oluşturmak genellikle oldukça fazla çalışma gerektirir. Örneğin, bazen uygulamanın kullanıcıyı istemci tarafında kimlik doğrulaması ve ardından sayfada göstermesi gereken tüm verilere sahip olmadan önce birkaç API isteği göndermesi gerekir.
Uygulama durumunu IndexedDB'de depolamak, tekrar eden ziyaretlerde yükleme süresini hızlandırmanın harika bir yolu olabilir. Uygulama daha sonra arka planda herhangi bir API hizmetiyle senkronize olabilir ve stale-while-revalidate stratejisi kullanarak kullanıcı arayüzünü yeni verilerle güncelleyebilir.
Ancak IndexedDB'yi kullanırken, API'leri yeni kullanmaya başlayan geliştiriciler için hemen anlaşılmayabilecek birçok önemli noktayı göz önünde bulundurmak gerekir. Bu dokümanda, sık sorulan sorular yanıtlanmakta ve uygulama durumunu IndexedDB'de kalıcı hale getirirken göz önünde bulundurulması gereken en önemli noktalardan bazıları ele alınmaktadır.
Uygulamanızın öngörülebilir olmasını sağlayın
IndexedDB ile ilgili karmaşıklıkların çoğu, sizin (geliştirici) kontrolünüzde olmayan çok sayıda faktörden kaynaklanır. Bu bölümde, IndexedDB ile çalışırken göz önünde bulundurmanız gereken birçok sorun ele alınmaktadır.
Depolama alanına yazma işlemi başarısız olabilir
IndexedDB'ye yazma sırasında çeşitli nedenlerle hatalar oluşabilir ve bazı durumlarda bu nedenler geliştirici olarak sizin kontrolünüz dışındadır. Örneğin, bazı tarayıcılar gizli tarama modundayken IndexedDB'ye yazmaya izin vermez. Kullanıcının disk alanı neredeyse tükenmiş bir cihazda olması ve tarayıcının herhangi bir şey depolamanızı kısıtlaması da mümkündür.
Bu nedenle, IndexedDB kodunuzda her zaman doğru hata işleme yöntemini uygulamanız çok önemlidir. Bu aynı zamanda, uygulama durumunu bellekte tutmanın (depolamanın yanı sıra) genellikle iyi bir fikir olduğu anlamına gelir. Böylece, gizli tarama modunda çalışırken veya depolama alanı olmadığında kullanıcı arayüzü bozulmaz (depolama alanı gerektiren diğer uygulama özelliklerinden bazıları çalışmasa bile).
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ı erişebilir ve kullanıcı tarafından temizlenebilir.
Kullanıcıların yerel olarak depolanan verilerini değiştirmesi nadir görülen bir durum olsa da bu verileri temizlemeleri oldukça yaygındır. Uygulamanızın bu iki durumu da hata vermeden işleyebilmesi önemlidir.
Depolanan veriler güncel olmayabilir.
Önceki bölümde olduğu gibi, kullanıcı verileri kendisi değiştirmemiş olsa bile depolama alanındaki veriler kodunuzun önceki bir sürümü (muhtemelen hatalı bir sürüm) tarafından yazılmış olabilir.
IndexedDB, şema sürümleri ve IDBOpenDBRequest.onupgradeneeded() yöntemini kullanarak yükseltme için yerleşik desteğe sahiptir. Ancak 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 senaryolarını manuel olarak test etmek genellikle mümkün olmadığından birim testleri bu noktada çok faydalı olabilir.
Uygulamanızın performansını koruma
IndexedDB'nin temel özelliklerinden biri eşzamansız API'sidir ancak bu durum, IndexedDB'yi kullanırken performans konusunda endişelenmenize gerek olmadığı anlamına gelmez. Yanlış kullanımın ana iş parçacığını engelleyebileceği ve yanıt vermemeye yol açabileceği birçok durum vardır.
Genel bir kural olarak, IndexedDB'ye okuma ve yazma işlemleri, erişilen veriler için gerekenden daha büyük olmamalıdır.
IndexedDB, büyük ve iç içe yerleştirilmiş nesneleri tek bir kayıt olarak depolamayı mümkün kılsa da (ve geliştirici açısından oldukça kullanışlı olsa da) bu uygulamadan kaçınılmalıdır. Bunun nedeni, IndexedDB bir nesneyi depolarken önce o nesnenin yapılandırılmış bir klonunu oluşturması ve yapılandırılmış klonlama işleminin ana iş parçacığında gerçekleşmesidir. Nesne ne kadar büyükse engelleme süresi de o kadar uzun olur.
Redux gibi popüler durum yönetimi kitaplıklarının çoğu, tüm durum ağacınızı tek bir JavaScript nesnesi olarak yöneterek çalıştığından, uygulama durumunun IndexedDB'de nasıl kalıcı hale getirileceğini planlarken bazı zorluklar ortaya çıkar.
Durumu bu şekilde yönetmenin birçok avantajı olsa da ve tüm durum ağacını IndexedDB'de tek bir kayıt olarak depolamak cazip ve kullanışlı olsa da her değişiklikten sonra bunu yapmak (kısıtlanmış/gecikmeli olsa bile) ana iş parçacığının gereksiz yere engellenmesine neden olur, yazma hataları olasılığını artırır ve hatta bazı durumlarda tarayıcı sekmesinin kilitlenmesine veya yanıt vermemesine neden olur.
Tüm durum ağacını tek bir kayıtta depolamak yerine, ağacı ayrı kayıtlara bölmeli ve yalnızca değişen kayıtları güncellemelisiniz.
En iyi uygulamaların çoğunda olduğu gibi bu da "ya hep ya hiç" kuralı değildir. Bir durum nesnesini bölüp yalnızca minimum değişiklik grubunu yazmanın mümkün olmadığı durumlarda, verileri alt ağaçlara bölüp yalnızca bunları yazmak, her zaman tüm durum ağacını yazmaya tercih edilir. Küçük iyileştirmeler, hiç iyileştirme olmamasından daha iyidir.
Son olarak, yazdığınız kodun performans üzerindeki etkisini her zaman ölçmeniz gerekir. IndexedDB'ye yapılan küçük yazma işlemlerinin büyük yazma işlemlerinden daha iyi performans göstereceği doğru olsa da bu durum yalnızca uygulamanızın IndexedDB'ye yaptığı yazma işlemleri ana iş parçacığını engelleyen ve kullanıcı deneyimini olumsuz etkileyen uzun süren görevlere yol açıyorsa önemlidir. Neyi optimize ettiğinizi anlamak için ölçüm yapmak önemlidir.
Sonuçlar
Geliştiriciler, IndexedDB gibi istemci depolama mekanizmalarını kullanarak uygulamalarının kullanıcı deneyimini iyileştirebilir. Bu sayede, hem oturumlar arasında durumu koruyabilir hem de tekrar ziyaretlerde ilk durumun yüklenme süresini kısaltabilirler.
IndexedDB'nin doğru kullanımı kullanıcı deneyimini önemli ölçüde iyileştirebilirken, yanlış kullanımı veya hata durumlarının ele alınmaması, uygulamaların bozulmasına ve kullanıcıların mutsuz olmasına neden olabilir.
İstemci depolama alanı, kontrolünüz dışında birçok faktör içerdiğinden kodunuzun iyi test edilmesi ve başlangıçta gerçekleşmesi olası görünmeyen hatalar da dahil olmak üzere hataları doğru şekilde işlemesi çok önemlidir.