FullCalendar’da veriden etkinlik üretmek

Takvimde bir yemek kaydını etkinlik olarak göstermek kolaydır. Aynı kutuya tıklayınca kapasiteyi güvenli biçimde azaltmak ise başka bir özelliktir. Arşivimdeki tek HTML rezervasyon arayüzünü açıklarken FullCalendar'ın gösterim modeliyle sunucunun rezervasyon kararını ayırıyorum; arayüz dosyasının varlığı kalıcı rezervasyon servisi kanıtı değil.

İş modelini etkinlik modeline dönüştürmek

Örnekte Lunch kaydının kimliği 1, kapasitesi 20, ayrılmış sayısı 7. Gösterilecek kalan değer 13. Date alanı 2026-10-17 biçiminde salt gün, bu nedenle allDay=true seçiliyor. toEvent fonksiyonu Node.js'te sınanabilir; yorumdaki FullCalendar kurulumu ise tarayıcı ve uygun kütüphane paketlerini gerektirir.

export function toEvent(meal){
  if(!/^[0-9]{4}-[0-9]{2}-[0-9]{2}$/.test(meal.date))throw new Error('Expected ISO date');
  return {id:String(meal.id),title:meal.name,start:meal.date,allDay:true,
    extendedProps:{remaining:meal.capacity-meal.reserved}};
}
console.log(JSON.stringify(toEvent({id:1,name:'Lunch',date:'2026-10-17',capacity:20,reserved:7})));
// Browser integration:
// new FullCalendar.Calendar(element, {
//   events: meals.map(toEvent),
//   eventClick: info => { details.textContent = info.event.title; }
// });

id'yi string yapmak takvimin olay kimliğiyle eşleşmeyi kolaylaştırır. title görünür adı, start başlangıç değerini taşır. remaining gibi uygulamaya özgü alanlar extendedProps içine konur. Bu ayrım, bileşenin event özelliklerini iş modelinin bütün alanlarıyla rastgele karıştırmamayı sağlar.

Bir regex geçerli tarihi kanıtlamaz

Örnekteki regex yalnız yyyy-MM-dd şekline bakıyor. 2026-02-31 aynı desenden geçer ama gerçek bir takvim günü değildir. API sınırında takvim geçerliliği ayrıca denetlenmeli; string'i Date'e verip otomatik taşmasına güvenilmemeli. Tarihin salt gün olması ile bir zaman damgası olması da ayrı sözleşmedir.

Bir gün etkinliğini gereksiz UTC dönüşümünden geçirirsem saat dilimine göre önceki veya sonraki güne kaydırabilirim. Belirli saatte başlayan etkinlikte ise offset ve FullCalendar timeZone seçimi açık olmalı. Aynı date string'ini her kullanımda aynı anlama geliyor sanmak hata üretir.

Takvim aralığının bitişi nasıl yorumlanıyor?

FullCalendar'da end değerinin dışlayıcı olması, çok günlük etkinliklerde sık görülen bir sınır hatasıdır. Bir etkinliğin son görünür günü ile end tarihini aynı kavram gibi kullanmam. Bu örnekte end alanı yok; yalnız tek güne ait veri sunuluyor. Daha uzun aralık eklenecekse başlangıç, bitiş ve görünür günler birlikte test edilir.

Kalan kapasite gösterimdir, rezervasyon yetkisi değil

remaining=capacity-reserved hesabı istemcide yapılabiliyor. Ancak iki kullanıcı aynı anda son yeri seçerse ikisinin de ekranında 1 görebilmesi mümkündür. Rezervasyonu kabul eden sunucu bu kararı atomik biçimde korumalı; istemcinin gönderdiği kalan sayıya veya butonun kapalı oluşuna güvenmemeli. Yetki, tarih uygunluğu ve mükerrer rezervasyon kuralı da aynı iş akışına aittir.

Kapalı kayıt, iptal veya dolu etkinlik için ayrı durum alanı daha açıklayıcı olabilir. Negatif remaining değerini sıfıra kırpmak veri tutarsızlığını gizleyebilir. Görsel kutu kırmızı olsa bile altyapı kuralı düzelmiş olmaz.

Tıklama ve veri yükleme sınırı

Örnekte eventClick, başlığı textContent ile yazar; kullanıcı metnini HTML birleştirerek basmıyor. Gerçek ayrıntı paneli gerekiyorsa event kimliğiyle yetkili API çağrısı yapabilir. Takvimin gösterdiği alanlar işlem yetkisini belirlemez.

Büyük veri için bütün yılı yüklemek yerine görünür aralık üzerinden istek yapılabilir. Kullanıcı hızla ay değiştirince eski yanıtın yeni ayı ezmemesi gerekir. Bir etkinliğin kimliğini kararlı tutmak, refresh sonrası aynı kaydı güncellemeyi de kolaylaştırır.

Testlerde geçerli gün, regex'ten geçen geçersiz gün, kapasitenin dolması, eşzamanlı iki rezervasyon ve çok günlük bitiş sınırı yer alır. toEvent bir saf dönüşüm olduğundan bu model kontrollerinin çoğu takvim bileşeni çizilmeden yapılabilir.

FullCalendar event sözleşmesi; Saat dilimi davranışı.