One Piece Hub: Spoiler Vermeyen Türkçe Wiki

One Piece Hub, One Piece evrenini Türkçe gezmek için yaptığım bir fan sitesi. Binden fazla bölümü arklara göre düzenliyor, filler bölümleri ayıklıyor, karakterleri, şeytan meyvelerini ve büyük savaşları tek bir yerde topluyor ve en önemlisi, kaldığın yerden sonrasını sana göstermiyor. Çünkü bir wiki her şeyi bilir ve seriyi 300. bölümde izleyen birine 900. bölümdeki olayı göstermek, yıllardır takip ettiği hikâyeyi elinden almak demek.

Seriyi Türkçe takip eden biri için mevcut kaynaklar ya İngilizce, ya filler dolu, ya da dağınık. Ben hem düzenli bir rehber istedim hem de bir anime wikisinin koyu temalı, hareketli bir arayüzle nasıl hissettirebileceğini görmek istedim. Sonuç bir rehber kadar bir deneme alanı da oldu.

Sitede Neler VarBağlantı Kopyalandı

1. 1

   Arklar ve Bölümler

   Seri on saga ve otuz altı ark olarak düzenli. Her arkın bölümleri filler ayıklanmış sırayla listeleniyor; hangi bölümü izlediğini işaretleyip kaldığın yeri hatırlayabiliyorsun. Hesap açarsan ilerleme veritabanına, açmazsan tarayıcına yazılıyor.

2. 2

   Karakterler ve Tayfalar

   Her karakterin sayfası, ödül geçmişi, tayfası ve ilk göründüğü ark. Karakter ilişkileri ekranında kimin kiminle nakama, aile, rakip ya da düşman olduğunu tek bakışta görüyorsun.

3. 3

   Dünya

   Şeytan meyveleri, haki rehberi, lokasyonlar, güç sıralaması ve serinin büyük dövüşleri. Her biri kendi sayfasında, kendi görseliyle.

4. 4

   Quiz ve Başarımlar

   Her ark için beş ile on soruluk bir quiz, seri takibi ve küçük ses efektleri. Skorlar hesabına yazılıyor, yüksek skor eskisinin üstüne geçiyor.

5. 5

   Komut Paleti

   ⌘K ile açılan bir arama: karakter, ark, meyve ya da sayfa adı yazıp doğrudan gidiyorsun. Telefonda alt menü ve tam ekran arama var.

Nasıl KurdumBağlantı Kopyalandı

Site Next.js 14 ve TypeScript ile yazıldı; stil Tailwind, hareket Framer Motion. İçeriğin tamamı, yani arklar, karakterler, meyveler ve quiz soruları veritabanında değil, tipli TypeScript dosyalarında duruyor. Bu sayede içerik sayfaları derleme anında üretiliyor ve git’te sürümleniyor; bir karakterin adını yanlış yazarsam derleme hata veriyor.

Veritabanı yalnızca kullanıcıya ait şeyleri tutuyor: izleme ilerlemesi ve quiz skorları. Neon üzerinde Postgres, Drizzle ile. Giriş kendi yazdığım küçük bir JWT akışı; çerezde duruyor, otuz gün geçerli. Sayfalar arası geçişlerde karakter kartı kendi sayfasının kapağına dönüşüyor; bunu tarayıcının View Transitions özelliği yapıyor.

Sitenin asıl zor kısmı bunların hiçbiri değildi. Zor kısım, bütün bu içeriği okuyan kişinin kaldığı yere göre saklamaktı.

Spoiler Nedir, Kod AçısındanBağlantı Kopyalandı

Kod yazmak için somut bir tanım gerekiyordu. “Önemli olay” gibi bir tanım işe yaramazdı; neyin önemli olduğu bir yargı ve her içerik parçası için ayrı ayrı verilmesi gerekir. Oysa One Piece sırayla ilerliyor: her içerik bir arka ait, arklar sıralı, okuyan kişi de bir arkta. Gerisi iki sayıyı karşılaştırmak.

const isSpoiler = useCallback((arcSlug: string | undefined) => {
  if (!active || !arcSlug) return false
  const targetIndex = ARCS.findIndex(a => a.slug === arcSlug)
  if (targetIndex === -1) return false
  return targetIndex > currentArcIndex
}, [active, currentArcIndex])

Bilinmeyen ark için “gizleme” kararı bilinçli. Bir içeriğin arkı etiketlenmemişse onu saklamıyorum. Öteki seçenek “emin değilsen sakla” olurdu ve o kural, etiketi eksik tek bir kayıt yüzünden sayfaları sebepsiz yere karartırdı. Emin değilken göstermek daha az zarar veriyor.

Okuyucuya “Neredesin” Diye SormakBağlantı Kopyalandı

Okuyucuya kaçıncı bölümde olduğunu sormuyorum; bölüm numarası kimsenin aklında kalmaz. Ama Alabasta’yı bitirip bitirmediğini herkes bilir. O yüzden bir ark seçiyorsun. Seçici otuz altı arkı on saga başlığı altında gruplayarak gösteriyor; düz bir liste uzun bir kaydırma olurdu.

