React geliştiricilerinin çoğu, formların her zaman bileşenler olması gerektiği zihinsel modelini paylaşır. Bu modelde, React Hook Form (RHF) yerel durum için, Zod validasyon için ve React Query backend işlemleri için kullanılır. Giriş ekranları, ayar sayfaları ve CRUD modal'ları gibi formların büyük çoğunluğu için bu yaklaşım mükemmel çalışır. Ancak bazı formlar, önceki yanıtlara bağlı görünürlük kuralları veya kaskat hesaplanan değerler gibi karmaşıklıklar biriktirmeye başladığında, bu modelin sınırları ortaya çıkar. Bu makalede, aynı çok adımlı formu iki farklı yaklaşımla (RHF+Zod ve SurveyJS) inşa ederek aralarındaki mimari farkları netleştireceğiz.
İlk olarak React Hook Form ve Zod ile bileşen odaklı yaklaşımı ele alalım. Bu yaklaşımda, formun şeklini belirleyen bir Zod şeması oluşturulur. Şema, ad ve e-posta gibi zorunlu alanları tanımlarken, koşullu kurallar (örneğin, 'Hesabınız var mı?' sorusuna 'Evet' yanıtı verildiğinde kullanıcı adı ve şifre alanlarının zorunlu hale gelmesi) 'superRefine' adı verilen bir fonksiyon içinde ele alınır. Bu, Zod'un tür düzeyindeki şemasının yalnızca nesnenin şeklini tanımlayabilmesi, ancak alanların ne zaman önemli olduğunu belirleyen kuralları ifade edememesinden kaynaklanır. superRefine, şema doğrulandıktan sonra tüm nesneye erişerek çapraz alan mantığını uygular. Ancak bu şema, sayfaları, hangi alanların hangi noktada görünür olduğunu veya navigasyonu ifade etmez; tüm bunlar başka bir yerde, genellikle bileşen içinde yönetilir.
Bileşen tarafında, form adımlarını yönetmek için bir 'step' durumu ve her adımda hangi alanların görüneceğini belirlemek için 'useWatch' gibi hook'lar kullanılır. Örneğin, 4 adımlı bir formda: Adım 1'de ad ve e-posta, Adım 2'de birim fiyat, miktar ve vergi oranı (alt toplam, vergi ve toplam otomatik hesaplanır), Adım 3'te hesap durumu ve memnuniyet puanı, Adım 4'te ise yalnızca toplam 100'ün üzerindeyse inceleme ekranı gösterilir. Bu koşullu mantık, bileşen içinde 'useEffect' veya 'useMemo' ile yönetilir ve her adım değiştiğinde form durumu güncellenir. Son adımda, form verileri React Query'nin 'useMutation' hook'u ile API'ye gönderilir. Bu yaklaşım, küçük ve orta ölçekli formlar için idealdir ancak karmaşıklık arttıkça bakımı zorlaşır.
Alternatif olarak, SurveyJS gibi bir kütüphane, formu bir bileşen ağacı yerine bir JSON şeması olarak ele alır. SurveyJS, formun tamamını bir veri yapısı olarak tanımlamanıza olanak tanır; bu yapı, sayfaları, alanları, koşullu kuralları ve hesaplamaları içerir. Örneğin, yukarıdaki form SurveyJS ile şu şekilde tanımlanabilir: Bir JSON nesnesi içinde 'pages' dizisi, her sayfada 'elements' dizisi ve her elementin 'type', 'name', 'title', 'isRequired' gibi özellikleri. Koşullu kurallar, 'visibleIf' alanı ile ifade edilir: örneğin, kullanıcı adı alanı yalnızca 'hasAccount' değeri 'Yes' ise görünür. Hesaplamalar ise 'calculatedValues' ile otomatik olarak yapılır. Adımlar arası geçiş ve nihai gönderim, SurveyJS tarafından otomatik olarak yönetilir. Bu yaklaşım, formun mantığını UI'dan ayırarak daha temiz bir ayrım sağlar ve form şeması kolayca değiştirilebilir veya başka bir yerde yeniden kullanılabilir.
İki yaklaşım arasındaki temel fark, form mantığının nerede yaşadığıdır. RHF+Zod yaklaşımında, form mantığı (koşullar, hesaplamalar, navigasyon) bileşenlerin içine dağılmıştır. Bu, küçük formlar için esneklik sağlarken, büyük ve karmaşık formlarda bakımı zorlaştırır. SurveyJS gibi veri odaklı yaklaşımda ise tüm mantık JSON şeması içinde tanımlanır ve UI tamamen bu şemaya göre oluşturulur. Bu, formun davranışını değiştirmek için bileşen koduna dokunmadan yalnızca şemayı güncellemeniz gerektiği anlamına gelir. Ayrıca, SurveyJS yerleşik olarak adım yönetimi, doğrulama ve gönderim sağlar, bu da geliştirme süresini kısaltır. Ancak, bu yaklaşım daha az esneklik sunar ve özel UI gereksinimleri için sınırlayıcı olabilir.
Teknik Analiz
Peki hangi yaklaşımı ne zaman kullanmalısınız? Kural tabanlı bir karar vermek için şu kriterleri göz önünde bulundurun: Formunuz basit (giriş, ayarlar, CRUD) ve az sayıda koşul içeriyorsa, RHF+Zod gibi bileşen odaklı bir yaklaşım idealdir. Ancak formunuz çok sayıda koşullu alan, hesaplama, dinamik sayfa içeriyorsa veya sık sık değişiyorsa, SurveyJS gibi veri odaklı bir yaklaşım daha uygundur. Ayrıca, form şemasının farklı ortamlarda (örneğin, kullanıcı arayüzü ve arka uç) paylaşılması gerekiyorsa, JSON tabanlı yaklaşım avantaj sağlar. Önemli olan, her iki yaklaşımın da güçlü ve zayıf yönlerini anlamak ve projenizin ihtiyaçlarına göre seçim yapmaktır. React geliştiricileri olarak, formların sadece UI olmadığını, bazen birer kural motoruna dönüştüğünü kabul etmeliyiz. Doğru aracı seçmek, uzun vadede bakım maliyetini düşürür ve uygulamanızın ölçeklenebilirliğini artırır.
Kaynak: smashingmagazine.com
