React’te bekleme ve hata durumları: kullanıcıyı yarıda bırakma

Bir arama kutusu tasarladığını düşün. Kullanıcı ilk kelimeyi yazar, bir istek başlar; hemen ardından sorguyu değiştirir. İlk istek daha geç dönerse ekranda hangi sonuç görünmelidir? Bu soru, bekleme durumunun yalnızca bir dönen simgeden ibaret olmadığını gösterir. Doğru tasarım; girdiyi, istek kimliğini, görünür sonucu ve hata yolunu birlikte ele alır. Buradaki örnek bir arayüz tasarımıdır, ölçülmüş bir performans iyileştirmesi iddiası değildir.

Kullanıcının neyi beklediğini tanımla

“Yükleniyor” mesajı tek başına eksik olabilir. Yeni sonuç listesi mi, bir dosya mı, yoksa kaydetme işlemi mi bekleniyor? Göstergenin konumu ve metni bu soruya cevap versin. Kullanıcı arama yazarken bütün sayfayı kullanılamaz hale getirmek yerine ilgili sonuç bölgesini ele alabilirsin. Buna karşılık aynı kaydı iki kez oluşturan bir işlemde gönderim kontrolü ayrıca gerekebilir. Her bekleme durumuna aynı kilitlemeyi uygulama.

Önceki sonucun ekranda kalması bazı akışlarda yararlıdır. Ancak yeni sorguya aitmiş gibi sunulursa yanıltıcı olur. Sonuçların yenilendiğini açık bir durum mesajıyla belirt ve eski verinin durumunu anlaşılır tut. Yerleşim için ayrılmış alanı korumak büyük sıçramaları azaltabilir. Görsel iskelet kullanıyorsan gerçek içerikle benzer bir alan kaplasın; sadece hareketli bir dekor olarak kalmasın. Hareket azaltma tercihi de bu tasarımın parçasıdır.

Hangi mekanizmanın ne yaptığını ayır

Suspense, desteklenen bir kaynak beklenirken yakınındaki fallback arayüzünü gösterebilir. Bir bileşenin içine rastgele fetch eklemek, onun otomatik olarak bu sınırı kullanacağı anlamına gelmez. Çatının veri yükleme yaklaşımını ve kullandığın bileşenin davranışını resmi belgede incele. Önce küçük bir örnekte hangi sınırın ne zaman göründüğünü gözle. Bir yükleme sorununu daha fazla sınır ekleyerek çözmeden önce gerçek veri akışını anla.

Transition ise ağ hızını değiştiren bir araç değildir. Bazı güncellemelerin önceliği ve mevcut arayüzün korunmasıyla ilişkilidir. Kullanıcının metin alanındaki değeri hemen güncellenmeli; daha ağır sonuç değişimi ayrı ele alınabilir. Asenkron eylemlerden sonra hangi state güncellemesinin transition kapsamında olduğunu da kontrol et. Bir API adını kullanmış olmak, beklediğin bütün davranışların kendiliğinden oluştuğunu kanıtlamaz.

Geç gelen yanıtı küçük bir testle yakala

İki sorgu düşün: önce “kitap”, sonra “kitaplık”. İkinci sorgunun sonucu önce dönsün. Birinci yanıt daha sonra gelince son listeyi değiştirmemeli. İstek iptali, etkin istek kimliği veya veri katmanının sunduğu mekanizma bu soruna yardımcı olabilir; hangi yaklaşımın kullanıldığını açıkça belirle. İptal edilmiş isteğin ekranda gereksiz hata mesajı üretip üretmediğini de kontrol et. İptal her zaman kullanıcıya hata diye gösterilmemelidir.

Bu testi gerçek servisi yormadan gecikmeli bir test yanıtıyla yapabilirsin. Normal sıra, ters sıra, boş sonuç ve hata için beklenen ekranı yaz. Her yanıtın yalnızca kendi sorgusuna ait sonucu değiştirdiğini doğrula. Sonra sayfadan ayrılma durumunu dene. Kullanıcı başka bölüme geçtiğinde eski isteğin görünmeyen bir bileşende beklenmeyen durum güncellemesi yaratmaması, iyi bir iptal ve yaşam döngüsü tasarımının parçasıdır.

Hata sonrasında devam yolu sun

Veri doğrulama hatasında kullanıcı hangi alanı değiştireceğini bilsin. Ağ sorununda aynı girdiyi koruyup yeniden deneme seçeneği sunabilirsin. Render hatası için kullanılan Error Boundary, bütün bu durumların yerine geçmez. Erişilebilir durum mesajı, odak davranışı ve hata metni birlikte kontrol edilmeli. Teknik hata yığınını ziyaretçiye göstermek yerine, neyin tamamlanmadığını ve yapabileceği güvenli sonraki adımı anlat.

Son kabul turunda yalnızca fare kullanma. Klavyeyle arama yap, yeni sonuca ulaş, hatayı okuyup yeniden dene. Ekran büyütüldüğünde mesaj ve kontrol birbirinden kopuyor mu, mobilde buton görünür mü, kontrol et. Kendi inceleme listen bu incelemeyi düzenler; kodunu çalıştırmaz veya erişilebilirliği sertifikalandırmaz. Gerçek doğrulama, bu durumları çalışan arayüzde gözleyip hangi kontrolün neyi kapsadığını kaydetmekle yapılır.

Bir etkileşimin durum çizelgesini hazırla

Küçük bir tabloya kullanıcı eylemini, etkin isteği, görünür sonucu ve kullanılabilir kontrolü yaz. İlk satırda kullanıcı henüz yazmamış olsun. İkinci satırda arama sürsün, üçüncüde boş sonuç, dördüncüde geçerli sonuç ve beşincide ağ hatası bulunsun. Her satırda aynı düğmenin ne yaptığı belli olmalıdır. Bir durumda yeniden dene, başka durumda yeni kayıt gönder anlamına geliyorsa etiket ve davranış bu farkı açıklamalıdır. Görsel benzerlik, farklı dış etkileri gizlememelidir.

Sonra sadece klavyeyle tabloda tarif ettiğin yolu izle. Sorgu yaz, sonucu bekle, boş durumda yeni sorgu gir ve hatadan sonra yeniden dene. Odak beklenmedik yere sıçrıyorsa veya hata metni kontrolün uzağında kalıyorsa bunu tasarım bulgusu olarak kaydet. Bekleme göstergesini kaldırıp aynı akışı düşünmek de yararlıdır: kullanıcı yine ne olduğunu anlayabiliyor mu? Anlamıyorsa yalnızca animasyona bağımlı bir açıklama yapmış olabilirsin. Metin, durum ve kontrol ilişkisini düzeltmek daha kalıcı bir iyileştirme sağlar.

Kaynaklar

• React Suspense
• React useTransition
• React hata sınırları