IndexedDB ile 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, kullanıcı arayüzünü oluşturmak için kullanılan ilk uygulama durumunu oluşturmak genellikle oldukça fazla iş gerektirir. Örneğin, bazen uygulamanın, sayfada göstermesi gereken tüm verilere sahip olmadan önce kullanıcı tarafında kimlik doğrulaması yapması ve ardından birkaç API isteği göndermesi gerekir.
Uygulama durumunu IndexedDB'de depolamak, tekrar ziyaretlerin yüklenme süresini kısaltmanın mükemmel bir yolu olabilir. Uygulama, daha sonra arka plandaki API hizmetleriyle senkronize olup kullanıcı arayüzünü yeni verilerle gecikmeli olarak güncelleyebilir. Bunun için stale-when-reverification stratejisinden yararlanır.
Bununla birlikte, IndexedDB'yi kullanırken API'leri yeni kullanmaya başlayan geliştiricilerin göz önünde bulundurması gereken birçok önemli nokta vardır. Bu dokümanda, sık sorulan sorular yanıtlanmakta ve IndexedDB'de uygulama durumunu devam ettirirken 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şık durumların çoğunun kaynağı, sizin (geliştirici) kontrol edemediğiniz çok sayıda faktör olmasıdı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şlemleri başarısız olabilir
IndexedDB'ye yazarken hatalar çeşitli nedenlerle ortaya çıkabilir 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'e yazmaya izin vermez. Ayrıca, kullanıcının disk alanı bitmek üzere olan bir cihazda olma ihtimali de vardır. Bu durumda tarayıcı, herhangi bir şey depolamanızı kısıtlar.
Bu nedenle, IndexedDB kodunuzda her zaman doğru hata işlemeyi uygulamanız çok önemlidir. Bu, uygulama durumunu depolamaya ek olarak bellekte tutmak genellikle iyi bir fikirdir. Böylece, özel tarama modunda çalışırken veya depolama alanı mevcut olmadığında (depolama alanı gerektiren diğer uygulama özelliklerinden bazıları çalışmasa bile) kullanıcı arayüzü bozulmaz.
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 bu veritabanları kullanıcı tarafından temizlenebilir.
Kullanıcılar yerel olarak depolanan verileri nadiren değiştirse de bunları temizlemek oldukça yaygın bir durumdur. Uygulamanızın bu durumların ikisini de hata yapmadan işleyebilmesi önemlidir.
Depolanan veriler güncel olmayabilir
Önceki bölüme benzer şekilde, kullanıcı verileri değiştirmemiş olsa bile depolama alanındaki verilerin, kodunuzun önceki bir sürümü (muhtemelen hata içeren bir sürüm) tarafından yazılmış olması da mümkündür.
IndexedDB, IDBOpenDBRequest.onupgradeneeded() yöntemini kullanarak şema sürümleri ve yükseltme için yerleşik destek sunar. Ancak yine de yükseltme kodunuzu, önceki bir sürümden (hata içeren sürümler dahil) gelen kullanıcıları işleyebilecek şekilde yazmanız gerekir.
Olası tüm yükseltme yollarını ve durumlarını manuel olarak test etmek genellikle mümkün olmadığından birim testleri burada çok yararlı olabilir.
Uygulamanızın performansını koruyun
IndexedDB'nin en önemli özelliklerinden biri, eşzamansız API'sidir. Ancak bu API'yi kullanırken performans konusunda endişelenmeniz gerekmediğini düşünmenize neden olması sizi yanıltmasın. Yanlış kullanım, ana mesaj dizisini engellemeye devam edip yanıt vermeme durumuna yol açabilir.
Genel bir kural olarak, IndexedDB'de yapılan okuma ve yazma işlemleri, erişilen veriler için gerekenden daha büyük olmamalıdır.
IndexedDB, iç içe yerleştirilmiş büyük nesnelerin tek bir kayıt olarak depolanmasını mümkün kılsa da (bunun geliştirici açısından oldukça kullanışlı olduğu kabul edilir) ancak bu uygulamadan kaçınılmalıdır. Bunun nedeni, IndexedDB bir nesneyi depoladığında önce bu nesnenin yapılandırılmış bir kopyasını oluşturması ve yapılandırılmış kopyalama işleminin ana iş parçacığında gerçekleşmesidir. Nesne ne kadar büyük olursa engelleme süresi de o kadar uzun olur.
Popüler durum yönetimi kitaplıklarının (Redux gibi) çoğu, durum ağacınızın tamamını tek bir JavaScript nesnesi olarak yöneterek çalıştığından, bu durum, uygulama durumunun IndexedDB'de nasıl tutulacağını planlarken bazı zorluklara yol açar.
Durumu bu şekilde yönetmenin birçok avantajı vardır ve durum ağacının tamamını IndexedDB'de tek bir kayıt olarak depolamak cazip ve kullanışlı olabilir. Ancak her değişiklikten sonra bunu yapmak (düzenlemeler sınırlandırılmış/geciktirilmiş olsa bile), ana iş parçacığının gereksiz yere engellenmesine neden olur, yazma hatalarının olasılığını artırır ve bazı durumlarda tarayıcı sekmesinin kilitlenmesine veya yanıt vermemesine bile yol açar.
Durum ağacının tamamını tek bir kayıtta depolamak yerine, tek tek kayıtlara ayırmanız ve yalnızca gerçekten değişen kayıtları güncellemeniz gerekir.
Çoğu en iyi uygulamada olduğu gibi bu da "ya hep ya hiç" kuralı değildir. Bir durum nesnesini bölmenin ve yalnızca minimum değişiklik grubunu yazmanın mümkün olmadığı durumlarda, verileri alt ağaçlara bölmek ve yalnızca bunları yazmak, her zaman durum ağacının tamamını yazmaya tercih edilir. Küçük iyileştirmeler, hiç iyileştirme yapmamaktan iyidir.
Son olarak, yazdığınız kodun performans etkisini her zaman ölçüyor olmanız gerekir. IndexedDB'ye yapılan küçük yazma işlemlerinin büyük yazmalardan daha iyi performans göstereceği doğru olsa da bu durum yalnızca, uygulamanızın IndexedDB'ye yaptığı yazma işlemlerinin ana iş parçacığını engelleyen ve kullanıcı deneyiminin kalitesini düşüren uzun görevlere yol açması durumunda önemlidir. Ne için optimizasyon yaptığınızı anlamanız için ölçüm yapmak önemlidir.
Sonuçlar
Geliştiriciler, IndexedDB gibi istemci depolama mekanizmalarını kullanarak yalnızca oturumlar genelinde durumu koruyarak değil, aynı zamanda tekrarlanan ziyaretlerde ilk durumu yüklemek için gereken süreyi kısaltarak uygulamalarının kullanıcı deneyimini iyileştirebilirler.
IndexedDB'i doğru şekilde kullanmak kullanıcı deneyimini önemli ölçüde iyileştirebilir. Ancak yanlış kullanmak veya hata durumlarını ele alamamak, uygulamaların bozulmasına ve kullanıcıların memnuniyetsiz 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 pek olası görünmeyen hatalar da dahil olmak üzere hataları düzgün şekilde ele alması önemlidir.