फ्रंटएंड इंटरव्यू: आप एक्सेसिबल फ़ॉर्म वैलिडेशन और एरर रिकवरी कैसे बनाते हैं?

प्रॉम्प्ट और लागू संदर्भ

ईमेल, देश, पोस्टल कोड, डिलीवरी की तारीख और एक वैकल्पिक डिस्काउंट कोड वाले चेकआउट फ़ॉर्म के लिए वैलिडेशन फ़्लो बनाएं। पोस्टल कोड के नियम देश पर निर्भर करते हैं। डिस्काउंट कोड की जाँच एक रिमोट सर्विस द्वारा की जाती है। कीमतों, स्टॉक, पते के नियमों और कोड की वैधता के लिए सर्वर ही आधिकारिक (authoritative) रहेगा।

फ़ॉर्म को कीबोर्ड और असिस्टिव टेक्नोलॉजी के साथ, 200% ज़ूम पर और सर्वर राउंड ट्रिप के बाद भी ठीक से काम करना चाहिए। त्रुटियों (errors) को केवल रंग के माध्यम से नहीं दर्शाया जा सकता है। एक असफल सबमिशन को दर्ज किए गए मानों (values) को सुरक्षित रखना चाहिए, प्रत्येक कार्रवाई योग्य त्रुटि की पहचान करनी चाहिए और रिकवरी का सीधा रास्ता प्रदान करना चाहिए। नेटवर्क विफलता, एक समाप्त (expired) हो चुका कोड और पुराने रिस्पॉन्स से आगे निकलने वाला नया एसिंक रिस्पॉन्स इस समस्या का हिस्सा हैं।

उद्देश्य कोई नई फ़ॉर्म लाइब्रेरी बनाना नहीं है। उत्तर में स्टेट, वैलिडेशन टाइमिंग, सिमेंटिक संबंध, फ़ोकस नीति और क्लाइंट-सर्वर एरर कॉन्ट्रैक्ट को परिभाषित किया जाना चाहिए, फिर यह दिखाया जाना चाहिए कि उन निर्णयों को कैसे सत्यापित किया जाता है। नेटिव HTML कंस्ट्रेंट्स आधार रेखा (baseline) हैं; कस्टम व्यवहार को ब्राउज़र सिमेंटिक्स को हटाए बिना स्पष्टता जोड़नी चाहिए।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत ज़िम्मेदारी का है। क्लाइंट वैलिडेशन तेज़ फ़ीडबैक देता है और अनावश्यक रिक्वेस्ट्स से बचाता है। सर्वर वैलिडेशन यह तय करता है कि कोई ऑर्डर स्वीकार किया जाए या नहीं। एक उम्मीदवार जो क्लाइंट-साइड required एट्रिब्यूट या डिस्काउंट टोटल पर भरोसा करता है, वह सुरक्षा और शुद्धता में एक कमी छोड़ देता है।

दूसरा संकेत डिटेक्शन नहीं, बल्कि रिकवरी है। केवल एक इनवैलिड बॉर्डर अपर्याप्त है। प्रत्येक एरर को सादे टेक्स्ट (plain text), अपने कंट्रोल के साथ एक प्रोग्रामेटिक संबंध और सुधार के निर्देश की आवश्यकता होती है। सबमिशन पर, यूज़र्स को एक ओवरव्यू और फ़ोकस के लिए एक अनुमानित स्थान की आवश्यकता होती है। उनका मान्य इनपुट बरकरार रहना चाहिए।

तीसरा संकेत टाइमिंग है। जब कोई यूज़र अभी भी ईमेल टाइप कर रहा हो, तब "इनवैलिड" दिखाना अनचाहा शोर (noise) पैदा करता है। पहले सबमिट पर वैलिडेट करें; किसी फ़ील्ड के विफल होने के बाद, उसे ब्लर (blur) या सार्थक बदलाव पर फिर से वैलिडेट करें ताकि यूज़र देख सके कि सुधार ने काम किया। एसिंक वैलिडेशन के लिए एक पेंडिंग स्टेट और पुराने रिस्पॉन्स से सुरक्षा की आवश्यकता होती है।

