Bir ekranda bağımsız sayfalı listeler kurmak

Bir yönetim ekranında hata kayıtları, işlem geçmişi ve istatistik listesi birlikte bulunabilir. Hatalarda ikinci sayfaya geçtiğimde geçmiş listesinin de ileri gitmesi, tek bir page değişkeninin yanlış paylaşılmasının tipik sonucudur. Arşivimde bu listeler için ayrı getirme ve sayfalama metotları var; aynı ayrımı ekran durumuna ve API isteğine kadar taşımak gerekir.

Sayfa durumu listeye aittir

Örnekte hata kaydı 1–12, işlem geçmişi 101–112 aralığında. Hata listesinden ikinci, geçmişten ilk sayfayı istiyorum. Sayfa numaraları birden başlıyor; her sayfada üç kayıt var. Bu .NET 10 konsol kodu bağımsız durum fikrini küçük bir veri kümesinde gösterir.

var errors = Enumerable.Range(1, 12).ToArray();
var actions = Enumerable.Range(101, 12).ToArray();
static int[] Page(int[] rows, int page, int size)
{
    if(page < 1 || size is < 1 or > 100) throw new ArgumentOutOfRangeException();
    return rows.Skip((page-1)*size).Take(size).ToArray();
}
Console.WriteLine(string.Join(",", Page(errors,2,3)));
Console.WriteLine(string.Join(",", Page(actions,1,3)));

Sonuç errors için 4,5,6; actions için 101,102,103. Skip hesabındaki page-1 birden başlayan ekran numarasını sıfır tabanlı ofsete çeviriyor. İki isteğe ayrı page vermek, aynı yordamı paylaşırken durumu karıştırmamayı sağlıyor. Gerçek ekranda ErrorsFilter ve HistoryFilter gibi ayrı nesneler sayfa, boyut ve ilgili arama koşullarını taşıyabilir.

Filtre değişince hangi sayfa sıfırlanır?

Hata mesajında arama yaparsam yalnız hata listesinin sayfasını bire çekerim. Geçmişin tarihi veya sayfa numarası değişmemeli. URL'de durum tutuluyorsa errorsPage ve historyPage gibi ayrı parametreler aynı ayrımı korur; geri/ileri gezinme de kullanıcının beklediği listeyi geri getirebilir. Aynı parametreyi farklı anlamlarda kullanmak bu davranışı zorlaştırır.

Toplam kayıt sayısı da filtreye ait olmalı. Görünen satırlar filtreli, pager toplamı filtresiz sorgudan geliyorsa kullanıcı boş sayfalara gider. Silme sonrası son sayfa boşaldığında geçerli son sayfa hesaplanıp o sayfaya dönülmeli. Bu düzeltmenin yalnız ilgili listeye uygulanması önemlidir.

Bellek örneğini sunucu sorgusuna taşımak

Konsol örneği küçük diziler üzerinde çalışır. Büyük tabloda bütün kayıtları indirip aynı Skip/Take işlemini tarayıcıda yapmak istemem. Sunucu önce yetki kapsamını ve filtreyi uygular, toplamı hesaplar, kararlı sıralama kurar, ardından sayfayı seçer. Liste yanıtında sayfa bilgisi ve toplam bulunur; kullanıcıya gösterilmeyen büyük gövdeler gereksiz yere gönderilmez.

Sıralama yalnız CreatedAt olduğunda aynı tarihli kayıtlar arasında sıra belirsiz kalabilir. CreatedAt ve Id gibi benzersiz sonuca ulaşan bir bileşim gerekir. Bu, offset sayfalamanın eşzamanlı eklemelere karşı sabit bir görüntü sağladığı anlamına gelmez. Çok hareketli veri veya büyük ofsetler için anahtar üzerinden sayfalama ayrı bir seçenektir.

Hızlı arama ve geciken yanıt

Kullanıcı iki filtreyi hızla değiştirdiğinde ilk isteğin cevabı sonradan gelebilir. İstek iptali veya güncel sorgu kimliği kullanarak eski cevabın yeni listeyi ezmesini önlerim. Her liste için yükleniyor ve hata durumu da ayrı tutulmalı. Bir geçmiş isteği hata verdi diye zaten gösterilmiş hata kayıtlarını kaldırmak gereksiz bir bağımlılık yaratır.

Arama girdisinde kısa bir debounce ağ yükünü azaltabilir; sayfa düğmesine basıldığında ise aynı beklemeyi zorunlu tutmak gerekmeyebilir. İstek sınırları da sunucuda doğrulanmalı. Örnekte size 1–100 aralığında ama çok büyük page değerinde çarpma taşması ayrıca ele alınmıyor; gerçek uçta üst sınır veya checked hesaplama gerekir.

Birbirinden bağımsızlığı test etmek

Önce yalnız errorsPage'i değiştirip geçmiş satırlarının aynı kaldığını doğrularım. Sonra filtre, boş sonuç, son satırın silinmesi ve ters sırada tamamlanan iki istek senaryolarını denerim. Bu kontroller ekranın yalnız ilk açılışını değil, kullanıcı birden fazla liste arasında çalışırken durumun kime ait kaldığını sınar.

EF Core sayfalama ve kararlı sıralama; Enumerable.Skip.