Uygulama durumunu IndexedDB ile popüler durum yönetimi kitaplıkları arasında 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ının kimliğini istemci tarafında doğrulaması ve ardından birkaç API isteği yapması gerekir.
Uygulama durumunu IndexedDB'de depolamak, tekrar ziyaretlerin yüklenme süresini kısaltmanın mükemmel bir yolu olabilir. Ardından uygulama, arka planda API hizmetleriyle senkronize olabilir ve güncel olmayan verileri yeniden doğrulama stratejisini kullanarak kullanıcı arayüzünü yeni verilerle yavaşça güncelleyebilir.
Ancak IndexedDB kullanılırken, API'lere yeni başlayan geliştiriciler tarafından hemen fark edilmeyebilecek 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şıklıkların çoğu, geliştirici olarak kontrolünüz dışında birçok faktörün olmasından 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şlemleri başarısız olabilir
IndexedDB'e yazma sırasında çeşitli nedenlerle hata oluşabilir. Bu nedenlerin bazıları geliştirici olarak kontrolünüz dışındadır. Örneğin, bazı tarayıcılar gizli tarama modundayken IndexedDB'e yazmaya izin vermez. Kullanıcının disk alanı neredeyse dolu olan bir cihaz kullanıyor olması da mümkündür. Bu durumda tarayıcı, hiçbir şey depolamanızı kısıtlar.
Bu nedenle, IndexedDB kodunuzda her zaman uygun hata işleme 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ın yerel olarak depolanan verilerini değiştirmesi nadir bir durum olsa da bu verileri temizlemeleri oldukça yaygındır. Uygulamanızın bu iki durumu da hata vermeden işleyebilmesi önemlidir.
Kayıtlı 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ı koruma
IndexedDB'in temel özelliklerinden biri, asenkron API'sidir. Ancak bu, kullanırken performans konusunda endişelenmenize gerek olmadığını düşünmenize neden olmasın. Yanlış kullanım, ana mesaj dizisini engellemeye devam edip yanıt vermeme durumuna yol açabilir.
Genel bir kural olarak, IndexedDB'de 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 saklamayı mümkün kılar (ve bunu yapmak geliştirici açısından oldukça kullanışlıdır). 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ükse engelleme süresi de o kadar uzun olur.
Popüler durum yönetimi kitaplıklarının çoğu (Redux gibi), durum ağacınızın tamamını tek bir JavaScript nesnesi olarak yöneterek çalıştığından, uygulama durumunun IndexedDB'de nasıl kalıcılaştırılacağını planlarken bazı zorluklar ortaya çıkar.
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 üzerindeki etkisini ölçmeniz gerekir. IndexedDB'e 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'e yaptığı yazma işlemlerinin ana iş parçacısını engelleyen ve kullanıcı deneyimini bozan uzun görevlere yol açması durumunda önemlidir. Ne için optimizasyon yaptığınızı anlamak amacıyla ölçüm yapmanız önemlidir.
Sonuçlar
Geliştiriciler, IndexedDB gibi istemci depolama mekanizmalarını kullanarak uygulamalarının kullanıcı deneyimini iyileştirebilir. Bunun için hem oturumlar arasında durumu sürdürebilir hem de tekrar ziyaretlerde ilk durumu yüklemenin süresini kısaltabilirler.
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.