अंतिम संकेत सत्यापन (verification) है। एक स्वचालित एक्सेसिबिलिटी स्कैन छूटे हुए लेबल्स ढूंढ सकता है, लेकिन यह उचित घोषणाओं (sensible announcements), फ़ोकस क्रम, सर्वर रिस्पॉन्स के बाद रिकवरी, या क्रम से बाहर आए डिस्काउंट-कोड रिस्पॉन्स से सुरक्षा को साबित नहीं कर सकता। इनके लिए इंटरैक्शन टेस्ट्स की आवश्यकता होती है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• कौन से चेक्स लोकल हैं? उपस्थिति (presence), फ़ॉर्मेट और सरल क्रॉस-फ़ील्ड नियम स्थानीय रूप से चल सकते हैं। कीमत, स्टॉक, पात्रता और अंतिम डिस्काउंट की वैधता सर्वर के स्वामित्व में हैं।
• फ़ीडबैक कब दिखना चाहिए? सबमिट करने पर सभी ब्लॉकिंग एरर्स सामने आ जाते हैं। एक फ़ील्ड जो पहले ही विफल हो चुकी है, वह ब्लर होने पर या किसी जानबूझकर किए गए बदलाव के बाद पुनः वैलिडेट हो सकती है; प्रत्येक कीस्ट्रोक पर घोषणा न करें।
• क्या सर्वर पेज को फिर से रेंडर करेगा? संवर्धित (enhanced) और सामान्य दोनों फ़ॉर्म सबमिशन को मानों को सुरक्षित रखना चाहिए और समान संरचित त्रुटियों को रेंडर करना चाहिए।
• क्या एक त्रुटि कई कंट्रोल्स को प्रभावित कर सकती है? देश और पोस्टल कोड मिलकर एक नियम बनाते हैं। साझा निर्देशों को ग्रुप के पास रखें और समरी को उस कंट्रोल से लिंक करें जो सुधार शुरू करता है।
• डिस्काउंट वैलिडेशन के दौरान क्या होता है? इसकी पेंडिंग स्थिति सूचनात्मक है, कोई त्रुटि नहीं। वर्तमान मान और रिक्वेस्ट जनरेशन यह तय करते हैं कि क्या कोई रिस्पॉन्स अभी भी प्रासंगिक है।
• विफलता के बाद फ़ोकस कहाँ जाना चाहिए? कई त्रुटियों के लिए, फ़ॉर्म से पहले एक समरी पर फ़ोकस करें; एक कॉम्पैक्ट एकल-त्रुटि के मामले में, इनवैलिड कंट्रोल पर फ़ोकस करना स्वीकार्य हो सकता है। एक नीति चुनें और एक ही बदलाव को दो बार घोषित करने से बचें।
• कौन सी विफलताएं फ़ील्ड एरर्स नहीं हैं? नेटवर्क आउटेज या स्टॉक में बदलाव पुनः प्रयास के विकल्प के साथ फ़ॉर्म-स्तरीय संदेश में आता है। इसे ईमेल या पोस्टल कोड से न जोड़ें।
• क्या यह फ़्लो संवेदनशील तथ्यों को उजागर करता है? प्रमाणीकरण और खाता-पुनर्प्राप्ति फ़ॉर्म को सामान्य सर्वर संदेशों की आवश्यकता हो सकती है। मददगार सुधार से यह उजागर नहीं होना चाहिए कि कोई खाता मौजूद है या नहीं।

30-सेकंड उत्तर ढाँचा

