Angular’\u0131n form y\u00f6netimi, geli\u015ftiricilere g\u00fc\u00e7l\u00fc ve esnek ara\u00e7lar sunarak kullan\u0131c\u0131 etkile\u015fimli uygulamalar\u0131n temelini olu\u015fturur. Sinyallerin (Signals) Angular ekosistemine entegrasyonuyla birlikte, form y\u00f6netimi de Angular, uzun y\u0131llard\u0131r reaktif ve \u015fablon tabanl\u0131 formlar olmak \u00fczere iki ana form y\u00f6netim stratejisi sunmaktad\u0131r. Ancak sinyallerin geli\u015fiyle birlikte, form y\u00f6netiminde daha modern, tip g\u00fcvenli ve performans odakl\u0131 bir yakla\u015f\u0131m benimsendi.<\/p>\n Geleneksel Angular formlar\u0131, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k formlarda baz\u0131 zorluklar bar\u0131nd\u0131rabiliyordu. De\u011fi\u015fiklik alg\u0131lama mekanizmas\u0131, form de\u011ferlerinin ve durumlar\u0131n\u0131n takibi, \u00f6zellikle i\u00e7 i\u00e7e ge\u00e7mi\u015f form gruplar\u0131nda bazen performans sorunlar\u0131na yol a\u00e7abiliyordu. Ayr\u0131ca, tip g\u00fcvenli\u011fi konusunda baz\u0131 esneklikler, beklenmedik hatalara zemin haz\u0131rlayabiliyordu.<\/p>\n Angular Sinyalleri, uygulaman\u0131n durumunu y\u00f6netmek i\u00e7in yeni ve g\u00fc\u00e7l\u00fc bir mekanizma sunar. Bir sinyal, de\u011feri de\u011fi\u015fti\u011finde ba\u011f\u0131ml\u0131 t\u00fcm hesaplamalar\u0131 veya g\u00f6r\u00fcn\u00fcmleri otomatik olarak g\u00fcncelleyen bir de\u011fer ta\u015f\u0131y\u0131c\u0131s\u0131d\u0131r. Signal Formlar\u0131, bu reaktif yap\u0131y\u0131 form kontrollerine, gruplar\u0131na ve dizilerine entegre ederek, form durumlar\u0131n\u0131n daha verimli ve \u00f6ng\u00f6r\u00fclebilir bir \u015fekilde y\u00f6netilmesini sa\u011flar. Her bir form kontrol\u00fc art\u0131k bir sinyal olarak i\u015flev g\u00f6r\u00fcr, bu da de\u011fi\u015fikliklerin an\u0131nda ve optimize edilmi\u015f bir \u015fekilde yay\u0131lmas\u0131n\u0131 m\u00fcmk\u00fcn k\u0131lar.<\/p>\n Web formlar\u0131nda say\u0131 giri\u015fi, kullan\u0131c\u0131dan say\u0131sal veri almak i\u00e7in kritik bir elemand\u0131r. Ancak bu basit g\u00f6r\u00fcnen eleman, arkas\u0131nda baz\u0131 teknik detaylar ve potansiyel tuzaklar bar\u0131nd\u0131r\u0131r.<\/p>\n HTML5 ile gelen JavaScript’te dize ve say\u0131 d\u00f6n\u00fc\u015f\u00fcmleri olduk\u00e7a yayg\u0131nd\u0131r. <\/code><\/p>\n Geleneksel Angular reaktif formlar\u0131nda, Signal Formlar\u0131'n\u0131n ilk s\u00fcr\u00fcmlerinde, Signal Formlar\u0131, tip g\u00fcvenli\u011fine b\u00fcy\u00fck \u00f6nem verir. Bir Signal Formlar\u0131'ndaki Bir <\/code><\/p>\n Bu sorun, kullan\u0131c\u0131 deneyimini olumsuz etkiliyordu. Kullan\u0131c\u0131lar bir say\u0131 giri\u015fini bo\u015f b\u0131rakt\u0131\u011f\u0131nda veya ge\u00e7ersiz bir de\u011fer girdi\u011finde, formun beklendi\u011fi gibi davranmamas\u0131, hata mesajlar\u0131n\u0131n d\u00fczg\u00fcn g\u00f6r\u00fcnt\u00fclenmemesi veya formun g\u00f6nderilememesi gibi durumlarla kar\u015f\u0131la\u015f\u0131yorlard\u0131. Geli\u015ftiriciler i\u00e7in ise bu, formlar\u0131 Signal Formlar\u0131 ile olu\u015ftururken Say\u0131 giri\u015fi sorununu daha iyi anlamak i\u00e7in Angular'\u0131n form mekanizmas\u0131n\u0131n ve DOM ile etkile\u015fiminin derinliklerine inmek gerekir.<\/p>\n Daha \u00f6nce belirtildi\u011fi gibi, HTML Angular formlar\u0131, DOM elemanlar\u0131 ile Signal Formlar\u0131'nda Senaryo \u015fu \u015fekilde i\u015fliyordu:<\/p>\n Bu durum, Angular ekibi, topluluktan gelen geri bildirimler \u00fczerine bu kritik sorunu h\u0131zla ele ald\u0131 ve Signal Formlar\u0131'ndaki say\u0131 giri\u015fi deneyimini d\u00fczeltmek i\u00e7in \u00f6nemli iyile\u015ftirmeler yapt\u0131.<\/p>\n Geli\u015ftiricilerin ya\u015fad\u0131\u011f\u0131 sorunlar, Angular GitHub depolar\u0131nda ve forumlarda yo\u011fun bir \u015fekilde tart\u0131\u015f\u0131ld\u0131. Angular ekibi, bu geri bildirimleri dikkate alarak, Signal Formlar\u0131'n\u0131n temel felsefesini korurken, pratik kullan\u0131m senaryolar\u0131nda ortaya \u00e7\u0131kan bu t\u00fcr uyumsuzluklar\u0131 gidermek i\u00e7in \u00e7al\u0131\u015fmalara ba\u015flad\u0131. Ama\u00e7, tip g\u00fcvenli\u011fini s\u00fcrd\u00fcrmek ancak geli\u015ftiricilerin yayg\u0131n HTML form elemanlar\u0131yla sorunsuz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamakt\u0131.<\/p>\n \u00c7\u00f6z\u00fcm, Bu sayede, Yap\u0131lan bu d\u00fczeltmeler, Signal Formlar\u0131'n\u0131n temel tip g\u00fcvenli\u011fi prensibinden \u00f6d\u00fcn vermedi. Aksine, DOM ile Angular form kontrol\u00fc aras\u0131ndaki aray\u00fczde daha ak\u0131ll\u0131 bir d\u00f6n\u00fc\u015f\u00fcm katman\u0131 ekleyerek, tip g\u00fcvenli\u011fini korurken geli\u015ftiricilere daha fazla esneklik sa\u011flad\u0131. Geli\u015ftiriciler art\u0131k \u00d6zellikle bo\u015f say\u0131 giri\u015flerinin Yap\u0131lan iyile\u015ftirmeler sayesinde, Angular Signal Formlar\u0131'nda say\u0131 giri\u015fleriyle \u00e7al\u0131\u015fmak art\u0131k sorunsuz ve beklenen \u015fekilde i\u015fliyor. Geli\u015ftiriciler, tip g\u00fcvenli\u011finden \u00f6d\u00fcn vermeden, modern form y\u00f6netiminin avantajlar\u0131ndan tam olarak yararlanabilirler.<\/p>\n Angular'\u0131n yeni versiyonlar\u0131yla birlikte (genellikle v17.1 ve sonras\u0131), Signal Formlar\u0131'ndaki \u0130\u015fte Signal Formlar\u0131 ile sorunsuz bir say\u0131 giri\u015fi \u00f6rne\u011fi:<\/p>\nSignal Forms<\/code> ad\u0131 alt\u0131nda yenilik\u00e7i bir d\u00f6n\u00fc\u015f\u00fcm ge\u00e7irdi. Bu yeni yakla\u015f\u0131m, form durumlar\u0131n\u0131 daha reaktif ve performansl\u0131 bir \u015fekilde y\u00f6netme vaadiyle geldi. Ancak, ilk a\u015famalarda \u00f6zellikle say\u0131 giri\u015fleri (input type=\"number\"<\/code>) beklenmedik sorunlara yol a\u00e7arak geli\u015ftiriciler aras\u0131nda kafa kar\u0131\u015f\u0131kl\u0131\u011f\u0131na neden oldu. Bu makalede, Signal Formlar\u0131’n\u0131n say\u0131 giri\u015fleriyle olan ilk uyumsuzlu\u011funu, bu sorunun teknik nedenlerini ve Angular ekibinin bu “k\u0131r\u0131k” deneyimi nas\u0131l kusursuz bir hale getirdi\u011fini detayl\u0131 bir \u015fekilde inceleyece\u011fiz.<\/p>\nAngular Signal Formlar\u0131’na K\u0131sa Bir Bak\u0131\u015f<\/h3>\n
Geleneksel Form Y\u00f6netimi ve Zorluklar\u0131<\/h4>\n
Sinyallerin Form Y\u00f6netimine Entegrasyonu<\/h4>\n
Yeni Yakla\u015f\u0131m\u0131n Avantajlar\u0131<\/h4>\n
\n
Say\u0131 Giri\u015flerinin Temel \u0130\u015fleyi\u015fi ve Zorluklar<\/h3>\n
HTML
input type=\"number\"<\/code> Davran\u0131\u015f\u0131<\/h4>\n<\/code> eleman\u0131, taray\u0131c\u0131 d\u00fczeyinde say\u0131sal giri\u015fleri kolayla\u015ft\u0131rmak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu eleman, genellikle art\u0131rma\/azaltma oklar\u0131 (spin button) sunar ve metin d\u0131\u015f\u0131 karakter giri\u015fini engellemeye \u00e7al\u0131\u015f\u0131r. Ancak \u00f6nemli bir detay \u015fudur: bu eleman\u0131n value<\/code> \u00f6zelli\u011fi her zaman bir dize (string) d\u00f6nd\u00fcr\u00fcr.<\/strong> Kullan\u0131c\u0131 bir say\u0131 girse bile, DOM’dan okundu\u011funda bu de\u011fer bir dize olarak gelir. E\u011fer giri\u015f bo\u015fsa, \"\"<\/code> (bo\u015f dize) d\u00f6nd\u00fcr\u00fcr.<\/p>\nJavaScript’in Say\u0131 Y\u00f6netimi<\/h4>\n
parseInt()<\/code>, parseFloat()<\/code> gibi fonksiyonlar veya unary art\u0131 operat\u00f6r\u00fc (+<\/code>) dizeyi say\u0131ya d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in kullan\u0131l\u0131r. Ancak, bo\u015f dizeyi (\"\"<\/code>) say\u0131ya d\u00f6n\u00fc\u015ft\u00fcrmeye \u00e7al\u0131\u015fmak 0<\/code> sonucunu verirken, ge\u00e7erli bir say\u0131 olmayan bir dizeyi d\u00f6n\u00fc\u015ft\u00fcrmek NaN<\/code> (Not-a-Number) sonucunu do\u011furur. Bu durum, form y\u00f6netiminde dikkatli olunmas\u0131 gereken bir noktad\u0131r.<\/p>\n\nconsole.log(+\"123\"); \/\/ 123 (number)\nconsole.log(+\"\"); \/\/ 0 (number)\nconsole.log(+\"abc\"); \/\/ NaN (number)\n<\/pre>\nGeleneksel Angular Formlar\u0131nda Say\u0131 Giri\u015fleri<\/h4>\n
<\/code> ile \u00e7al\u0131\u015fmak genellikle sorunsuzdu. Angular'\u0131n DefaultValueAccessor<\/code> veya \u00f6zel ControlValueAccessor<\/code>'lar\u0131, DOM'dan gelen dize de\u011ferlerini otomatik olarak number<\/code> tipine d\u00f6n\u00fc\u015ft\u00fcrme veya null<\/code> olarak i\u015fleme konusunda daha esnek davran\u0131yordu. Bu sayede, geli\u015ftiriciler genellikle type=\"number\"<\/code> giri\u015flerinden gelen de\u011ferleri do\u011frudan say\u0131 olarak kullanabiliyorlard\u0131, bo\u015f de\u011ferler ise genellikle null<\/code> veya undefined<\/code> olarak kabul ediliyordu.<\/p>\nSignal Formlar\u0131 ve Say\u0131 Giri\u015flerindeki \u0130lk Sorun: Neden K\u0131r\u0131ld\u0131?<\/h3>\n
<\/code> elemanlar\u0131yla ilgili ciddi bir uyumsuzluk ya\u015fand\u0131. Bu durum, geli\u015ftiricilerin formlar\u0131nda say\u0131sal giri\u015fleri kullanmas\u0131n\u0131 neredeyse imkans\u0131z hale getirdi.<\/p>\nFormControl<\/code>'\u00fcn value<\/code> Tipi ve number<\/code> Giri\u015fleri<\/h4>\nFormControl<\/code> tan\u0131mlarken, beklenen de\u011fer tipini belirtiriz. \u00d6rne\u011fin, new FormControlnull<\/code> olmas\u0131n\u0131 bekledi\u011fi anlam\u0131na gelir. Ancak, <\/code> eleman\u0131ndan gelen de\u011fer her zaman bir dizedir (string<\/code>). Kullan\u0131c\u0131 bir say\u0131 girse bile, DOM'dan gelen de\u011fer \"123\"<\/code> gibi bir dizeydi. E\u011fer giri\u015f bo\u015f b\u0131rak\u0131l\u0131rsa, \"\"<\/code> (bo\u015f dize) geliyordu.<\/p>\nSinyallerin Tip G\u00fcvenli\u011fi ve Otomatik D\u00f6n\u00fc\u015f\u00fcm<\/h4>\n
FormControl<\/code>, ald\u0131\u011f\u0131 de\u011ferin belirtilen tiple e\u015fle\u015fmesini bekliyordu. Geleneksel formlar\u0131n aksine, sinyal tabanl\u0131 yakla\u015f\u0131mlar tip d\u00f6n\u00fc\u015f\u00fcmlerinde daha kat\u0131yd\u0131. string<\/code> bir de\u011ferin do\u011frudan number<\/code> tipine atanmas\u0131, tip uyu\u015fmazl\u0131\u011f\u0131na yol a\u00e7\u0131yordu. Bo\u015f dize (\"\"<\/code>) durumunda ise, bu dizeyi bir say\u0131ya d\u00f6n\u00fc\u015ft\u00fcrme giri\u015fimi ba\u015far\u0131s\u0131z oluyor veya beklenmedik bir \u015fekilde 0<\/code>'a d\u00f6n\u00fc\u015f\u00fcyordu. Oysa \u00e7o\u011fu zaman, bo\u015f bir say\u0131 giri\u015finin kar\u015f\u0131l\u0131\u011f\u0131 null<\/code> olmal\u0131d\u0131r.<\/p>\nBo\u015f De\u011ferler ve
null<\/code>\/undefined<\/code> Sorunu<\/h4>\n<\/code> eleman\u0131 bo\u015f b\u0131rak\u0131ld\u0131\u011f\u0131nda, DOM value<\/code> \u00f6zelli\u011fini \"\"<\/code> (bo\u015f dize) olarak d\u00f6nd\u00fcr\u00fcr. Signal Formlar\u0131'ndaki FormControl\n\/\/ Sorunlu senaryo (ilk versiyonlarda)\nconst quantityControl = new FormControlKullan\u0131c\u0131 Deneyimi \u00dczerindeki Etkileri<\/h4>\n
type=\"number\"<\/code> kullan\u0131m\u0131ndan ka\u00e7\u0131nma veya her seferinde \u00f6zel \u00e7\u00f6z\u00fcmler \u00fcretme anlam\u0131na geliyordu.<\/p>\nSorunun Derinlemesine Analizi ve Teknik Detaylar<\/h3>\n
Input<\/code> Eleman\u0131n\u0131n value<\/code> \u00d6zelli\u011fi<\/h4>\n<\/code> eleman\u0131n\u0131n value<\/code> \u00f6zelli\u011fi, type<\/code> ne olursa olsun her zaman bir dize d\u00f6nd\u00fcr\u00fcr. Bu, web standartlar\u0131n\u0131n bir par\u00e7as\u0131d\u0131r ve Angular'\u0131n do\u011frudan m\u00fcdahale edemeyece\u011fi bir davran\u0131\u015ft\u0131r. Angular, bu dize de\u011feri al\u0131p uygulama mant\u0131\u011f\u0131na uygun tipe d\u00f6n\u00fc\u015ft\u00fcrmekten sorumludur.<\/p>\nAngular'\u0131n
valueAccessor<\/code> Mekanizmas\u0131<\/h4>\nFormControl<\/code> aras\u0131nda bir k\u00f6pr\u00fc g\u00f6revi g\u00f6ren ControlValueAccessor<\/code> ad\u0131 verilen bir mekanizma kullan\u0131r. Her farkl\u0131 input<\/code> tipi (metin, say\u0131, onay kutusu vb.) veya \u00f6zel bile\u015fen i\u00e7in bir ControlValueAccessor<\/code> bulunur. Bu eri\u015fimciler, DOM'dan gelen de\u011ferleri okur ve FormControl<\/code>'e iletir; ayn\u0131 \u015fekilde, FormControl<\/code>'den gelen de\u011ferleri de DOM eleman\u0131na yazar. type=\"number\"<\/code> i\u00e7in varsay\u0131lan bir ControlValueAccessor<\/code> vard\u0131r.<\/p>\nSignal Formlar\u0131'ndaki
FormControl<\/code>'\u00fcn \u0130\u00e7 Yap\u0131s\u0131<\/h4>\nFormControl<\/code>, i\u00e7 de\u011ferini bir sinyal olarak tutar. Bu sinyal, tip g\u00fcvenli\u011fini daha s\u0131k\u0131 bir \u015fekilde uygular. Geleneksel formlarda, FormControl<\/code>'\u00fcn value<\/code> \u00f6zelli\u011fi genellikle any<\/code> veya daha esnek tiplere izin verebilirken, Signal Forms'da tip parametresi (\u00f6rne\u011fin ControlValueAccessor<\/code>'dan gelen string<\/code> de\u011ferinin do\u011frudan sinyale atanmaya \u00e7al\u0131\u015f\u0131ld\u0131\u011f\u0131nda tip uyu\u015fmazl\u0131\u011f\u0131na yol a\u00e7t\u0131\u011f\u0131 temel nedendi.<\/p>\nTip Uyu\u015fmazl\u0131\u011f\u0131 ve Hata Senaryolar\u0131<\/h4>\n
\n
<\/code> eleman\u0131na bir de\u011fer girer (\u00f6rne\u011fin \"123\") veya bo\u015f b\u0131rak\u0131r (\"\").<\/li>\nControlValueAccessor<\/code>, bu dizeyi al\u0131r.<\/li>\nFormControl<\/code>, bu dizeyi do\u011frudan number | null<\/code> tipindeki i\u00e7 sinyaline atamaya \u00e7al\u0131\u015f\u0131r.<\/li>\n\"\"<\/code>) geldi\u011finde ve bu dize 0<\/code>'a d\u00f6n\u00fc\u015ft\u00fcr\u00fcld\u00fc\u011f\u00fcnde, kontrol\u00fcn null<\/code> olmas\u0131n\u0131 bekleyen geli\u015ftirici i\u00e7in bu bir sorun te\u015fkil eder. En k\u00f6t\u00fcs\u00fc, tip sisteminin bu d\u00f6n\u00fc\u015f\u00fcm\u00fc kabul etmemesi ve hata f\u0131rlatmas\u0131d\u0131r.<\/li>\n<\/ol>\nFormControl<\/code>'\u00fcn value<\/code> sinyalinin her zaman belirtilen tipte bir de\u011fer tutmas\u0131n\u0131 sa\u011flamaya \u00e7al\u0131\u015fan kat\u0131 tip kontrol\u00fc ile DOM'dan gelen dize de\u011ferleri aras\u0131ndaki uyumsuzluktan kaynaklan\u0131yordu.<\/p>\n\u00c7\u00f6z\u00fcme Giden Yol: Yap\u0131lan \u0130yile\u015ftirmeler<\/h3>\n
Angular Ekibinin M\u00fcdahalesi ve Topluluk Geri Bildirimleri<\/h4>\n
number<\/code> Giri\u015fleri \u0130\u00e7in \u00d6zel \u0130\u015fleyiciler<\/h4>\ntype=\"number\"<\/code> i\u00e7in \u00f6zel bir ControlValueAccessor<\/code> veya mevcut eri\u015ficinin davran\u0131\u015f\u0131nda yap\u0131lan bir iyile\u015ftirme ile geldi. Bu iyile\u015ftirme, DOM'dan gelen dize de\u011ferini daha ak\u0131ll\u0131ca i\u015flemeyi i\u00e7eriyordu:<\/p>\n\n
\"\"<\/code>), bunu null<\/code> olarak kabul et.<\/li>\n\"123\"<\/code>), bunu number<\/code> tipine d\u00f6n\u00fc\u015ft\u00fcr (123<\/code>).<\/li>\n\"abc\"<\/code>), bu durumu uygun \u015fekilde y\u00f6net (\u00f6rne\u011fin null<\/code> veya NaN<\/code> olarak, ancak genellikle null<\/code> tercih edilir).<\/li>\n<\/ul>\nFormControlnumber | null<\/code> de\u011ferini alabiliyordu, b\u00f6ylece tip uyu\u015fmazl\u0131\u011f\u0131 sorunu ortadan kalkt\u0131.<\/p>\nTip G\u00fcvenli\u011fini Korurken Esneklik Sa\u011flama<\/h4>\n
FormControl<\/code>'lerini number | null<\/code> olarak g\u00fcvenle tan\u0131mlayabiliyor ve type=\"number\"<\/code> giri\u015fleriyle sorunsuz \u00e7al\u0131\u015fabiliyorlard\u0131.<\/p>\nnull<\/code> ve undefined<\/code> De\u011ferlerinin Y\u00f6netimi<\/h4>\nnull<\/code> olarak i\u015flenmesi, bu \u00e7\u00f6z\u00fcm\u00fcn en \u00f6nemli par\u00e7alar\u0131ndan biriydi. Bu, hem tip g\u00fcvenli\u011fi a\u00e7\u0131s\u0131ndan do\u011fruydu hem de \u00e7o\u011fu i\u015f mant\u0131\u011f\u0131 senaryosunda bo\u015f bir say\u0131 giri\u015finin \"hi\u00e7bir de\u011fer girilmedi\" anlam\u0131na gelmesi beklentisini kar\u015f\u0131l\u0131yordu. Bu sayede, FormControl<\/code>'\u00fcn value<\/code> sinyali, kullan\u0131c\u0131 giri\u015fi bo\u015f oldu\u011funda null<\/code> de\u011ferini ta\u015f\u0131yarak, formun ge\u00e7erlilik durumunu ve modelini do\u011fru bir \u015fekilde yans\u0131tabiliyordu.<\/p>\nArt\u0131k Kusursuz: G\u00fcncel Durum ve Kullan\u0131m<\/h3>\n
Yeni Davran\u0131\u015f\u0131n Test Edilmesi<\/h4>\n
type=\"number\"<\/code> giri\u015flerinin davran\u0131\u015f\u0131 d\u00fczeltildi. Art\u0131k bir FormControl\n
number<\/code> tipi) olur.<\/li>\nnull<\/code> olur.<\/li>\nnull<\/code> olur.<\/li>\n<\/ul>\nKod \u00d6rnekleri: Sorunsuz Say\u0131 Giri\u015fleri<\/h4>\n
\nimport { Component } from '@angular\/core';\nimport { FormControl, ReactiveFormsModule } from '@angular\/forms';\nimport { JsonPipe } from '@angular\/common';\n\n@Component({\n selector: 'app-number-input-example',\n standalone: true,\n imports: [ReactiveFormsModule, JsonPipe],\n template: Say\u0131 Giri\u015fi \u00d6rne\u011fi<\/h3>\n