Ekranın köşesindeki küçük düğme durumu sürekli söylüyor: koruma açıksa kaçıncı arkta olduğunu, açık ama ark seçilmemişse ark seçmen gerektiğini. Çalıştığını iddia etmeden önce gerçekten çalışıyor olması gerekiyor; bunu zor yoldan öğrendim.

Perde Aylarca Hiçbir Şeyi ÖrtmemişBağlantı Kopyalandı

Spoiler korumasını siteye eklediğim günden dört ay sonrasına kadar o köşedeki düğme yanlış bilgi verdi. Koruma düz bir React hook’uydu ve onu çağıran her bileşen kendi state’ini kuruyordu. Düğmenin bir kopyası vardı, listedeki her ark kartının da ayrı bir kopyası. Düğmeden ark seçince yalnızca düğmenin kopyası değişiyordu. Düğme “Spoiler: 14/36” yazıyor, kartlar ise sayfa yenilenene kadar hiçbir şeyi gizlemiyordu.

Düzeltme, hook’u tema ve oturum sağlayıcılarıyla aynı yapıda tek bir Context sağlayıcıya çevirmek oldu. Yanına iki küçük karar ekledim. Ark seçmek korumayı kendiliğinden açıyor, çünkü niyeti belli eden adım o. Ve durum artık her zaman yazıyla bildiriliyor: kaç ark gizlendi, ark seçmen gerekiyor mu, koruma duraklatıldı mı.

Görünmeyen bir korumaya kimse güvenmez. Görünüp çalışmayan bir koruma daha kötü, çünkü güveni hak etmeden kazanır.

Gizlenen Şey Nasıl GörünmeliBağlantı Kopyalandı

İki seçenek vardı: içeriği tamamen kaldırmak ya da üstünü örtmek. Kaldırmak ark listesini ortasından keserdi ve okuyan kişi sitenin bozuk olduğunu sanırdı. Üstelik bir arkın var olduğunu bilmek spoiler sayılmaz; içinde ne olduğunu bilmek sayılır.

Gizli bir kart şöyle duruyor: görsel bulanık, ark adı ve özet bulanık ve seçilemiyor, bölüm sayısı hiç çizilmiyor, üstünde “Spoiler” ve “göstermek için tıkla” yazıyor. Tıklayınca yalnızca o kart açılıyor, koruma kapanmıyor. Kararı okuyan kişiye bırakıyorum; “bunu görmek istiyor musun” sorusu, sorunun kendisi bir şey ele vermediği sürece adil.

Burada dürüst olmam gereken bir eksik var. Bulanıklık CSS’te ve ekran okuyucu CSS görmez. Gizli kartın erişilebilir adı ark adını okumuyor ama saga adını söylüyor; yani gören okuyucudan saklanan bir bilgi, ekran okuyucu kullanan okuyucuya yüksek sesle söyleniyor. İki taraf aynı kuralı izlemiyor ve bunu henüz düzeltmedim.

Karakter İlişkileri: Neden ÇemberBağlantı Kopyalandı

Sitenin uğraştıran ikinci parçası karakter ilişkileri ekranıydı. Elimde yirmi beş karakter ve aralarında elle yazdığım yirmi dokuz bağ var: nakama, aile, rakiplik, düşmanlık, hoca-öğrenci, ittifak. Böyle ekranlar genelde fizik tabanlı çizilir; düğümler birbirini iter, bağlı olanlar birbirini çeker, sistem kendi dengesini bulur.

Ben düğümleri bir çemberin üzerine eşit aralıklarla dizdim. Sekiz satır, fizik yok, rastgelelik yok. Kazancı yerinden oynamaması: Luffy her ziyarette aynı yerde duruyor ve ilişki türüne göre filtre bir anlam kazanıyor. “Sadece düşmanlıklar” dediğinde çember aynı kalıyor, yalnızca çizgiler değişiyor; iki görünümü bu sayede karşılaştırabiliyorsun. Fizik tabanlı yerleşimde her filtre yeni bir düzen demek olurdu.

Fizik tabanlı yerleşim, yapısını bilmediğin bir grafta küme aramak için iyidir. Ben yapıyı zaten biliyordum.

Ne ÖğrendimBağlantı Kopyalandı

İki parçada da işe yarayan çözüm daha sade olanıydı. Spoiler perdesi sıralı bir dizide iki indeksi karşılaştırıyor; graf, fizik hesaplamak yerine düğümleri çembere diziyor.

Perdenin kapsamı da hâlâ dar. Bugün yalnızca ark listesindeki kartlarda çalışıyor. Karakterlerin ilk göründüğü ark veride var ama karakter sayfaları perdeye bağlı değil. Yani bir karakter sayfasını açıp sağ üstte “Durum: Ölü” görmek hâlâ mümkün. Sıradaki iş o.