"मैं लेबलयुक्त नेटिव कंट्रोल्स और कंस्ट्रेंट्स से शुरुआत करता हूँ, लेकिन सर्वर हमेशा आधिकारिक रहता है। प्रत्येक इनवैलिड कंट्रोल को aria-invalid="true" और aria-describedby द्वारा संदर्भित एक स्थिर टेक्स्ट एरर मिलता है; रंग और आइकन द्वितीयक हैं। पहला असफल सबमिट प्रत्येक इनवैलिड फ़ील्ड के लिंक के साथ एक एरर समरी रेंडर करता है और फ़ोकस को उस समरी पर ले जाता है। दर्ज किए गए मान अपने स्थान पर बने रहते हैं।

मैं सबमिट पर वैलिडेट करता हूँ, फिर केवल उन फ़ील्ड्स के लिए ब्लर या सार्थक बदलाव पर वैलिडेट करता हूँ जो विफल रही हैं। डिस्काउंट-कोड चेक्स को डीबाउंस किया जाता है, वे रद्द करने योग्य (cancellable) होते हैं और उन्हें एक जनरेशन के साथ टैग किया जाता है ताकि कोई पुराना रिस्पॉन्स नए मान को बदल न सके। सर्वर ज्ञात फ़ील्ड एरर्स के साथ-साथ फ़ॉर्म-स्तरीय एरर्स को एक संरचित आकार में लौटाता है। मैं स्वचालित परीक्षणों के अलावा कीबोर्ड और स्क्रीन-रीडर रिकवरी, ज़ूम और फ़ोर्स्ड कलर्स, सर्वर राउंड ट्रिप्स, जावास्क्रिप्ट-अक्षम सबमिशन और एसिंक रेस का परीक्षण करता हूँ।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: स्टेट और इनवेरिएंट्स को परिभाषित करें

मानों को वैलिडेशन स्टेट से अलग रखें। प्रत्येक फ़ील्ड अनटच्ड, पेंडिंग, वैलिड या इनवैलिड हो सकती है, जिसमें एक एरर कोड होता है जो स्थानीयकृत टेक्स्ट से मैप होता है। फ़ॉर्म-स्तरीय एरर्स अलग होते हैं। एक सबमिट प्रयास फ़्लैग स्टोर करें ताकि यूआई आधे टाइप किए गए फ़ील्ड को विफल के रूप में प्रस्तुत न करे।

इनवेरिएंट्स इस प्रकार हैं: लेबल्स दृश्यमान रहते हैं; निर्देश त्रुटि से पहले मौजूद होते हैं; प्रदर्शित प्रत्येक फ़ील्ड एरर प्रोग्रामेटिक रूप से संबद्ध होता है; छिपे हुए एरर्स का संदर्भ नहीं दिया जाता है; एक सबमिशन एक स्पष्ट फ़ोकस मूवमेंट उत्पन्न करता है; मान्य इनपुट विफलता के बाद भी सुरक्षित रहता है; और एक पुराना एसिंक रिस्पॉन्स वर्तमान स्टेट को म्यूटेट नहीं कर सकता है।

चरण 2: ARIA से पहले सिमेंटिक कंट्रोल्स बनाएं

label, सबसे विशिष्ट इनपुट प्रकार, required, autocomplete और उचित लंबाई या पैटर्न कंस्ट्रेंट्स का उपयोग करें। देश पर निर्भर पोस्टल नियम setCustomValidity() का उपयोग कर सकता है। जैसे ही मान मान्य हो जाए, कस्टम संदेश को एक खाली स्ट्रिंग से साफ़ करें; अन्यथा ब्राउज़र सबमिशन को ब्लॉक करना जारी रखेगा।

<label for="email">Email</label>
<input id="email" name="email" type="email"
  aria-invalid="true"
  aria-describedby="email-hint email-error">
<p id="email-hint">name@example.com</p>
<p id="email-error">Enter a valid email address.</p>

