Angular forms मानक HTML के साथ बहुत अच्छी तरह से काम करते हैं। input, textarea, और select बिना किसी अतिरिक्त प्रयास के Reactive Forms में फिट हो जाते हैं। फ्रेमवर्क उनके events, values और states को समझता है।
लेकिन आधुनिक एप्लिकेशन शायद ही कभी केवल मानक तत्वों (standard elements) से काम चलते हैं। आपको एक star rating widget, एक composite date selector, या एक custom color picker की आवश्यकता हो सकती है। इनमें से किसी एक को form group में डालने पर, Angular उसे एक 'dead HTML' की तरह मानता है। patchValue कुछ नहीं करता। Validators इसे अनदेखा कर देते हैं। फॉर्म को पता ही नहीं चलता कि उपयोगकर्ता control के साथ कब इंटरैक्ट कर रहा है, और form.disable() custom widget को पूरी तरह से interactive छोड़ देता है।
यही वह समस्या है जिसे हल करने के लिए ControlValueAccessor बनाया गया है।
ControlValueAccessor वास्तव में क्या करता है
ControlValueAccessor वह कॉन्ट्रैक्ट (contract) है जो एक custom component को एक 'first-class form citizen' में बदल देता है। यह Angular Forms API और आपके अपने UI के बीच एक अनुवादक (translator) के रूप में कार्य करता है। एक बार जब आप इसे सही ढंग से लागू (implement) कर लेते हैं, तो फॉर्म के दृष्टिकोण से आपका component एक native input से अलग नहीं रह जाता। यह एक built-in element की तरह ही values प्राप्त कर सकता है, changes emit कर सकता है, touches रिपोर्ट कर सकता है, और disabled states का सम्मान कर सकता है।
इस interface के लिए चार विशिष्ट methods की आवश्यकता होती है। प्रत्येक method संचार (communication) की एक अलग दिशा को संभालता है।
writeValue: Form से Component तक
writeValue(obj) इनबाउंड लेन (inbound lane) है। जब भी form model अपडेट होता है और उसे आपके UI में एक नई value भेजनी होती है, तो Angular इस method को कॉल करता है। यदि आप किसी form group पर patchValue({ rating: 4 }) कॉल करते हैं, तो 4 की वह value writeValue के माध्यम से आपके component के अंदर पहुँच जाती है। यदि आप फॉर्म को reset करते हैं, तो writeValue नई initial value या null प्राप्त करता है। इस method के अंदर आपका काम उस आने वाले डेटा को लेना और उसे अपने component की internal state पर मैप करना है। यदि आप एक color picker बना रहे हैं, तो writeValue को #ff4400 जैसी hex string प्राप्त होती है, और आपको उस रंग को selected दिखाने के लिए अपने view को अपडेट करना होगा।
यहाँ एक व्यावहारिक समस्या (practical wrinkle) है। Angular आपके view के पूरी तरह से initialize होने से पहले ही writeValue को कॉल कर सकता है, विशेष रूप से dynamically rendered components, dialogs, या tabbed interfaces के अंदर। यदि आपका component बहुत जल्दी DOM या child components को छूने (touch करने) की कोशिश करता है, तो आपको runtime errors मिल सकते हैं। एक बेहतर तरीका (solid pattern) यह है कि value को एक local property में स्टोर करें और view initialize होने के बाद उसे लागू करें, या undefined child references से बचने के लिए सुरक्षा (guard) लगाएँ। कभी भी यह न मानें कि writeValue केवल तभी चलता है जब आपका template स्थिर (stable) हो।
registerOnChange: Component से Form तक
registerOnChange(fn) आउटबाउंड लेन (outbound lane) सेटअप करता है। Angular आपको एक callback function देता है, और आपको उसका reference रखना चाहिए। हर बार जब उपयोगकर्ता आपके component के अंदर value बदलता है, तो आप उस function को नई value के साथ कॉल करते हैं। एक star rating component में, जब उपयोगकर्ता तीसरे स्टार पर क्लिक करता है, तो आप संग्रहीत (stored) callback को 3 के साथ invoke करते हैं। वह call वापस FormControl में प्रवाहित होती है, model को अपडेट करती है, किसी भी valueChanges subscription को ट्रिगर करती है, और validators को फिर से चलाती है।
इस स्टेप को छोड़ना फॉर्म को चुपचाप खराब करने का सबसे आम तरीका है। Widget जीवित लग सकता है। उपयोगकर्ता को तारे चमकते हुए, रंग बदलते हुए, या तारीखें भरते हुए दिखाई दे सकते हैं। लेकिन form model कभी अपडेट नहीं होता। Validators पुराने (stale) डेटा का मूल्यांकन करना जारी रखते हैं। Submit handlers पुरानी values भेजते हैं। component काम करता हुआ प्रतीत होता है, फिर भी फॉर्म प्रभावी रूप से 'अंधा' (blind) रहता है। यदि आपका custom control उपयोगकर्ता के इनपुट को स्वीकार करता है लेकिन आसपास का फॉर्म उसे कभी नोटिस नहीं करता है, तो लगभग हमेशा यही कारण होता है।
registerOnTouched: Interaction की रिपोर्ट करना
फॉर्म केवल values को ट्रैक नहीं करते हैं। वे यह भी ट्रैक करते हैं कि क्या उपयोगकर्ता ने किसी field के साथ इंटरैक्ट किया है। Angular 'touched state' का उपयोग यह तय करने के लिए करता है कि validation errors दिखाना कब उचित है। एक required text input को पेज लोड होते ही लाल रंग में नहीं चमकना चाहिए। इसे तब तक प्रतीक्षा करनी चाहिए जब तक उपयोगकर्ता tab key दबाकर आगे न बढ़ जाए या कहीं और क्लिक न कर दे।
Native inputs इसे blur events के माध्यम से स्वचालित रूप से संभालते हैं। Custom components ऐसा नहीं करते हैं। आपको इन interactions को स्वयं रिपोर्ट करने के लिए registerOnTouched(fn) का उपयोग करना चाहिए। Angular आपको एक और callback देता है; जब आप तय करते हैं कि उपयोगकर्ता ने control के साथ सार्थक रूप से (meaningfully) जुड़ा है, तब आप इसे कॉल करते हैं।
सटीक समय आपके component पर निर्भर करता है। टेक्स्ट जैसे custom input के लिए, आप इसे blur होने पर कॉल कर सकते हैं। star rating के लिए, पहला क्लिक शायद सही समय है। एक color picker के लिए जो popover खोलता है, आप palette बंद होने तक प्रतीक्षा कर सकते हैं। मुख्य बात निरंतरता (consistency) है। यदि आप कभी भी touched callback को कॉल नहीं करते हैं, तो Angular control को 'pristine' के रूप में चिह्नित करना जारी रखता है। उपयोगकर्ता द्वारा एडिटिंग पूरी करने के बाद भी validation errors छिपे रहते हैं। इससे भ्रम और खराब user experience होता है।
setDisabledState: फॉर्म कमांड्स का पालन करना
डायनामिक फॉर्म्स बिजनेस लॉजिक के आधार पर लगातार फील्ड्स को इनेबल (enable) और डिसेबल (disable) करते रहते हैं। जब आप FormControl पर .disable() कॉल करते हैं, तो Angular को उम्मीद होती है कि आपका कस्टम कंपोनेंट भी उस पर प्रतिक्रिया दे। setDisabledState(isDisabled) एक boolean प्राप्त करता है। जब यह true हो, तो आपको अपने UI को लॉक कर देना चाहिए।
इसका मतलब सिर्फ क्लिक्स को इग्नोर करना नहीं है। आपको इंटरनल बटन्स को डिसेबल करना चाहिए, फोकस करने योग्य (focusable) स्टेट्स को हटाना चाहिए, और कम ओपेसिटी (reduced opacity) या pointer-events: none जैसे विजुअल ट्रीटमेंट्स लागू करने चाहिए। यदि आप इस मेथड को इग्नोर करते हैं, तो आपका कंपोनेंट पूरी तरह से इंटरैक्टिव बना रहता है जबकि फॉर्म मॉडल यह दावा करता है कि वह डिसेबल है। इससे ऐसे बग्स पैदा होते हैं जिन्हें ट्रैक करना मुश्किल होता है। यूजर्स उन वैल्यूज को बदल सकते हैं जिन्हें फॉर्म को रिजेक्ट करना चाहिए था। सेव बटन्स अमान्य (invalid) स्टेट्स के आधार पर इनेबल हो सकते हैं। फॉर्म ग्रुप और UI एक-दूसरे से अलग हो जाते हैं।
एक अच्छी तरह से बनाया गया कस्टम कंट्रोल setDisabledState को एक प्राथमिक आवश्यकता (first-class requirement) मानता है, न कि बाद में सोचा गया कोई काम।
गलतियाँ जो आपका डिबगिंग समय बर्बाद करेंगी
इस इंटरफ़ेस से नए डेवलपर्स अक्सर कुछ दोहराई जाने वाली गलतियाँ करते हैं।
change callback को कॉल करना भूल जाना। आपका कंपोनेंट अपनी इंटरनल स्टेट को अपडेट करता है, लेकिन फॉर्म को इसकी जानकारी नहीं मिल पाती। Validators रुक जाते हैं, और पैरेंट फॉर्म पुराना (stale) डेटा सबमिट कर देते हैं। जैसे ही यूजर कोई नई वैल्यू दर्ज करे, हमेशा उस स्टोर किए गए onChange फंक्शन को कॉल करें।
touched callback को छोड़ देना। इसके बिना, Angular कंट्रोल को कभी भी 'touched' के रूप में मार्क नहीं करता है। touched या dirty स्टेट्स से जुड़े एरर मैसेज दिखाई नहीं देते। यूजर्स एक ऐसे फॉर्म को देखते रह जाते हैं जो सही लगता है लेकिन सबमिट नहीं होता, और उन्हें यह भी पता नहीं चलता कि क्या गलत है।
disabled state की अनदेखी करना। एक विजुअली इनेबल कंट्रोल जिसे फॉर्म डिसेबल समझता है, वह भरोसे की सीमा (trust boundary) को तोड़ देता है। यूजर टाइप करना या क्लिक करना जारी रख सकता है, लेकिन मॉडल उन्हें इग्नोर कर देता है। या इससे भी बुरा यह कि मॉडल सिंक साइकिल के दौरान उनके इनपुट को बीच-बीच में ओवरराइट कर देता है।
NG_VALUE_ACCESSOR provider को छोड़ देना। यह एक 'साइलेंट किलर' है। यदि आप चारों मेथड्स को लागू करते हैं लेकिन अपने कंपोनेंट के providers एरे में NG_VALUE_ACCESSOR जोड़ना भूल जाते हैं, तो Angular आपके कंपोनेंट को कभी भी वैल्यू एक्सेसॉर के रूप में रजिस्टर नहीं करता है। कोड कंपाइल हो जाता है। व्यू रेंडर हो जाता है। लेकिन कुछ भी बाइंड नहीं होता। कोई एरर मैसेज नहीं आता, बस एक कंपोनेंट होता है जो पूरी तरह से फॉर्म के बाहर तैरता रहता है। इसे हमेशा डेकोरेटर मेटाडेटा (decorator metadata) में शामिल करें।
Signals, Validators, और Modern Angular
ControlValueAccessor कोई पुराना (legacy) API सरफेस नहीं है। यह आधुनिक Angular डेवलपमेंट में पूरी तरह फिट बैठता है। चाहे आप इंटरनल स्टेट को Signals, प्लेन प्रॉपर्टीज, या RxJS subjects के साथ मैनेज करें, ये चारों मेथड्स फॉर्म्स मॉड्यूल के साथ आपका पब्लिक कॉन्ट्रैक्ट बने रहते हैं। आप writeValue में वैल्यूज का उपयोग करते हैं, अपने Signals या स्टेट को बदलते हैं, और Angular द्वारा दिए गए कॉलबैक्स के माध्यम से उन्हें एमिट (emit) करते हैं।
स्टैंडर्ड Validators बिना किसी बदलाव के काम करते हैं। Validators.required, Validators.min, Validators.pattern, और कस्टम क्रॉस-फील्ड Validators, आपके CVA-बैक्ड कंपोनेंट का मूल्यांकन ठीक वैसे ही करते हैं जैसे वे किसी नेटिव इनपुट का करते हैं। फॉर्म कंट्रोल एक वैल्यू और एक स्टेट देखता है। उसे इससे फर्क नहीं पड़ता कि वह वैल्यू किसी टेक्स्ट बॉक्स से आई है या किसी हाथ से बनाए गए मंथ-पिकर (month-picker) से।
यही पोर्टेबिलिटी (portability) कारण है कि डिजाइन सिस्टम और शेयर की गई UI लाइब्रेरीज़ के लिए CVA महत्वपूर्ण है। एक टीम एक मजबूत फोन-नंबर इनपुट या फाइल अपलोड विजेट बनाती है। वे इंटरफ़ेस को एक बार लागू करते हैं। संगठन की हर दूसरी टीम बिना किसी अतिरिक्त वायरिंग के इसे अपने Reactive Forms में इस्तेमाल कर सकती है। कंपोनेंट प्रेडिक्टेबल तरीके से व्यवहार करता है, यूनिफॉर्मली वैलिडेट करता है, और हर फीचर मॉड्यूल में कंसिस्टेंटली डिसेबल होता है।
असली निष्कर्ष
ControlValueAccessor सिर्फ इंटरव्यू के सवालों के लिए याद करने वाला एक और इंटरफ़ेस नहीं है। यह वह पुल है जो आपके कस्टम कंपोनेंट्स को नेटिव HTML एलिमेंट्स के बराबर Angular के फॉर्म इकोसिस्टम में भाग लेने की अनुमति देता है। इसमें महारत हासिल करने का मतलब है अपने विजेट और फॉर्म के बीच होने वाली पूरी बातचीत को समझना: वैल्यूज प्राप्त करना, बदलावों की रिपोर्ट करना, टच (touches) की घोषणा करना और डिसेबल स्टेट्स का सम्मान करना। यदि आप इन चार चीजों को सही ढंग से कर लेते हैं, तो आप जटिल, पुन: प्रयोज्य (reusable) फॉर्म कंट्रोल्स बना सकते हैं जो उन्हें इस्तेमाल करने वाले डेवलपर्स के लिए अदृश्य महसूस होते हैं। यही एक प्रोफेशनल Angular कंपोनेंट की पहचान है।