यह लेख सर्वेजेएस द्वारा प्रायोजित है एक मानसिक मॉडल है जिसे अधिकांश रिएक्ट डेवलपर्स बिना ज़ोर से चर्चा किए साझा करते हैं। उन रूपों को हमेशा घटक माना जाता है। इसका मतलब है एक ढेर जैसा:
स्थानीय राज्य के लिए रिएक्ट हुक फॉर्म (न्यूनतम पुन: प्रस्तुतीकरण, एर्गोनोमिक फ़ील्ड पंजीकरण, अनिवार्य इंटरैक्शन)। सत्यापन के लिए ज़ोड (इनपुट शुद्धता, सीमा सत्यापन, प्रकार-सुरक्षित पार्सिंग)। बैकएंड के लिए प्रतिक्रिया क्वेरी: सबमिशन, पुनः प्रयास, कैशिंग, सर्वर सिंक, इत्यादि।
और अधिकांश फ़ॉर्म के लिए - आपकी लॉगिन स्क्रीन, आपके सेटिंग पृष्ठ, आपके सीआरयूडी मॉडल - यह वास्तव में अच्छी तरह से काम करता है। प्रत्येक टुकड़ा अपना काम करता है, वे सफाई से रचना करते हैं, और आप अपने एप्लिकेशन के उन हिस्सों पर आगे बढ़ सकते हैं जो वास्तव में आपके उत्पाद को अलग करते हैं। लेकिन समय-समय पर, एक फॉर्म दृश्यता नियमों जैसी चीजें जमा करना शुरू कर देता है जो पहले के उत्तरों पर निर्भर होते हैं, या व्युत्पन्न मान जो तीन क्षेत्रों के माध्यम से कैस्केड होते हैं। शायद संपूर्ण पृष्ठ भी जिन्हें छोड़ दिया जाना चाहिए या कुल योग के आधार पर दिखाया जाना चाहिए। आप पहली सशर्तता को यूज़वॉच और इनलाइन शाखा के साथ संभालते हैं, जो ठीक है। फिर एक और। फिर आप क्रॉस-फील्ड नियमों को एन्कोड करने के लिए सुपररिफाइन तक पहुंच रहे हैं जिन्हें आपका ज़ॉड स्कीमा सामान्य तरीके से व्यक्त नहीं कर सकता है। फिर, चरण नेविगेशन व्यावसायिक तर्क को लीक करना शुरू कर देता है। कुछ बिंदु पर, आप देखते हैं कि आपने क्या बनाया है और महसूस करते हैं कि फॉर्म अब वास्तव में यूआई नहीं है। यह एक निर्णय प्रक्रिया से अधिक है, और घटक वृक्ष वही है जहां आपने इसे संग्रहीत किया था। मुझे लगता है कि यहीं पर रिएक्ट में फॉर्मों का मानसिक मॉडल टूट जाता है, और यह वास्तव में किसी की गलती नहीं है। आरएचएफ + ज़ॉड स्टैक उस उद्देश्य के लिए उत्कृष्ट है जिसके लिए इसे डिज़ाइन किया गया था। मुद्दा यह है कि हम इसे उस बिंदु से आगे उपयोग करना जारी रखते हैं जहां इसके सार समस्या से मेल खाते हैं क्योंकि विकल्प के लिए रूपों के बारे में पूरी तरह से सोचने के एक अलग तरीके की आवश्यकता होती है। यह लेख उस विकल्प के बारे में है. इसे दिखाने के लिए, हम ठीक उसी बहु-चरणीय फ़ॉर्म को दो बार बनाएंगे:
सबमिशन के लिए रिएक्ट हुक फॉर्म + ज़ॉड को रिएक्ट क्वेरी से जोड़कर, सर्वेजेएस के साथ, जो एक फॉर्म को डेटा के रूप में मानता है - एक घटक पेड़ के बजाय एक सरल JSON स्कीमा।
समान आवश्यकताएँ, समान सशर्त तर्क, अंत में समान एपीआई कॉल। फिर हम सटीक रूप से मैप करेंगे कि क्या स्थानांतरित हुआ और क्या रुका, और यह तय करने के लिए एक व्यावहारिक तरीका पेश करेंगे कि आपको किस मॉडल का उपयोग करना चाहिए, और कब। हम जो प्रपत्र बना रहे हैं:
यह फॉर्म 4-चरणीय प्रवाह का उपयोग करेगा: चरण 1: विवरण
प्रथम नाम (आवश्यक), ईमेल (आवश्यक, वैध प्रारूप)।
चरण 2: ऑर्डर करें
इकाई मूल्य, मात्रा, कर की दर, व्युत्पन्न: उप योग, कर, कुल.
चरण 3: खाता और फीडबैक
क्या आपके पास कोई खाता है? (हां/नहीं) यदि हां → उपयोगकर्ता नाम + पासवर्ड, दोनों आवश्यक हैं। यदि नहीं → ईमेल चरण 1 में पहले ही एकत्र कर लिया गया है।
संतुष्टि रेटिंग (1-5) यदि ≥ 4 → पूछें "आपको क्या पसंद आया?" यदि ≤ 2 → पूछें "हम क्या सुधार कर सकते हैं?"
चरण 4: समीक्षा करें
केवल तभी प्रकट होता है जब कुल >= 100 हो अंतिम प्रस्तुतिकरण.
यह अति नहीं है. लेकिन यह वास्तु संबंधी मतभेदों को उजागर करने के लिए पर्याप्त है। भाग 1: घटक-चालित (रिएक्ट हुक फॉर्म + ज़ॉड) स्थापना एनपीएम रिएक्ट-हुक-फॉर्म ज़ोड @हुकफॉर्म/रिज़ॉल्वर @टैनस्टैक/रिएक्शन-क्वेरी इंस्टॉल करें
ज़ॉड स्कीमा आइए ज़ॉड स्कीमा से शुरू करें, क्योंकि आमतौर पर फॉर्म का आकार वहीं स्थापित होता है। पहले दो चरणों के लिए - व्यक्तिगत विवरण और ऑर्डर इनपुट - सब कुछ सीधा है: आवश्यक स्ट्रिंग्स, न्यूनतम के साथ संख्याएं, और एक एनम। दिलचस्प हिस्सा तब शुरू होता है जब आप सशर्त नियमों को व्यक्त करने का प्रयास करते हैं।
"ज़ोड" से आयात { z };
निर्यात स्थिरांक फॉर्मस्कीमा = z.ऑब्जेक्ट ({पहला नाम: z.string().min(1, "आवश्यक"), ईमेल: z.string().ईमेल ("अमान्य ईमेल"), मूल्य: z.number().min(0), मात्रा: z.number().min(1), कर दर: z.number(), hasAccount: z.enum(["हां", "नहीं"]), उपयोगकर्ता नाम: z.string().वैकल्पिक(), पासवर्ड: z.string().वैकल्पिक(), संतुष्टि: z.number().min(1).max(5), सकारात्मक फीडबैक: z.string().वैकल्पिक(), सुधार फीडबैक: z.string().वैकल्पिक(),}).superRefine((डेटा, ctx) => { if (data.hasAccount === "हां") { if (!data.username) { ctx.addIssue({ कोड: "कस्टम", पथ: ["उपयोगकर्ता नाम"], संदेश: "आवश्यक" }); } यदि (!data.password || data.password.length < 6) { ctx.addIssue({ कोड: "कस्टम", पथ: ["पासवर्ड"], संदेश: "न्यूनतम 6 अक्षर" } });
यदि (डेटा.संतुष्टि >= 4 && !डेटा.पॉजिटिवफीडबैक) { ctx.addIssue({ कोड: "कस्टम", पथ: ["पॉजिटिवफीडबैक"], संदेश: "कृपया जो आपको पसंद आया उसे साझा करें" }); }
अगर (डेटा.संतुष्टि <= 2 && !डेटा.सुधार फीडबैक) { ctx.addIssue({ कोड: "कस्टम", पथ:["सुधार प्रतिक्रिया"], संदेश: "कृपया हमें बताएं कि क्या सुधार करना है" }); }});
निर्यात प्रकार फॉर्मडेटा = z.infer
ध्यान दें कि उपयोगकर्ता नाम और पासवर्ड वैकल्पिक() के रूप में टाइप किए गए हैं, भले ही वे सशर्त रूप से आवश्यक हों क्योंकि ज़ॉड का प्रकार-स्तरीय स्कीमा ऑब्जेक्ट के आकार का वर्णन करता है, न कि फ़ील्ड के महत्व को नियंत्रित करने वाले नियमों का। सशर्त आवश्यकता को सुपररिफाइन के अंदर रहना होगा, जो आकार के मान्य होने के बाद चलता है और पूर्ण ऑब्जेक्ट तक पहुंच रखता है। वह अलगाव कोई दोष नहीं है; यह वही है जिसके लिए उपकरण डिज़ाइन किया गया है: सुपररिफाइन वह जगह है जहां क्रॉस-फील्ड तर्क तब जाता है जब इसे स्कीमा संरचना में व्यक्त नहीं किया जा सकता है। यहां यह भी उल्लेखनीय है कि यह स्कीमा क्या व्यक्त नहीं करती है। इसमें पृष्ठों की कोई अवधारणा नहीं है, इस बात की कोई अवधारणा नहीं है कि कौन से क्षेत्र किस बिंदु पर दिखाई दे रहे हैं, और नेविगेशन की कोई अवधारणा नहीं है। वह सब कहीं और रहेंगे. प्रपत्र घटक
"react-hook-form" से आयात करें {useForm, useWatch }; "@hookform/resolvers/zod" से आयात करें { zodResolver }; "@tanstack/react-query" से आयात करें {useMutation }; "react" से आयात करें {useState,useMemo };
स्थिरांक चरण = ["विवरण", "आदेश", "खाता", "समीक्षा"];
ऑर्डरपेलोड टाइप करें = फॉर्मडेटा और { उप-योग: संख्या; कर नंबर; कुल गणना };
निर्यात फ़ंक्शन RHFMultiStepForm() { स्थिरांक [चरण, सेटस्टेप] = उपयोगस्टेट(0);
स्थिरांक उत्परिवर्तन = उपयोग उत्परिवर्तन({ उत्परिवर्तनएफएन: एसिंक (पेलोड: ऑर्डरपेलोड) => { स्थिरांक = प्रतीक्षा करें ("/एपीआई/ऑर्डर", { विधि: "पोस्ट", हेडर: { "सामग्री-प्रकार": "एप्लिकेशन/जेसन" }, मुख्य भाग: JSON.stringify(पेलोड), }); यदि (!res.ok) नई त्रुटि फेंकें ("सबमिट करने में विफल"); वापसी res.json(); }, });
स्थिरांक { रजिस्टर, नियंत्रण, हैंडल सबमिट, फॉर्मस्टेट: {त्रुटियां }, } = उपयोगफॉर्म<फॉर्मडेटा>({रिज़ॉल्वर: zodResolver(formSchema), defaultValues: {मूल्य: 0, मात्रा: 1, कर दर: 0.1, संतुष्टि: 3, hasAccount: "नहीं", }, }); स्थिरांक मूल्य = उपयोग देखें({नियंत्रण, नाम: "कीमत" }); स्थिरांक मात्रा = उपयोग देखें({नियंत्रण, नाम: "मात्रा" }); स्थिरांक कर दर = उपयोग देखें({नियंत्रण, नाम: "कर दर" }); const hasAccount = useWatch({ नियंत्रण, नाम: "hasAccount" }); स्थिरांक संतुष्टि = उपयोग देखें({नियंत्रण, नाम: "संतुष्टि" }); स्थिरांक उप-योग = यूज़मेमो(() => (कीमत ?? 0) * (मात्रा ?? 1), [कीमत, मात्रा]); स्थिरांक कर = उपयोग मेमो (() => उप-योग * (कर दर ?? 0), [उप योग, कर दर]); स्थिरांक कुल = यूज़मेमो (() => उप-योग + कर, [उप-योग, कर]); स्थिरांक onSubmit = (डेटा: फॉर्मडेटा) => उत्परिवर्तन.उत्परिवर्तित ({...डेटा, उप-योग, कर, कुल }); स्थिरांक शोसबमिट = (चरण === 2 && कुल < 100) || (चरण === 3 && कुल >= 100)
वापसी (
);}सिक्सएक्सटिंक्शन द्वारा पेन सर्वेजेएस-03-आरएचएफ [फोर्क्ड] देखें। यहां काफी कुछ हो रहा है, और यह ध्यान देने योग्य है कि चीजें कहां समाप्त हुईं।
व्युत्पन्न मान - उप-योग, कर, कुल - की गणना घटक में यूज़वॉच और यूज़मेमो के माध्यम से की जाती है क्योंकि वे लाइव फ़ील्ड मानों पर निर्भर करते हैं और उनके लिए कोई अन्य प्राकृतिक स्थान नहीं है। उपयोगकर्ता नाम, पासवर्ड, सकारात्मक फीडबैक और सुधार फीडबैक के लिए दृश्यता नियम JSX में इनलाइन सशर्त के रूप में रहते हैं। स्टेप-स्किपिंग लॉजिक - समीक्षा पृष्ठ केवल तभी दिखाई देता है जब कुल >= 100 - शोसबमिट वेरिएबल और चरण 3 पर रेंडर स्थिति में एम्बेड किया गया है। नेविगेशन अपने आप में एक यूज़स्टेट काउंटर है जिसे हम मैन्युअल रूप से बढ़ा रहे हैं। रिएक्ट क्वेरी पुनः प्रयास, कैशिंग और अमान्यकरण को संभालती है। प्रपत्र केवल मान्य डेटा के साथ उत्परिवर्तन.उत्परिवर्तित को कॉल करता है।
इनमें से कुछ भी गलत नहीं है। यह अभी भी मुहावरेदार प्रतिक्रिया है, और आरएचएफ पुन: प्रस्तुतकर्ताओं को अलग करने के तरीके के कारण घटक काफी प्रदर्शनशील है। लेकिन अगर आपको इसे किसी ऐसे व्यक्ति को सौंपना है जिसने इसे नहीं लिखा है और उनसे यह समझाने के लिए कहें कि समीक्षा पृष्ठ किन परिस्थितियों में दिखाई देता है, तो उन्हें शोसबमिट, चरण 3 रेंडर स्थिति और नेव बटन तर्क - तीन अलग-अलग स्थानों - के माध्यम से पता लगाना होगा - एक नियम को फिर से बनाने के लिए जिसे एक पंक्ति में बताया जा सकता था। फॉर्म काम करता है, हां, लेकिन एक सिस्टम के रूप में व्यवहार वास्तव में निरीक्षण योग्य नहीं है। इसे मानसिक रूप से क्रियान्वित करना होगा। इससे भी महत्वपूर्ण बात यह है कि इसे बदलने के लिए इंजीनियरिंग की भागीदारी की आवश्यकता होती है। यहां तक कि एक छोटा सा बदलाव, जैसे कि समीक्षा चरण दिखाई देने पर समायोजन करना, का अर्थ है घटक को संपादित करना, सत्यापन को अपडेट करना, पुल अनुरोध खोलना, समीक्षा की प्रतीक्षा करना और फिर से तैनात करना। भाग 2: स्कीमा-संचालित (सर्वेजेएस) आइए अब एक स्कीमा का उपयोग करके समान प्रवाह बनाएं। स्थापना एनपीएम सर्वेक्षण-कोर सर्वेक्षण-प्रतिक्रिया-यूआई @ टैनस्टैक/प्रतिक्रिया-क्वेरी स्थापित करें
सर्वे-कोर एमआईटी-लाइसेंस प्राप्त प्लेटफ़ॉर्म-स्वतंत्र रनटाइम इंजन जो सर्वेजेएस के फॉर्म रेंडरिंग को शक्ति प्रदान करता है - वह हिस्सा जिसकी हम यहां परवाह करते हैं। यह एक JSON स्कीमा लेता है, उससे एक आंतरिक मॉडल बनाता है, और वह सब कुछ संभालता है जो अन्यथा आपके रिएक्ट घटक में रहता है: दृश्यता अभिव्यक्तियों का मूल्यांकन करना, व्युत्पन्न मूल्यों की गणना करना, पृष्ठ स्थिति का प्रबंधन करना, सत्यापन को ट्रैक करना, और यह तय करना कि "पूर्ण" का क्या अर्थ है, यह देखते हुए कि कौन से पृष्ठ वास्तव में दिखाए गए थे। सर्वेक्षण-प्रतिक्रिया-यूआई यूआई / रेंडरिंग परत जो उस मॉडल को रिएक्ट से जोड़ती है। यह अनिवार्य रूप से एक <सर्वेक्षण मॉडल={मॉडल} /> घटक है जो इंजन की स्थिति बदलने पर पुन: प्रस्तुत होता है। सर्वेजेएस यूआई लाइब्रेरी एंगुलर, वीयू3 और कई अन्य फ्रेमवर्क के लिए भी उपलब्ध हैं।
साथ में, वे आपको नियंत्रण प्रवाह की एक भी पंक्ति लिखे बिना पूरी तरह कार्यात्मक, बहु-पृष्ठ फॉर्म रनटाइम देते हैं। स्कीमा प्रारूप स्वयं, जैसा कि पहले कहा गया है, केवल एक JSON है - कोई DSL या कुछ भी स्वामित्व नहीं। आप इसे इनलाइन कर सकते हैं, फ़ाइल से आयात कर सकते हैं, एपीआई से ला सकते हैं, या डेटाबेस कॉलम में संग्रहीत कर सकते हैं और रनटाइम पर हाइड्रेट कर सकते हैं। वही फॉर्म, डेटा के रूप में यहां वही फॉर्म है, जिसे इस बार JSON ऑब्जेक्ट के रूप में व्यक्त किया गया है। स्कीमा सब कुछ परिभाषित करती है: संरचना, सत्यापन, दृश्यता नियम, व्युत्पन्न गणना, पृष्ठ नेविगेशन - और इसे एक मॉडल को सौंपती है जो रनटाइम पर इसका मूल्यांकन करती है। यहाँ वह पूर्ण रूप से कैसा दिखता है:
निर्यात स्थिरांक सर्वेस्कीमा = { शीर्षक: "ऑर्डर फ़्लो", शोप्रोग्रेसबार: "शीर्ष", पृष्ठ: [ { नाम: "विवरण", तत्व: [ { प्रकार: "पाठ", नाम: "प्रथम नाम", आवश्यक है: सत्य }, { प्रकार: "पाठ", नाम: "ईमेल", इनपुट प्रकार: "ईमेल", आवश्यक है: सत्य, सत्यापनकर्ता: [{ प्रकार: "ईमेल", पाठ: "अमान्य ईमेल" }] } ] }, { नाम: "आदेश", तत्व: [ { प्रकार: "पाठ", नाम: "मूल्य", इनपुट प्रकार: "संख्या", डिफ़ॉल्ट वैल्यू: 0 }, { प्रकार: "पाठ", नाम: "मात्रा", इनपुट प्रकार: "संख्या", डिफ़ॉल्ट वैल्यू: 1 }, { प्रकार: "ड्रॉपडाउन",नाम: "कर दर", डिफ़ॉल्ट मान: 0.1, विकल्प: [ { मान: 0.05, पाठ: "5%" }, { मान: 0.1, पाठ: "10%" }, { मान: 0.15, पाठ: "15%" } ] }, { प्रकार: "अभिव्यक्ति", नाम: "उपयोग", अभिव्यक्ति: "{मूल्य} {मात्रा}" }, { प्रकार: "अभिव्यक्ति", नाम: "टैक्स", अभिव्यक्ति: "{सबटोटल} {टैक्सरेट}" }, { टाइप: "एक्सप्रेशन", नाम: "टोटल", एक्सप्रेशन: "{सबटोटल} + {टैक्स}" } ] }, { नाम: "अकाउंट", एलिमेंट्स: [ { टाइप: "रेडियोग्रुप", नाम: "हैअकाउंट", विकल्प: ["हां", "नहीं"] }, { टाइप: "टेक्स्ट", नाम: "यूजरनेम", विजिबलइफ: "{हैअकाउंट} = 'हां'', आवश्यक है: सत्य }, { प्रकार: "पाठ", नाम: "पासवर्ड", इनपुट प्रकार: "पासवर्ड", दृश्यमानयदि: "{hasAccount} = 'हां'", आवश्यक है: सत्य, सत्यापनकर्ता: [{ प्रकार: "पाठ", न्यूनतम लंबाई: 6, पाठ: "न्यूनतम 6 अक्षर" }] }, { प्रकार: "रेटिंग", नाम: "संतुष्टि", दर न्यूनतम: 1, दर अधिकतम: 5 }, { प्रकार: "टिप्पणी", नाम: "सकारात्मक फीडबैक", दृश्यमान यदि: "{संतुष्टि} >= 4" }, { प्रकार: "टिप्पणी", नाम: "सुधार फीडबैक", दृश्यमान यदि: "{संतुष्टि} <= 2" } ] }, { नाम: "समीक्षा", दृश्यमान यदि: "{कुल} >= 100", तत्व: [] } ]};
एक पल के लिए इसकी तुलना आरएचएफ संस्करण से करें।
सशर्त रूप से आवश्यक उपयोगकर्ता नाम और पासवर्ड वाला सुपररिफाइन ब्लॉक चला गया है। दृश्यमान यदि: "{hasAccount} = 'हां'" isRequired के साथ संयुक्त है: सत्य दोनों चिंताओं को एक साथ संभालता है, फ़ील्ड पर ही, जहां आप उन्हें ढूंढने की उम्मीद करते हैं। उप-योग, कर और कुल की गणना करने वाली यूज़वॉच + यूज़मेमो श्रृंखला को तीन अभिव्यक्ति फ़ील्ड द्वारा प्रतिस्थापित किया जाता है जो एक दूसरे को नाम से संदर्भित करते हैं। समीक्षा पृष्ठ की स्थिति, जो आरएचएफ संस्करण में केवल चरण 3 रेंडर शाखा, शोसबमिट के माध्यम से ट्रेस करके पुनर्निर्माण योग्य थी। और अंत में, नेव बटन लॉजिक पेज ऑब्जेक्ट पर एक एकल दृश्यमान संपत्ति है।
वहां भी यही तर्क है. यह सिर्फ इतना है कि स्कीमा इसे रहने के लिए एक जगह देती है जहां यह पूरे घटक में फैलने के बजाय अलगाव में दिखाई देता है। यह भी ध्यान दें कि स्कीमा उप-योग, कर और कुल के लिए प्रकार: 'अभिव्यक्ति' का उपयोग करती है। अभिव्यक्ति केवल पढ़ने के लिए है और मुख्य रूप से परिकलित मान प्रदर्शित करने के लिए उपयोग की जाती है। सर्वेजेएस स्थिर सामग्री के लिए प्रकार: 'एचटीएमएल' का भी समर्थन करता है, लेकिन परिकलित मूल्यों के लिए, अभिव्यक्ति सही विकल्प है। अब प्रतिक्रिया पक्ष के लिए। प्रतिपादन और प्रस्तुतीकरण बहुत सरल. onComplete को अपने एपीआई पर उसी तरह से वायर करें - यूज़म्यूटेशन या प्लेन फ़ेच के माध्यम से:
"प्रतिक्रिया" से {useState, useEffect, useRef } आयात करें; "@tanstack/react-query" से {useMutation } आयात करें;
निर्यात फ़ंक्शन सर्वेफ़ॉर्म() { स्थिरांक [मॉडल] = उपयोगस्टेट(() => नया मॉडल(सर्वेस्कीमा));
स्थिरांक उत्परिवर्तन = उपयोग उत्परिवर्तन({ उत्परिवर्तनएफएन: एसिंक (डेटा) => { स्थिरांक = प्रतीक्षा करें ("/एपीआई/ऑर्डर", { विधि: "पोस्ट", हेडर: { "सामग्री-प्रकार": "एप्लिकेशन/जेसन" }, मुख्य भाग: JSON.stringify(डेटा), }); यदि (!res.ok) नई त्रुटि फेंकें ("सबमिट करने में विफल"); वापसी res.json(); }, });
स्थिरांक उत्परिवर्तनRef = उपयोगRef(उत्परिवर्तन); उत्परिवर्तनRef.current = उत्परिवर्तन; useEffect(() => { const हैंडलर = (प्रेषक) => उत्परिवर्तनRef.current.mutate(sender.data); model.onComplete.add(handler); return() => model.onComplete.remove(handler); }, [मॉडल]); // रेफरी हर रेंडर हैंडलर को फिर से पंजीकृत करने से बचता है (म्यूटेशन ऑब्जेक्ट पहचान बदलता है)
वापसी ( <> <सर्वेक्षण मॉडल={मॉडल} /> {mutation.isError &&
सिक्सएक्सटिंक्शन द्वारा पेन सर्वेजेएस-03-सर्वेजेएस [फोर्क्ड] देखें।
जब उपयोगकर्ता अंतिम दृश्यमान पृष्ठ के अंत तक पहुंचता है तो onComplete सक्रिय हो जाता है। इसलिए यदि कुल कभी भी 100 को पार नहीं करता है और समीक्षा पृष्ठ छोड़ दिया जाता है, तब भी यह सही ढंग से सक्रिय होता है क्योंकि सर्वेजेएस "अंतिम पृष्ठ" का अर्थ तय करने से पहले दृश्यता का मूल्यांकन करता है। फिर, प्रेषक.डेटा में प्रथम श्रेणी फ़ील्ड के रूप में गणना किए गए मानों (उपयोग, कर, कुल) के साथ सभी उत्तर शामिल होते हैं, इसलिए एपीआई पेलोड ऑनसबमिट में मैन्युअल रूप से इकट्ठे किए गए आरएचएफ संस्करण के समान है। म्यूटेशनरेफ पैटर्न वही है जिसे आप कहीं भी प्राप्त कर सकते हैं, आपको एक स्थिर ईवेंट हैंडलर की आवश्यकता होती है जो प्रत्येक रेंडर पर बदलता है - इसके बारे में सर्वेजेएस-विशिष्ट कुछ भी नहीं है।
रिएक्ट घटक में अब कोई भी व्यावसायिक तर्क नहीं है। इसमें कोई यूजवॉच नहीं है, कोई कंडीशनल JSX नहीं है, कोई स्टेप काउंटर नहीं है, कोई यूजमेमो चेन नहीं है, कोई सुपररिफाइन नहीं है। रिएक्ट वही कर रहा है जिसमें वह वास्तव में अच्छा है: एक घटक को प्रस्तुत करना और उसे एपीआई कॉल में वायर करना। प्रतिक्रिया से क्या हुआ?
चिंता आरएचएफ स्टैक सर्वेजेएस दृश्यता जेएसएक्स शाखाएँ दृश्यमान यदि व्युत्पन्न मूल्य यूज़वॉच / यूज़मेमो अभिव्यक्ति क्रॉस-फील्ड नियम सुपररिफाइन स्कीमा शर्तें नेविगेशन चरण अवस्था पृष्ठ दृश्यमानयदि नियम स्थान फ़ाइलों में वितरित स्कीमा में केंद्रीकृत
रिएक्ट में जो रहता है वह लेआउट, स्टाइलिंग, सबमिशन वायरिंग और ऐप इंटीग्रेशन है, जिसका अर्थ है कि रिएक्ट वास्तव में जिन चीजों के लिए डिज़ाइन किया गया है। बाकी सब कुछ स्कीमा में चला गया, और क्योंकि स्कीमा सिर्फ एक JSON ऑब्जेक्ट है, इसे डेटाबेस में संग्रहीत किया जा सकता है, आपके एप्लिकेशन कोड से स्वतंत्र रूप से संस्करणित किया जा सकता है, या तैनाती की आवश्यकता के बिना आंतरिक टूलींग के माध्यम से संपादित किया जा सकता है। एक उत्पाद प्रबंधक जिसे समीक्षा पृष्ठ को ट्रिगर करने वाली सीमा को बदलने की आवश्यकता है, वह घटक को छुए बिना ऐसा कर सकता है। यह उन टीमों के लिए एक सार्थक परिचालन अंतर है जहां फॉर्म व्यवहार अक्सर विकसित होता है और हमेशा इंजीनियरों द्वारा संचालित नहीं होता है। प्रत्येक दृष्टिकोण का उपयोग कब करें? यहां एक अच्छा नियम है जो मेरे लिए काम करता है: फ़ॉर्म को पूरी तरह से हटाने की कल्पना करें। आप क्या खो देंगे?
यदि यह स्क्रीन है, तो आप घटक-संचालित फॉर्म चाहते हैं। यदि यह व्यावसायिक तर्क है, जैसे थ्रेसहोल्ड, शाखा नियम और सशर्त आवश्यकताएं जो वास्तविक निर्णयों को एन्कोड करती हैं, तो आप एक स्कीमा इंजन चाहते हैं।
इसी तरह, यदि आपके रास्ते में आने वाले परिवर्तन अधिकतर लेबल, फ़ील्ड और लेआउट के बारे में हैं, तो आरएचएफ आपकी अच्छी सेवा करेगा। यदि वे उन स्थितियों, परिणामों और नियमों के बारे में हैं जिन्हें आपके ऑप्स या कानूनी टीम को टिकट दाखिल किए बिना मंगलवार दोपहर को समायोजित करने की आवश्यकता हो सकती है, तो सर्वेजेएस वाला स्कीमा मॉडल अधिक सटीक रूप से फिट बैठता है। ये दोनों दृष्टिकोण वास्तव में एक-दूसरे के साथ प्रतिस्पर्धा में नहीं हैं। वे समस्याओं के विभिन्न वर्गों को संबोधित करते हैं, और टालने योग्य गलती तर्क के वजन के साथ अमूर्तता को बेमेल करना है - एक नियम प्रणाली को एक घटक की तरह व्यवहार करना क्योंकि यह परिचित उपकरण है, या एक नीति इंजन तक पहुंचना क्योंकि एक फॉर्म तीन चरणों तक बढ़ गया और एक सशर्त क्षेत्र हासिल कर लिया। यहां हमने जो फॉर्म बनाया है वह जानबूझकर सीमा के पास बैठता है, अंतर को उजागर करने के लिए काफी जटिल है लेकिन इतना चरम नहीं है कि तुलना में धांधली महसूस हो। अधिकांश वास्तविक फॉर्म जो आपके कोडबेस में बोझिल हो गए हैं, संभवतः उसी सीमा के पास बैठते हैं, और सवाल आमतौर पर सिर्फ यह है कि क्या किसी ने नाम दिया है कि वे वास्तव में क्या हैं। रिएक्ट हुक फॉर्म + ज़ॉड का उपयोग करें जब:
फॉर्म सीआरयूडी-उन्मुख हैं; तर्क उथला और यूआई-संचालित है; इंजीनियरों के पास सभी व्यवहार हैं; बैकएंड सत्य का स्रोत बना हुआ है।
सर्वेजेएस का उपयोग तब करें जब:
प्रपत्र व्यावसायिक निर्णयों को कूटबद्ध करते हैं; नियम यूआई से स्वतंत्र रूप से विकसित होते हैं; तर्क दृश्यमान, श्रवण योग्य या संस्करणबद्ध होना चाहिए; गैर-इंजीनियर व्यवहार को प्रभावित करते हैं; एक ही फॉर्म को कई फ्रंटएंड पर चलना चाहिए।