checkValidity() कंस्ट्रेंट्स की जाँच करता है, जबकि reportValidity() ब्राउज़र से अपना फ़ीडबैक प्रस्तुत करने के लिए भी कहता है। यदि उत्पाद अपने स्वयं के एक्सेसिबल संदेशों को रेंडर करता है, तो दो प्रतिस्पर्धी एरर सिस्टम दिखाने के बजाय लगातार इनवैलिड स्टेट को इंटरसेप्ट करें।

चरण 3: वैलिडेशन टाइमिंग को सोच-समझकर चुनें

पहले सबमिट पर, प्रत्येक फ़ील्ड को वैलिडेट करें और सभी ब्लॉकिंग एरर्स को प्रकट करें। उसके बाद, ब्लर होने पर किसी इनवैलिड फ़ील्ड को फिर से वैलिडेट करें। चयनों या एक स्पष्ट पूर्ण आकार वाले सुधारे गए मान के लिए, कोई बदलाव त्रुटि को जल्दी साफ़ कर सकता है। जब कोई तारीख या ईमेल अधूरा हो, तो बार-बार लाइव-रीजन घोषणाएं न भेजें।

क्रॉस-फ़ील्ड नियम तब चलते हैं जब कोई भी निर्भरता बदलती है। यदि देश बदलता है, तो पोस्टल कोड को पुनः वैलिडेट करें और उसके दृश्य निर्देश को अपडेट करें। जब तक नॉर्मलाइज़ेशन सुरक्षित और प्रतिवर्ती (reversible) न हो, यूज़र इनपुट को चुपचाप दोबारा न लिखें; आस-पास के व्हाइटस्पेस को ट्रिम करना पोस्टल फ़ॉर्मेट का अनुमान लगाने से अलग है।

चरण 4: इनलाइन एरर्स और एक नेविगेट करने योग्य समरी प्रस्तुत करें

प्रत्येक फ़ील्ड के पास संक्षिप्त टेक्स्ट रेंडर करें, केवल इनवैलिड होने पर aria-invalid सेट करें और एरर के स्थिर आईडी को संदर्भित करें। विज़ुअल ट्रीटमेंट को फ़ोर्स्ड-कलर्स मोड में उपयोगी बनाए रखें और केवल लाल बॉर्डर या चेतावनी आइकन ही नहीं, बल्कि शब्दों को शामिल करें।

एक असफल मल्टी-एरर सबमिट के बाद, फ़ॉर्म से पहले एक शीर्षक वाली समरी डालें। इसे एक अस्थायी फ़ोकस लक्ष्य दें, इसे एक बार फ़ोकस करें, त्रुटियों की संख्या बताएं और संबंधित कंट्रोल्स के लिंक प्रदान करें। लिंक टेक्स्ट में फ़ील्ड और सुधार का नाम होना चाहिए। उसी इवेंट में फ़ोकस को पहले फ़ील्ड पर भी न ले जाएं; इससे समरी का निरीक्षण करना कठिन हो जाएगा।

चरण 5: एसिंक्रोनस वैलिडेशन को रेस-सेफ़ बनाएं

डिस्काउंट कोड के पूरा होने तक प्रतीक्षा करें, फिर रिक्वेस्ट को डीबाउंस करें। मान बदलने पर पिछली रिक्वेस्ट को एबॉर्ट (रद्द) करें और पूरा होने पर मोनोटोनिक रूप से बढ़ती जनरेशन की तुलना भी करें। दोनों चेक्स महत्वपूर्ण हैं क्योंकि रद्दीकरण तब आ सकता है जब कोई रिस्पॉन्स पहले ही आगे बढ़ चुका हो।

