Bağlı seçimlerde eski alt değeri temizlemek

İl seçildi, ilçe listesi geldi; kullanıcı ili değiştirdi ama eski ilçe kimliği formda kaldı. Ekran boş görünse bile modeldeki değer kayda gidebilir. Bağlı seçimlerde yalnız yeni seçenekleri yüklemek yetmez; üst alan değiştiği anda alt seçimin geçerliliği de yeniden kurulmalı.

Üst seçim değişince eski bağı koparmak

Arşivdeki bağlı seçim örneklerini küçük bir sözlükle gösteriyorum. Üst kimlik 1 için 10 ve 11, üst kimlik 2 için yalnız 20 geçerli. Başlangıçta 1/10 seçilmişken üstü 2 yapınca alt seçim null olur. Örnek .NET 10 konsolunda çalışır; gerçek form ve API yerine durum geçişini görünür tutar.

var options=new Dictionary<int,int[]> { [1]=[10,11],[2]=[20] };
int parentId=1; int? childId=10;
void ChangeParent(int next)
{
    if(!options.ContainsKey(next))throw new ArgumentException("Unknown parent");
    parentId=next;
    childId=null;
}
ChangeParent(2);
Console.WriteLine($"parent={parentId};selected={childId?.ToString()??"none"};options={string.Join(",",options[parentId])}");

Çıktı parent=2;selected=none;options=20. Kontrol sırası bilinçli: bilinmeyen üst kimlik önce reddedilir, sonra parentId değiştirilir ve childId temizlenir. Geçersiz üst girdide mevcut geçerli formu bozmak istemem. Alt değer için null seçimi, 0 gibi gerçek bir kimlikle karıştırılabilecek sihirli varsayılanı da önler.

Alt listenin kendi durumu var

Gerçek bir istemcide alt alan en az “üst seçilmedi”, “yükleniyor”, “seçenekler geldi”, “boş sonuç” ve “hata” durumlarına sahip olabilir. Boş seçenek listesi ile servis arızasını aynı “kayıt yok” mesajına çevirmem. Hata durumunda kullanıcıya tekrar deneme yolu sunulur; eski üst değere ait seçenekler yeni üst değer altında seçilebilir kalmamalı.

Üst değiştiği anda alt kimliği ve gerekiyorsa alt listeyi temizlerim. Yükleme sırasında alanı kapalı tutmak yanlış seçimi azaltır, fakat kapalı olmasının nedeni görünür olmalı. Kullanıcı bir sonraki adımı anlayabilmeli; yalnız gri bir kutu yeterli geri bildirim değildir.

Yanıtlar istek sırasıyla gelmeyebilir

Kullanıcı önce A, hemen sonra B seçerse B'nin seçenekleri önce dönebilir. A yanıtını sonradan uygulamak modelin üst kimliği B iken ekranda A seçenekleri göstermesine neden olur. İptal edilebilir istek veya artan istek kimliğiyle yalnız son isteğin sonucunu kabul ederim. Sadece “her isteği await ettim” demek farklı kullanıcı olaylarının aynı sırada biteceğini garanti etmez.

İstek iptali ağ veya sunucu işini her zaman geri almaz; yine de eski yanıtın UI'ı değiştirmemesi gerekir. Bir parentId ile yüklenen seçenek kümesini o kimlikle birlikte tutmak, yanıt uygulanırken ek bir tutarlılık kontrolü sağlar.

Düzenleme ekranını açmak farklı bir geçiştir

Var olan kaydı yüklerken hem üst hem alt kimlik dolu gelir. “Üst değişti” işleyicisini körlemesine çalıştırırsam kayıtlı alt değeri ekran açılırken silerim. İlk yükleme/hydration ile kullanıcının sonradan değiştirmesini ayırır, önce üst seçenekleri ve ona ait alt seçenekleri yükleyip kayıtlı ilişkinin hâlâ geçerli olduğunu doğrularım.

Alt kayıt artık pasifse sessizce başka bir seçeneğe geçmem. Kullanıcıya mevcut ilişkinin neden kullanılamadığını ve yeniden seçim gerektiğini açıklarım. Özellikle aynı isme sahip seçeneklerde gösterim metnine göre eşleştirme yerine kalıcı kimlik kullanılır.

Son kontrol kayıt sırasında yapılır

İstemcide doğru listeyi göstermek veri bütünlüğü sınırı değildir. Sunucu, gönderilen childId'nin parentId'ye ait ve kullanıcının kapsamı içinde olduğunu kayıt anında kontrol eder. Gerekli ilişki kısıtları da veritabanında bulunmalı; iki ayrı geçerli foreign key her zaman aralarındaki doğru eşleşmeyi kanıtlamaz.

Testte üst değişimi, hızlı A→B geçişi, boş sonuç, yükleme hatası, mevcut kayıt açılışı ve elle değiştirilmiş istek bulunmalı. Ekranı doğru doldurmak kadar yanlış ilişkiyi reddetmek de bu özelliğin tamamlanma ölçütüdür.

Eski yanıtları etkisizleştirme örneği; Kalıcı ilişki modelleme.