Veri ve Entegrasyon

Şu an: fixture verisi

Ekranlarda görünen her rakam app/_data/panel.ts dosyasından gelir. Bu veriler tasarım paketinden aktarıldı ve hiçbiri gerçek değil. Repoda hiçbir fetch, server action ya da veritabanı çağrısı bulunmuyor.

Veriler ekran başına dağıtılmak yerine tek bir modülde toplandı. Böylece gerçek okumalara geçiş bu dosyaya ve ekranların import satırlarına dokunur, ekranların işaretlemesine dokunmaz.

Modülün içeriği

Menü ürünleri üretilir. Ürünler, prototipin kullandığı formülle oluşturulur: fiyat kategori taban fiyatından türetilir, oto-ateşle Bar istasyonu ve Başlangıçlar kategorisinde açıktır, her 23. ürün satış dışıdır. On iki kategori tanımından 158 ürün bu yüzden çıkar. Yalnızca birkaç ürünün açıklama, içindekiler ve alerjen bilgisi dolu.

Türetilmiş sayaçlar

Kenar çubuğu rozetleri, stok durumu, stok değeri, zayi ve plan kullanımı gibi değerler saklanmaz, kaynak dizilerden hesaplanır. Böylece bir satırı düzenlemek, rozetin özetlediği tabloyla çelişmesine yol açamaz.

Rozetler fixture’lardan hesaplanır, ekranların client state’inden değil. Menüde bir ürün silmek veya bir cihazı eşleştirmek kenar çubuğundaki sayıyı değiştirmez.

Stok rozeti tükenenleri de sayar; Stok ekranındaki “Kritik” hücresi ise yalnızca miktarı sıfırdan büyük olanları sayar ve tükenenleri notta ayrıca gösterir. Bu yüzden iki sayı farklı görünebilir.

Client state

Client ekranlar useState’i bu sabitlerle başlatır. Personel eklemek, cihaz eşleştirmek ya da plan değiştirmek ekranda görünür, ama yalnızca o oturum için geçerlidir ve sayfa yenilenince kaybolur. State ekranlar arasında da paylaşılmaz. Şu an kaydedilecek bir yer olmadığı için bu bilinçli bir tercih.

Bilinen sınırlamalar

• Yeni kayıt kimlikleri çakışabilir. Menü kategorileri, menü ürünleri, cihazlar ve personel için yeni id önek + (dizi uzunluğu + 1) olarak üretilir. Önce bir kayıt silinip sonra yenisi eklenirse, üretilen id mevcut bir kayda denk gelebilir. Örneğin 12 kategoriden biri silinip yeni kategori eklenirse yeni id c12 olur, ki bu zaten Kokteyller’in id’sidir. O durumda iki satır aynı React key’ini taşır ve düzenleme ikisine birden uygulanır. Kimlikler veritabanından gelmeye başladığında bu sorun ortadan kalkar; o zamana kadar düzeltilmedi.
• Silme işlemleri onay istemez. Kategori silmek içindeki ürünleri de siler.
• Stok hareketi, e-belge oluşturma, yeniden gönderme, iptal ve ayar kaydetme yalnızca arayüzdür. Bkz. Ekranlar.

Gerçek veriye geçiş

Bir ekranı gerçek veriye bağlarken:

1. Okumayı, veri gerektiren en yakın Server Component’e koyun. Client ekranlarda veriyi Server Component’te çekip prop olarak geçirin; bu, ekranı baştan client’a taşımaktan iyidir.
2. İlgili fixture’ı app/_data/panel.ts’ten kaldırın ve türetilmiş sayaçları (BADGES dahil) gerçek veriden hesaplayın.
3. Yazma işlemleri için server action kullanın ve “yalnızca arayüz” düğmelerini bağlayın. Başarısız olabilecek yıkıcı işlemler geldiğinde onay ve bildirim (toast) altyapısı gündeme gelmeli.
4. Kullanılan her backend endpoint’i için aşağıdaki tabloya bir satır ekleyin. Bu repo kendi endpoint’ini (route handler) açarsa onu docs/api/ altında belgeleyin. Bkz. Dokümantasyon düzeni.
5. Next.js 16’nın veri çekme ve önbellekleme davranışını node_modules/next/dist/docs/ altındaki rehberden doğrulayın. Eski sürümlerden hatırlanan davranışa güvenmeyin.

Kullanılan endpoint’ler

Henüz yok. Panel hiçbir backend endpoint’ini çağırmıyor ve kendisi de endpoint açmıyor.

Ekranları bekleten işler

Ekranların arayüz işleri SCRUM-19 (Admin Panel Foundation) epiği altındadır: kabuk ve navigasyon SCRUM-134, ekranlar SCRUM-186 … SCRUM-195. Gerçek veriye geçişi belirleyen işler:

Backend’e ve yerel veritabanına ait değişiklikler kendi repolarında belgelenir (smart-menu-adisyon-backend-dev, smart-menu-adisyon-localdb-dev). Bu sayfa yalnızca panelin onlara olan bağımlılığını gösterir.