एक पोलाइट (polite) लाइव रीजन के माध्यम से पास में "जाँच की जा रही है" स्थिति दिखाएं। जब जाँच पेंडिंग हो तो डिस्काउंट लागू करने को अक्षम करें, लेकिन असंबंधित फ़ील्ड्स को अक्षम न करें। उत्पाद अनुबंध के अनुसार टाइमआउट एक पुनः प्रयास करने योग्य फ़ॉर्म-स्तरीय या कोड-स्तरीय स्थिति बन जाता है; इसे "अमान्य कोड" के रूप में रिपोर्ट नहीं किया जाना चाहिए। परिणामों को केवल मूल्य निर्धारण संदर्भ और समाप्ति अवधि के साथ कैश करें जो उन्हें मान्य बनाते हैं।

चरण 6: आधिकारिक सर्वर एरर्स का मिलान करें

फ़ॉर्म के सामान्य एक्शन या एक संवर्धित रिक्वेस्ट के माध्यम से रॉ मान सबमिट करें। सर्वर फिर से नॉर्मलाइज़ और वैलिडेट करता है, कुल योग की गणना करता है और फ़ील्ड एरर कोड्स, फ़ॉर्म एरर कोड्स और स्वीकृत मान जैसे परिणाम लौटाता है। क्लाइंट केवल अनुमति प्राप्त (allowlisted) फ़ील्ड नामों को मैप करता है। अज्ञात कुंजियाँ चयनकर्ता या मार्कअप इंजेक्शन अवसर बनने के बजाय एक सुरक्षित फ़ॉर्म-स्तरीय त्रुटि बन जाती हैं।

अस्वीकृति पर, सभी गैर-संवेदनशील प्रविष्टियों को सुरक्षित रखें, क्लाइंट के अनुमानों को सर्वर के सत्य से बदलें, वही समरी रेंडर करें और उस पर फ़ोकस करें। सफलता पर, एक स्पष्ट पुष्टि दिखाएं और डुप्लिकेट सक्रियण को रोकें। यदि सबमिशन के बाद रिस्पॉन्स खो जाता है, तो दूसरा शुल्क लगाने से पहले एक आइडेम्पोटेंसी कुंजी या ऑर्डर लुकअप का उपयोग करें।

चरण 7: स्नैपशॉट नहीं, बल्कि रिकवरी पाथ्स सत्यापित करें

खाली सबमिशन, एक त्रुटि, कई त्रुटियां, देश/पोस्टल निर्भरता, समाप्त डिलीवरी तिथि, डिस्काउंट टाइमआउट, अमान्य डिस्काउंट, तेज़ कोड परिवर्तन, केवल-सर्वर अस्वीकृति और खोए हुए सफलता रिस्पॉन्स का परीक्षण करें। यह पुष्टि करें कि मान बने रहें, समरी लिंक्स सही कंट्रोल्स पर फ़ोकस करें, सुधारी गई त्रुटियां गायब हो जाएं और पुराने एसिंक रिस्पॉन्स को अनदेखा कर दिया जाए।

केवल कीबोर्ड और स्क्रीन रीडर का उपयोग करके फ़्लो को मैन्युअली पूरा करें। 200% ज़ूम, रीफ़्लो, दृश्य फ़ोकस, फ़ोर्स्ड कलर्स, ब्राउज़र ऑटोफ़िल और क्लाइंट जावास्क्रिप्ट के बिना सामान्य सर्वर सबमिशन की जाँच करें। स्वचालित एक्सेसिबिलिटी और यूनिट टेस्ट्स इन जाँचों के पूरक हैं; वे घोषणा और फ़ोकस परीक्षण की जगह नहीं लेते हैं।

मजबूत नमूना उत्तर

"मैं फ़ील्ड मानों को टच्ड, पेंडिंग और एरर स्टेट से स्वतंत्र रूप से मॉडल करूँगा। नेटिव लेबल्स, इनपुट प्रकार, ऑटोकमप्लीट टोकन और कंस्ट्रेंट्स आधार रेखा प्रदान करते हैं। एक कस्टम क्रॉस-फ़ील्ड नियम setCustomValidity() का उपयोग करता है और मान्य होने पर हमेशा संदेश को साफ़ करता है। क्लाइंट चेक्स गति में सुधार करते हैं; सर्वर ऑर्डर स्वीकार करने से पहले कीमतों, स्टॉक, पते और डिस्काउंट को फिर से वैलिडेट करता है।

