Çok adımlı dinamik form: koşullu mantık, doğrulama ve yarıda kalan formlar

Rezervasyon formları, bir web uygulamasının en çok terk edilen ekranlarından biridir. Sebep genelde form alanlarının sayısı değil, hangi alanın neden sorulduğunun belli olmaması ve bir hatanın kullanıcıyı başa döndürmesidir. Bu yazıda çok adımlı, koşullu mantık içeren formları nasıl kurduğumuzu, Elite Transportions için geliştirdiğimiz dinamik form sisteminden çıkan derslerle anlatıyoruz.

Elite Transportions için React ile ulaşım hizmetlerine yönelik bir dinamik form sistemi geliştirdik. Sistemin temel parçaları: alanların koddan değil tanımdan üretilmesi, koşullu alan görüntüleme mantığı, gerçek zamanlı doğrulama, çok adımlı ilerleme, ilerleme takibi ve kaydetme, dosya yükleme ve önizleme, özelleştirilebilir alan türleri ve ulaşım rezervasyon sistemleriyle entegrasyon. Arayüz mobil uyumlu tasarlandı.

Aşağıdaki bölümler bu parçaların her birinde verilmesi gereken kararları ele alıyor. Bir kısmı doğrudan bu projeden, bir kısmı benzer formlarda genel olarak geçerli olan pratiklerden geliyor.

Adımları koda değil veriye yazmak

Çok adımlı bir formu her adım için ayrı bir bileşen yazarak kurmak ilk başta hızlıdır. Sorun, ilk değişiklik talebinde başlar: bir alanın başka bir adıma taşınması, yeni bir hizmet türü için iki alan eklenmesi, bir alanın zorunluluğunun değişmesi. Her biri bir kod değişikliği ve yeni bir dağıtım demektir.

Dinamik form yaklaşımında adımlar, alanlar, alan türleri, doğrulama kuralları ve görünürlük koşulları bir tanım nesnesinde durur; arayüz bu tanımı okuyarak formu üretir. Tanım sunucudan gelebilir, bir yönetim panelinden düzenlenebilir veya en azından kodun tek bir yerinde toplanabilir.

// Örnek form tanımı: arayüz bu nesneyi okuyarak adımları üretir
const formTanimi = {
  adimlar: [
    {
      id: 'yolculuk',
      baslik: 'Yolculuk',
      alanlar: [
        { ad: 'hizmetTuru', tur: 'secim', zorunlu: true,
          secenekler: ['transfer', 'saatlik'] },
        { ad: 'donusVar', tur: 'onay' },
        { ad: 'donusTarihi', tur: 'tarih', zorunlu: true,
          gorunur: { alan: 'donusVar', esittir: true } }
      ]
    },
    {
      id: 'belgeler',
      baslik: 'Belgeler',
      alanlar: [
        { ad: 'ekDosya', tur: 'dosya', kabul: ['pdf', 'jpg'] }
      ]
    }
  ]
}

Bu yapının bir bedeli var: tanım dili büyüdükçe kendi küçük programlama dilinize dönüşme eğilimi gösterir. Koşul ifadelerini basit tutmak, "eşittir", "içerir", "boş değil" gibi az sayıda operatörle sınırlamak ve karmaşık kuralları adlandırılmış fonksiyonlara taşımak bu riski azaltır.

Özelleştirilebilir alan türleri de aynı mantıkla çalışır. Metin, seçim, tarih, onay kutusu ve dosya gibi her tür, kendi giriş bileşenini ve varsayılan doğrulamasını bilen bir kayıt olarak tanımlanır. Yeni bir tür gerektiğinde formun geri kalanına dokunmadan yalnızca bu kayda bir satır eklenir. Rezervasyon sistemine gönderilecek veri de tanımdaki alan adlarından üretilebilir; böylece entegrasyon tarafı form değiştikçe ayrıca elden geçirilmek zorunda kalmaz, yeter ki alan adları rastgele değiştirilmesin ve hedef sistemin beklediği biçim tek bir dönüştürme fonksiyonunda tutulsun.

Koşullu alanlar ve gizlenen alanın değeri

Koşullu alan görüntüleme, kullanıcıya yalnızca kendisini ilgilendiren soruyu sormanın yoludur. Dönüş yolculuğu yoksa dönüş tarihi sorulmaz. Teknik olarak basit görünür ama iki ince nokta vardır.

Birincisi, gizlenen alanın değeri. Kullanıcı dönüş tarihini girip sonra dönüş seçeneğini kaldırırsa o tarih ne olacak? Formda saklı kalıp sunucuya gönderilirse, rezervasyon kaydında var olmayan bir dönüş yolculuğu görünür. İkincisi, doğrulama. Gizli bir alan zorunlu olarak işaretliyse ve doğrulama görünürlüğü hesaba katmıyorsa, kullanıcı göremediği bir alan yüzünden ilerleyemez.

Değeri silmek mi, saklayıp göndermemek mi? Kullanıcı seçeneği yanlışlıkla kaldırıp geri açabileceği için değeri arayüzde tutup gönderim sırasında ayıklamak genelde daha iyi bir deneyim verir.