पहला सबमिट प्रत्येक ब्लॉकिंग एरर को प्रकट करता है। प्रत्येक इनवैलिड इनपुट aria-invalid="true" प्राप्त करता है और aria-describedby के साथ दृश्यमान सुधारात्मक टेक्स्ट को संदर्भित करता है। कई त्रुटियों के लिए मैं फ़ॉर्म से पहले एक समरी रेंडर करता हूँ, इसे एक बार फ़ोकस करता हूँ और प्रत्येक आइटम को उसके कंट्रोल से लिंक करता हूँ। मान्य मान अप्रभावित रहते हैं। उस सबमिट के बाद, विफल फ़ील्ड्स प्रत्येक की-प्रेस पर लाइव घोषणा के बिना, ब्लर या सार्थक बदलाव पर पुनः वैलिडेट होती हैं।

डिस्काउंट वैलिडेशन डीबाउंस होता है और इसमें एक एबॉर्ट सिग्नल और एक जनरेशन नंबर दोनों होते हैं। केवल वर्तमान मान से मेल खाने वाला रिस्पॉन्स ही यूआई को अपडेट कर सकता है। पेंडिंग और अनुपलब्ध अमान्य (invalid) से अलग हैं। सर्वर फ़ील्ड कोड्स एक अनुमति सूची के माध्यम से मैप होते हैं; वैश्विक विफलताएं फ़ॉर्म स्तर पर रहती हैं। मैं स्वचालित चेक्स के साथ-साथ कीबोर्ड, स्क्रीन-रीडर, ज़ूम, नो-स्क्रिप्ट सर्वर राउंड-ट्रिप, रेस और डुप्लिकेट-सबमिट टेस्ट पास होने के बाद ही इसे शिप करूँगा।"

सामान्य गलतियाँ

• केवल लाल बॉर्डर का उपयोग करना → कुछ यूज़र्स स्थिति को नहीं समझ सकते → सुधारात्मक टेक्स्ट, प्रोग्रामेटिक जुड़ाव और एक गैर-रंग संकेत जोड़ें।
• प्रत्येक कीस्ट्रोक पर वैलिडेट करना → अधूरा इनपुट निरंतर शोर उत्पन्न करता है → सबमिट पर वैलिडेट करें, फिर विफल फ़ील्ड्स को एक उपयोगी सीमा पर पुनः वैलिडेट करें।
• setCustomValidity() को भरा हुआ छोड़ना → सुधारा गया इनपुट अमान्य बना रहता है → नियम पास होने पर इसे खाली स्ट्रिंग पर सेट करें।
• समरी और पहले फ़ील्ड दोनों पर फ़ोकस करना → घोषणाएं और फ़ोकस आपस में प्रतिस्पर्धा करते हैं → एक विचारशील फ़ोकस मूवमेंट करें और नेविगेशन के लिए लिंक्स प्रदान करें।
• टाइमआउट को अमान्य कोड मानना → इन्फ्रास्ट्रक्चर की विफलता यूज़र का झूठा दोष बन जाती है → पेंडिंग, अनुपलब्ध और अमान्य को अलग-अलग दर्शाएं।
• प्राप्त अंतिम रिस्पॉन्स को स्वीकार करना → पुराना वैलिडेशन वर्तमान इनपुट को ओवरराइट कर देता है → पुराने काम को एबॉर्ट करें और रिक्वेस्ट जनरेशन्स की तुलना करें।
• क्लाइंट के टोटल पर भरोसा करना → रिक्वेस्ट्स यूआई को बायपास कर सकती हैं → सर्वर पर पुनर्गणना और सत्यापन करें।
• विफलता के बाद फ़ॉर्म को साफ़ करना → रिकवरी दोबारा प्रविष्टि बन जाती है → मान्य, गैर-संवेदनशील मानों को सुरक्षित रखें और केवल एरर स्टेट को बदलें।

फ़ॉलो-अप प्रश्न और उत्तर

फ़ॉलो-अप 1: क्या समरी को role="alert" का उपयोग करना चाहिए?

गतिशील रूप से डाले गए एरर्स के लिए, एक अलर्ट या उपयुक्त लाइव रीजन समरी की घोषणा कर सकता है। फ़ोकस भी इसे उपलब्ध करा सकता है। चुने गए संयोजन का परीक्षण करें क्योंकि फ़ोकस और एक असर्टिव अलर्ट एक ही सामग्री को दो बार घोषित कर सकते हैं। पूर्ण सर्वर नेविगेशन पर, पेज टाइटल और मुख्य हेडिंग में एरर काउंट डालने से पहले संदर्भ मिल सकता है।

फ़ॉलो-अप 2: फ़ॉर्म मान्य होने तक सबमिट बटन को अक्षम (disable) क्यों नहीं किया जाता?

एक अक्षम बटन यह छिपा सकता है कि क्या गलत रह गया है और कुछ नेविगेशन मोड के लिए दुर्गम हो सकता है। सबमिट पाथ को उपलब्ध रखें ताकि यूज़र पूर्ण वैलिडेशन परिणाम का अनुरोध कर सके। केवल तभी अक्षम करें जब कोई वास्तविक सबमिशन प्रगति पर हो, उस स्थिति की व्याख्या करें और यदि यह विफल हो जाए तो रिकवर करें।

फ़ॉलो-अप 3: लाइव रीजन की तुलना में aria-describedby कब बेहतर होता है?

aria-describedby फ़ील्ड को उसका वर्तमान संकेत और त्रुटि तब देता है जब यूज़र उस तक पहुँचता है। एक लाइव रीजन बिना फ़ोकस के एक सार्थक गतिशील बदलाव की घोषणा करता है। स्थैतिक इनलाइन एरर्स को लाइव रीजन्स की आवश्यकता नहीं होती है; एक साथ प्रत्येक फ़ील्ड की घोषणा करना शोर पैदा करता है। बैच के लिए समरी का उपयोग करें और वास्तव में एसिंक्रोनस परिवर्तनों के लिए पोलाइट स्थिति का उपयोग करें।

फ़ॉलो-अप 4: आप जावास्क्रिप्ट के बिना सर्वर-रेंडर्ड वैलिडेशन का समर्थन कैसे करते हैं?

एक वास्तविक फ़ॉर्म एक्शन का उपयोग करें। सर्वर सुरक्षित रखे गए मानों, फ़ील्ड एरर कोड्स, फ़ॉर्म से पहले एक समरी और टाइटल या हेडिंग में एरर काउंट के साथ समान पेज लौटाता है। समरी लिंक्स स्थिर कंट्रोल आईडी का उपयोग करते हैं। क्लाइंट संवर्धन को उसी एरर अनुबंध का उपभोग करना चाहिए, ताकि दोनों मोड में भिन्नता न आए।

फ़ॉलो-अप 5: आप एसिंक रेस का नियतात्मक (deterministically) परीक्षण कैसे करेंगे?

दो वैलिडेशन प्रॉमिस को नियंत्रित करें। रिक्वेस्ट A शुरू करें, मान बदलें, फिर B शुरू करें। B को मान्य के रूप में और A को बाद में अमान्य के रूप में रिज़ॉल्व करें। यह सुनिश्चित करें कि यूआई अभी भी B और वर्तमान मान को दर्शाता है। पेंडिंग के दौरान एबॉर्ट, टाइमआउट, अनमाउंट और पुनः सबमिशन के साथ इसे दोहराएं।