Gerçek zamanlı doğrulama, ama rahatsız etmeden

Gerçek zamanlı doğrulama, hatayı kullanıcı formu göndermeden önce göstermek demektir. Yanlış uygulandığında ise kullanıcı daha yazmayı bitirmeden kırmızı uyarılarla karşılaşır. Genel olarak işe yarayan düzen şudur:

• Alan ilk kez doldurulurken hata gösterme; kullanıcı alandan çıktığında doğrula.
• Alan bir kez hatalı işaretlendikten sonra, her tuş vuruşunda yeniden doğrula ki hata düzelir düzelmez kaybolsun.
• Sonraki adıma geçişte yalnızca o adımın görünür alanlarını doğrula ve ilk hatalı alana odaklan.
• Hata mesajı neyin yanlış olduğunu değil, ne yapılması gerektiğini söylesin.
• İstemci doğrulaması bir kolaylıktır; aynı kurallar sunucuda da çalışmalıdır.

Son madde tanım tabanlı formların avantajlarından biridir: doğrulama kuralları veride durduğu için aynı tanım hem tarayıcıda hem sunucuda okunabilir.

Fiyat hesabı: istemcide göster, sunucuda hesapla

Rezervasyon formlarında kullanıcı genellikle seçimlerinin fiyata etkisini anında görmek ister. Bu, form değiştikçe tahmini bir tutar göstermeyi gerektirir. Burada genel kural nettir: tarayıcıda gösterilen tutar bilgilendirme amaçlıdır, bağlayıcı tutar her zaman sunucuda yeniden hesaplanır. İstemciden gelen fiyat alanına güvenen bir sistem, istek düzenlenerek değiştirilebilir.

Fiyat kuralları da formun kendisi gibi veriden okunursa, istemcideki tahmin ile sunucudaki kesin hesap aynı kaynaktan beslenir ve kullanıcının son adımda farklı bir tutarla karşılaşma ihtimali azalır.

Yarıda bırakılan formlar ve dosya yüklemeleri

Çok adımlı bir formda kullanıcı sayfayı kapatabilir, telefonu kilitlenebilir veya bağlantısı kopabilir. Elite Transportions formunda ilerleme takibi ve kaydetme bu yüzden temel özelliklerden biriydi. İlerlemenin kaydedildiği yer, formun hassasiyetine göre seçilmelidir: tarayıcı depolaması basit ve sunucusuz bir çözümdür, ama farklı cihazdan devam etmeyi sağlamaz ve paylaşılan cihazlarda kişisel veriyi açıkta bırakabilir.

Dosya yükleme de bu kararı etkiler. Dosyalar tarayıcı depolamasına uygun değildir; büyük dosyayı formun sonunda göndermek yerine seçildiği anda yükleyip yalnızca referansını form durumunda tutmak, hem yarıda kalan formu kurtarmayı kolaylaştırır hem de son adımdaki gönderimi hafifletir. Önizleme, kullanıcının yanlış dosyayı seçtiğini gönderimden önce fark etmesini sağlar.

Mobilde çok adımlı form

Rezervasyon formları büyük ölçüde telefondan doldurulur. Mobil uyumluluk yalnızca alanların ekrana sığması değildir. Her adımın tek ekranda tamamlanabilir olması, ilerleme göstergesinin kullanıcıya kaç adım kaldığını söylemesi, tarih, telefon ve e-posta alanlarında doğru klavyenin açılması ve "İleri" düğmesinin başparmakla erişilebilir yerde durması, formun tamamlanıp tamamlanmayacağını belirler.

Geri düğmesi de ayrıca düşünülmelidir. Kullanıcı tarayıcının geri tuşuna bastığında bir önceki adıma dönmeyi bekler, formun tamamen kapanmasını değil. Adımları adres çubuğuna yansıtmak bu beklentiyi karşılar.

Karar listesi

1. Adımlar ve alanlar sık değişecek mi? Evet ise tanım tabanlı dinamik forma yatırım yapın; değişmeyecekse sabit bileşenler daha az karmaşıktır.
2. Görünürlük, doğrulama ve gönderim aynı koşul fonksiyonunu mu kullanıyor?
3. Gizlenen alanların değerleri gönderimden önce ayıklanıyor mu?
4. Doğrulama kuralları sunucuda da çalışıyor mu?
5. Gösterilen fiyat sunucuda yeniden hesaplanıyor mu?
6. Yarıda kalan form nerede saklanıyor ve bu yer verinin hassasiyetine uygun mu?
7. Dosyalar seçildiği anda mı yükleniyor, formun sonunda mı?
8. Form telefonda, tek elle, baştan sona test edildi mi?

Çok adımlı bir formun iyi olup olmadığını en hızlı anlamanın yolu, onu gerçek bir telefondan, aceleyle ve bir adımda hata yaparak doldurmaktır. Bu testte takılan her nokta, kullanıcının formu terk ettiği noktadır.

• #dinamik form
• #react
• #form doğrulama
• #rezervasyon