यो लेख SurveyJS द्वारा प्रायोजित हो त्यहाँ धेरैजसो प्रतिक्रिया विकासकर्ताहरूले यसलाई ठूलो स्वरमा छलफल नगरी साझा गर्ने मानसिक मोडेल हो। त्यो फारमहरू सधैं कम्पोनेन्ट हुन मानिन्छ। यसको अर्थ स्ट्याक जस्तै:
स्थानीय राज्यको लागि प्रतिक्रिया हुक फारम (न्यूनतम पुन: रेन्डर, एर्गोनोमिक क्षेत्र दर्ता, अनिवार्य अन्तरक्रिया)। प्रमाणीकरणका लागि Zod (इनपुट शुद्धता, सीमा प्रमाणीकरण, टाइप-सुरक्षित पार्सिङ)। ब्याकइन्डको लागि प्रतिक्रिया प्रतिक्रिया: सबमिशन, पुन: प्रयास, क्यासिङ, सर्भर सिङ्क, र यस्तै।
र धेरै जसो फारमहरूको लागि - तपाईंको लगइन स्क्रिनहरू, तपाईंको सेटिङहरू पृष्ठहरू, तपाईंको CRUD मोडलहरू - यसले वास्तवमै राम्रोसँग काम गर्दछ। प्रत्येक टुक्राले यसको काम गर्दछ, तिनीहरू सफासँग रचना गर्छन्, र तपाईं आफ्नो अनुप्रयोगको भागहरूमा जान सक्नुहुन्छ जुन वास्तवमा तपाईंको उत्पादनलाई फरक पार्छ। तर प्रत्येक पटक केहि समय मा, एक फारमले पहिलेका जवाफहरूमा निर्भर हुने दृश्यता नियमहरू, वा तीनवटा क्षेत्रहरू मार्फत क्यास्केड गर्ने व्युत्पन्न मानहरू जस्ता चीजहरू जम्मा गर्न थाल्छ। हुनसक्छ सम्पूर्ण पृष्ठहरू जुन छोड्नुपर्छ वा चलिरहेको कुलको आधारमा देखाइन्छ। तपाईंले प्रयोगवाच र इनलाइन शाखाको साथ पहिलो सशर्त ह्यान्डल गर्नुहुन्छ, जुन ठीक छ। त्यसपछि अर्को। त्यसोभए तपाईं क्रस-फिल्ड नियमहरू इन्कोड गर्न सुपररिफाइनको लागि पुग्दै हुनुहुन्छ जुन तपाईंको Zod स्कीमाले सामान्य तरिकामा व्यक्त गर्न सक्दैन। त्यसपछि, चरण नेभिगेसनले व्यापार तर्क चुहाउन थाल्छ। केहि बिन्दुमा, तपाईले के निर्माण गर्नुभएको छ भनेर हेर्नुहुन्छ र महसुस गर्नुहुन्छ कि फारम वास्तवमा UI अब छैन। यो एक निर्णय प्रक्रिया को अधिक हो, र घटक रूख मात्र जहाँ तपाईं यसलाई भण्डारण गर्न भयो। यो जहाँ मलाई लाग्छ प्रतिक्रियामा फारमहरूको लागि मानसिक मोडेल बिग्रन्छ, र यो वास्तवमा कसैको गल्ती होइन। RHF + Zod स्ट्याक यसको लागि डिजाइन गरिएकोमा उत्कृष्ट छ। मुद्दा यो हो कि हामी यसलाई बिन्दुमा प्रयोग गरिरहन्छौं जहाँ यसको अमूर्तताहरू समस्यासँग मेल खान्छ किनभने वैकल्पिकलाई पूर्ण रूपमा रूपहरूको बारेमा सोच्ने फरक तरिका चाहिन्छ। यो लेख त्यो विकल्पको बारेमा हो। यो देखाउनको लागि, हामी ठ्याक्कै उही बहु-चरण फारम दुई पटक निर्माण गर्नेछौं:
प्रतिक्रिया हुक फारम + Zod को साथ सबमिशनको लागि प्रतिक्रिया क्वेरी गर्न वायर्ड, SurveyJS सँग, जसले फारमलाई डेटाको रूपमा व्यवहार गर्छ — एक साधारण JSON स्किमा — कम्पोनेन्ट ट्रीको सट्टा।
एउटै आवश्यकताहरू, एउटै सशर्त तर्क, अन्तमा उही API कल। त्यसोभए हामी के सारियो र के रह्यो भन्ने ठ्याक्कै नक्सा गर्नेछौं, र तपाईले कुन मोडेल र कहिले प्रयोग गर्ने भन्ने निर्णय गर्ने व्यावहारिक तरिका तयार गर्नेछौं। हामीले निर्माण गरिरहेको फारम:
यो फारमले 4-चरण प्रवाह प्रयोग गर्नेछ: चरण 1: विवरणहरू
पहिलो नाम (आवश्यक), इमेल (आवश्यक, मान्य ढाँचा)।
चरण 2: अर्डर
एकाइ मूल्य, मात्रा, कर दर, व्युत्पन्न: उप-योग, कर, कुल।
चरण 3: खाता र प्रतिक्रिया
तपाईंसँग खाता छ? (हो/होइन) यदि हो → प्रयोगकर्ता नाम + पासवर्ड, दुवै आवश्यक छ। यदि छैन भने → इमेल पहिले नै चरण १ मा सङ्कलन गरिएको छ।
सन्तुष्टि मूल्याङ्कन (१–५) यदि ≥ 4 → "तपाईलाई के मन पर्यो?" सोध्नुहोस् यदि ≤ 2 → "हामी के सुधार गर्न सक्छौं?"
चरण 4: समीक्षा गर्नुहोस्
कुल >= १०० भए मात्र देखिन्छ अन्तिम सबमिशन।
यो चरम होइन। तर वास्तुगत भिन्नताहरू उजागर गर्न यो पर्याप्त छ। भाग १: कम्पोनेन्ट-संचालित (प्रतिक्रिया हुक फारम + Zod) स्थापना npm install react-hook-form zod @hookform/resolvers @tanstack/react-query
Zod स्कीमा Zod स्कीमाको साथ सुरु गरौं, किनभने सामान्यतया त्यहाँ फारमको आकार स्थापित हुन्छ। पहिलो दुई चरणहरूको लागि - व्यक्तिगत विवरणहरू र अर्डर इनपुटहरू - सबै कुरा सीधा छ: आवश्यक स्ट्रिङहरू, न्यूनतम संख्याहरू, र एक एनम। चाखलाग्दो भाग सुरु हुन्छ जब तपाइँ सशर्त नियमहरू व्यक्त गर्ने प्रयास गर्नुहुन्छ।
"zod" बाट { z } आयात गर्नुहोस्;
निर्यात const formSchema = z.object({ firstName: z.string().min(1, "आवश्यक"), इमेल: z.string().email("अमान्य इमेल"), मूल्य: z.number().min(0), मात्रा: z.number().min(1), tax दर: z.number().min(1), कर दर: z.number:"[ycount(), छ। "No"]), प्रयोगकर्ता नाम: z.string().optional(), password: z.string().optional(), satisfaction: z.number().min(1).max(5), positive Feedback: z.string().optional(), improvementfeedback: z.string().optional(ef), ine (ct) = (ct) = ( ct }) super (data.hasAccount === "हो") { यदि (!data.username) { ctx.addIssue({ code: "custom", path: ["username"], message: "Required" }); ["पासवर्ड"], सन्देश: "न्यूनतम ६ अक्षरहरू" } });
यदि (data.satisfaction >= 4 && !data.positiveFeedback) { ctx.addIssue({ code: "custom", path: ["positiveFeedback"], सन्देश: "कृपया तपाईलाई मनपर्ने कुरा साझा गर्नुहोस्" }); }
यदि (data.satisfaction <= 2 && !data.improvementFeedback) { ctx.addIssue({ code: "custom", path:["सुधार प्रतिक्रिया"], सन्देश: "कृपया हामीलाई के सुधार गर्ने भन्नुहोस्" }); }});
निर्यात प्रकार FormData = z.infer
ध्यान दिनुहोस् कि प्रयोगकर्ता नाम र पासवर्ड वैकल्पिक () को रूपमा टाइप गरिएको छ यद्यपि तिनीहरू सशर्त रूपमा आवश्यक छन् किनभने Zod को प्रकार-स्तर स्कीमाले वस्तुको आकार वर्णन गर्दछ, फिल्डहरू महत्त्वपूर्ण हुँदा नियमहरू होइन। सशर्त आवश्यकता सुपररिफाइन भित्र बस्नु पर्छ, जुन आकार मान्य भएपछि चल्छ र पूर्ण वस्तुमा पहुँच छ। त्यो अलगाव एक दोष होइन; यो उपकरणको लागि डिजाइन गरिएको हो: सुपररिफाइन त्यो हो जहाँ क्रस-फिल्ड तर्क जान्छ जब यो स्कीमा संरचनामा व्यक्त गर्न सकिँदैन। यहाँ के पनि उल्लेखनीय छ कि यो योजनाले व्यक्त गर्दैन। यसमा पृष्ठहरूको कुनै अवधारणा छैन, कुन बिन्दुमा कुन क्षेत्रहरू देखिने छन् भन्ने कुनै अवधारणा छैन, र नेभिगेसनको कुनै अवधारणा छैन। ती सबै अरू कतै बस्नेछन्। फारम कम्पोनेन्ट
"react-hook-form" बाट { useForm, useWatch } आयात गर्नुहोस्; "@hookform/resolvers/zod" बाट { zodResolver } आयात गर्नुहोस्; "@tanstack/react-query" बाट { useMutation } आयात गर्नुहोस्; "react" बाट { useState, useMemo } आयात गर्नुहोस्; "react" बाट; maata form बाट आयात गर्नुहोस्; maata form } बाट;
const STEPS = ["विवरण", "अर्डर", "खाता", "समीक्षा"];
टाइप गर्नुहोस् OrderPayload = FormData र { उपकुल: संख्या; कर: नम्बर; कुल: संख्या };
निर्यात प्रकार्य RHFMultiStepForm() { const [step, setStep] = useState(0);
const mutation = useMutation({ mutationFn: async (payload: OrderPayload) => { const res = प्रतिक्षा गर्नुहोस् ("/api/orders", { विधि: "POST", हेडर: { "सामग्री-प्रकार": "application/json" }, मुख्य भाग: JSON.stringify(payload), }); यदि (!res.ok) नयाँ त्रुटि ("पेश गर्न असफल") फ्याँकियो; फिर्ता res.json(); }, });
const { दर्ता, नियन्त्रण, handleSubmit, formState: { त्रुटिहरू }, } = useForm
फिर्ता गर्नुहोस् (
);}Pen SurveyJS-03-RHF [काँटेदार] छैट एक्सटिंक्शन हेर्नुहोस्। यहाँ धेरै कुराहरू भइरहेका छन्, र चीजहरू कहाँ समाप्त भयो भनेर ध्यान दिनको लागि यो ढिलो गर्न लायक छ।
व्युत्पन्न मानहरू - उप-योग, कर, कुल - कम्पोनेन्टमा UseWatch र useMemo मार्फत गणना गरिन्छ किनभने तिनीहरू प्रत्यक्ष क्षेत्र मानहरूमा निर्भर हुन्छन् र तिनीहरूका लागि कुनै अन्य प्राकृतिक स्थान छैन। प्रयोगकर्ता नाम, पासवर्ड, सकारात्मक प्रतिक्रिया, र सुधारफिडब्याकको लागि दृश्यता नियमहरू JSX मा इनलाइन सर्तहरूको रूपमा लाइभ हुन्छन्। चरण-छोड्ने तर्क — कुल >= १०० — शोसबमिट भेरिएबल र चरण ३ मा रेन्डर अवस्था सम्मिलित हुँदा मात्र समीक्षा पृष्ठ देखा पर्दछ। नेभिगेसन आफैंमा प्रयोग गर्ने राज्य काउन्टर हो जुन हामी म्यानुअल रूपमा बढाउँदैछौं। प्रतिक्रिया क्वेरीले पुन: प्रयास, क्यासिङ, र अमान्यता ह्यान्डल गर्दछ। फारमले मान्य डाटाको साथ mutation.mutate लाई मात्र कल गर्छ।
यी मध्ये कुनै पनि गलत छैन, प्रति व्यक्ति। यो अझै पनि idiomatic React हो, र RHF कसरी रि-रेन्डरलाई अलग गर्छ भनेर कम्पोनेन्ट एकदमै प्रदर्शनकारी छ। तर यदि तपाईंले यो कसैलाई हस्तान्तरण गर्नुभयो जसले यसलाई लेखेका थिएनन् र तिनीहरूलाई समीक्षा पृष्ठ कुन अवस्थामा देखा पर्दछ भनेर व्याख्या गर्न सोध्नु भएको थियो भने, उनीहरूले showSubmit, चरण 3 रेन्डर अवस्था, र एनएभ बटन तर्क - तीन अलग-अलग ठाउँहरू - एक लाइनमा भनिएको नियमलाई पुनर्निर्माण गर्न। फारमले काम गर्छ, हो, तर व्यवहार प्रणालीको रूपमा वास्तवमै निरीक्षणयोग्य छैन। यसलाई मानसिक रूपमा कार्यान्वयन गर्नुपर्छ । अझ महत्त्वपूर्ण कुरा, यसलाई परिवर्तन गर्न ईन्जिनियरिङ् संलग्नता आवश्यक छ। एउटा सानो ट्वीक पनि, जस्तै समीक्षा चरण देखा पर्दा समायोजन, यसको अर्थ कम्पोनेन्ट सम्पादन गर्ने, प्रमाणीकरण अद्यावधिक गर्ने, पुल अनुरोध खोल्ने, समीक्षाको लागि पर्खने, र फेरि प्रयोग गर्ने हो। भाग २: योजना-संचालित (सर्वेजेएस) अब स्कीमा प्रयोग गरेर समान प्रवाह निर्माण गरौं। स्थापना npm सर्वेक्षण-कोर सर्वेक्षण-रिएक्ट-ui @tanstack/react-query स्थापना गर्नुहोस्
सर्वेक्षण-कोर MIT-लाइसेन्स गरिएको प्लेटफर्म-स्वतन्त्र रनटाइम इन्जिन जसले SurveyJS को फारम रेन्डरिङलाई शक्ति दिन्छ — हामीले यहाँ ख्याल गर्ने भाग। यसले JSON स्कीमा लिन्छ, यसबाट आन्तरिक मोडेल बनाउँछ, र अन्यथा तपाईंको प्रतिक्रिया कम्पोनेन्टमा रहने सबै चीजहरू ह्यान्डल गर्छ: दृश्यता अभिव्यक्तिहरूको मूल्याङ्कन गर्ने, व्युत्पन्न मानहरू कम्प्युट गर्ने, पृष्ठ स्थितिको व्यवस्थापन गर्ने, प्रमाणीकरण गर्ने, र "पूर्ण" भनेको कुन पृष्ठहरू वास्तवमा देखाइएका थिए भन्ने निर्णय गर्ने। सर्वेक्षण-प्रतिक्रिया-uiThe UI/रेन्डरिङ तह जसले त्यो मोडेललाई प्रतिक्रियासँग जोड्छ। यो अनिवार्य रूपमा एक <सर्वे मोडेल={मोडेल} /> कम्पोनेन्ट हो जुन इन्जिनको अवस्था परिवर्तन हुँदा पुन: रेन्डर हुन्छ। SurveyJS UI पुस्तकालयहरू Angular, Vue3 र अन्य धेरै फ्रेमवर्कहरूको लागि पनि उपलब्ध छन्।
सँगै, तिनीहरूले तपाईंलाई पूर्ण रूपमा कार्यात्मक, बहु-पृष्ठ फारम रनटाइम दिन्छन्, नियन्त्रण प्रवाहको एकल रेखा नलिइकन। स्कीमा ढाँचा आफैं हो, जस्तै पहिले भने, केवल एक JSON - कुनै DSL वा कुनै पनि स्वामित्व छैन। तपाईं यसलाई इनलाइन गर्न सक्नुहुन्छ, फाइलबाट आयात गर्न सक्नुहुन्छ, यसलाई API बाट ल्याउन सक्नुहुन्छ, वा डाटाबेस स्तम्भमा भण्डारण गर्न सक्नुहुन्छ र रनटाइममा हाइड्रेट गर्न सक्नुहुन्छ। समान फारम, डेटाको रूपमा यहाँ उही फारम छ, यो पटक JSON वस्तुको रूपमा व्यक्त गरिएको छ। स्कीमाले सबै कुरा परिभाषित गर्दछ: संरचना, प्रमाणीकरण, दृश्यता नियमहरू, व्युत्पन्न गणनाहरू, पृष्ठ नेभिगेसन — र यसलाई रनटाइममा मूल्याङ्कन गर्ने मोडेलमा हस्तान्तरण गर्दछ। यहाँ यो पूर्ण रूपमा कस्तो देखिन्छ:
निर्यात const surveySchema = {शीर्षक: "अर्डर फ्लो", showProgressBar: "शीर्ष", पृष्ठहरू: [ { नाम: "विवरणहरू", तत्वहरू: [ { प्रकार: "पाठ", नाम: "पहिलो नाम", isRequired: true }, { type: "text", name: "email", inputType: "email", isRequired: "true, email type", "Required: idval text" }] } ] }, {नाम: "अर्डर", तत्वहरू: [ { प्रकार: "पाठ", नाम: "मूल्य", इनपुट प्रकार: "नम्बर", पूर्वनिर्धारित मान: 0 }, { प्रकार: "पाठ", नाम: "मात्रा", इनपुट प्रकार: "नम्बर", पूर्वनिर्धारित मान: 1 }, { प्रकार: "ड्रपडाउन",नाम: "कर दर", पूर्वनिर्धारित मान: ०.१, छनोटहरू: [ { मान: ०.०५, पाठ: "५%" }, { मान: ०.१, पाठ: "१०%" }, { मान: ०.१५, पाठ: "१५%" } ] }, { प्रकार: "अभिव्यक्ति", नाम: "उपलब्धता}, "सबटोट}}, "सबट" {ताल}} प्रकार: "अभिव्यक्ति", नाम: "कर", अभिव्यक्ति: "{subtotal} {taxRate}" }, { प्रकार: "अभिव्यक्ति", नाम: "कुल", अभिव्यक्ति: "{subtotal} + {कर}" } ] }, {नाम: "खाता", तत्वहरू: [ { प्रकार: "रेडियोसमूह", नाम: "हैसओएन", "छानना:" {YasoN}", [YasoN]" प्रकार: "पाठ", नाम: "प्रयोगकर्ता नाम", दृश्यमान यदि: "{hasAccount} = 'हो'", isRequired: true }, { type: "text", name: "password", inputType: "password", visibleIf: "{hasAccount} = 'Yes'", isRequired: true:{mint: 6 type, text: valid. "न्यूनतम 6 वर्णहरू" }] }, { प्रकार: "रेटिङ", नाम: "सन्तुष्टि", दर न्यूनतम: 1, दर अधिकतम: 5 }, { प्रकार: "टिप्पणी", नाम: "सकारात्मक प्रतिक्रिया", दृश्यमान यदि: "{सन्तुष्टि} >= 4" }, {प्रकार: "टिप्पणी", नाम: "प्रमाण: "प्रमाण: "इफभिजबल" <= 2" } ] }, { नाम: "समीक्षा", visibleIf: "{कुल} >= 100", तत्वहरू: [] } ]};
यसलाई एक क्षणको लागि RHF संस्करणसँग तुलना गर्नुहोस्।
सुपररिफाइन ब्लक जुन सशर्त आवश्यक प्रयोगकर्ता नाम र पासवर्ड गएको छ। visibleIf: "{hasAccount} = 'Yes'" isRequired सँग जोडिएको: true ले दुबै चिन्ताहरू सँगै ह्यान्डल गर्छ, फिल्डमा, जहाँ तपाईंले तिनीहरूलाई फेला पार्ने अपेक्षा गर्नुहुन्छ। UseWatch + useMemo चेन जसले उप-योग, कर, र कुल गणना गर्दछ नामद्वारा एकअर्कालाई सन्दर्भ गर्ने तीन अभिव्यक्ति क्षेत्रहरूद्वारा प्रतिस्थापन गरिएको छ। समीक्षा पृष्ठ अवस्था, जुन RHF संस्करणमा showSubmit, चरण 3 रेन्डर शाखा मार्फत ट्रेस गरेर मात्र पुनर्निर्माण गर्न सकिन्छ। र अन्तमा, नेभि बटन तर्क एकल दृश्यमान यदि पृष्ठ वस्तुमा गुण हो।
त्यही तर्क पनि छ । यो मात्र हो कि स्कीमाले यसलाई बस्नको लागि ठाउँ दिन्छ जहाँ यो कम्पोनेन्टमा फैलनुको सट्टा अलगावमा देखिन्छ। साथै, ध्यान दिनुहोस् कि स्कीमाले प्रकार प्रयोग गर्दछ: उप-योग, कर, र कुलको लागि 'अभिव्यक्ति'। अभिव्यक्ति पढ्ने मात्र हो र मुख्य रूपमा गणना गरिएको मानहरू प्रदर्शन गर्न प्रयोग गरिन्छ। SurveyJS ले स्थिर सामग्रीको लागि प्रकार: 'html' लाई पनि समर्थन गर्दछ, तर गणना गरिएको मानहरूको लागि, अभिव्यक्ति सही विकल्प हो। अब प्रतिक्रिया पक्ष को लागी। रेन्डरिङ र सबमिशन धेरै सरल। तार onComplete लाई तपाइँको API मा उस्तै तरिकाले - useMutation वा प्लेन फेच मार्फत:
"react" बाट { useState, useEffect, useRef } आयात गर्नुहोस्; "@tanstack/react-query" बाट { useMutation } आयात गर्नुहोस्; "सर्भे-कोर" बाट { मोडेल } आयात गर्नुहोस्; "सर्वे-रिएक्ट-ui" बाट { सर्वेक्षण } आयात गर्नुहोस्; "सर्वे-कोर/सीएसएस" आयात गर्नुहोस्;
निर्यात प्रकार्य SurveyForm() { const [model] = useState(() => new Model(surveySchema));
const mutation = useMutation({ mutationFn: async (डेटा) => { const res = प्रतिक्षा गर्नुहोस् ("/api/orders", { विधि: "POST", हेडर: { "सामग्री-प्रकार": "application/json" }, मुख्य भाग: JSON.stringify(डेटा), }); यदि (!res.ok) नयाँ त्रुटि ("पेश गर्न असफल") फ्याँकियो; फिर्ता res.json(); }, });
const mutationRef = useRef(mutation); mutationRef.current = उत्परिवर्तन; useEffect(() => { const handler = (sender) => mutationRef.current.mutate(sender.data); model.onComplete.add(handler); फिर्ता () => model.onComplete.remove(handler); }, [model]); // रेफले प्रत्येक रेन्डर ह्यान्डलरलाई पुन: दर्ता गर्नबाट जोगाउँछ (उत्परिवर्तन वस्तु पहिचान परिवर्तनहरू)
फिर्ता ( <> <सर्वे मोडेल={model} /> {mutation.isError &&
Pen SurveyJS-03-SurveyJS [forked] by sixthextinction हेर्नुहोस्।
प्रयोगकर्ता अन्तिम देखिने पृष्ठको अन्त्यमा पुग्दा onComplete फायरहरू। त्यसोभए यदि कुलले कहिल्यै 100 पार गर्दैन र समीक्षा पृष्ठ छोडियो भने, यो अझै पनि सही रूपमा सक्रिय हुन्छ किनभने SurveyJS ले "अन्तिम पृष्ठ" को अर्थ के हो भनेर निर्णय गर्नु अघि दृश्यता मूल्याङ्कन गर्दछ। त्यसपछि, sender.data मा गणना गरिएको मानहरू (उपयोग, कर, कुल) पहिलो-कक्षा क्षेत्रहरूको रूपमा समावेश गर्दछ, त्यसैले API पेलोड RHF संस्करणले onSubmit मा म्यानुअल रूपमा भेला गरेको जस्तै हो। दmutationRef ढाँचा उस्तै हो जुन तपाईले जहाँसम्म पुग्नुहुनेछ तपाईलाई प्रत्येक रेन्डरमा परिवर्तन हुने मानमा स्थिर घटना ह्यान्डलर चाहिन्छ - यसको बारेमा SurveJS-विशिष्ट केहि छैन।
प्रतिक्रिया कम्पोनेन्टले अब कुनै पनि व्यापार तर्क समावेश गर्दैन। त्यहाँ कुनै प्रयोग छैन वाच, कुनै सशर्त JSX, कुनै चरण काउन्टर छैन, कुनै मेमो चेन छैन, कुनै सुपररिफाइन छैन। प्रतिक्रिया भनेको वास्तवमा राम्रो कुरा हो: कम्पोनेन्ट रेन्डर गर्दै र यसलाई API कलमा तार गर्दै। के प्रतिक्रिया बाहिर सारियो?
चिन्ता RHF स्ट्याक सर्वेक्षण जेएस दृश्यता JSX शाखाहरू देखिने यदि व्युत्पन्न मानहरू useWatch / useMemo अभिव्यक्ति क्रस-फिल्ड नियमहरू सुपर रिफाइन स्कीमा सर्तहरू नेभिगेसन चरण राज्य पृष्ठ देखिने यदि नियम स्थान फाइलहरूमा वितरित योजनामा केन्द्रीकृत
React मा रहने कुरा लेआउट, स्टाइलिङ, सबमिशन वायरिङ, र एप एकीकरण हो, जसलाई भन्नु पर्दा, React वस्तुहरूका लागि डिजाइन गरिएको हो। अरू सबै कुरा स्कीमामा सारियो, र स्कीमा JSON वस्तु मात्र भएको हुनाले, यसलाई डाटाबेसमा भण्डारण गर्न सकिन्छ, तपाईंको एप्लिकेसन कोडको स्वतन्त्र रूपमा संस्करण गर्न सकिन्छ, वा कुनै डिप्लोइ आवश्यक नभई आन्तरिक टुलिङ मार्फत सम्पादन गर्न सकिन्छ। समीक्षा पृष्ठ ट्रिगर गर्ने थ्रेसहोल्ड परिवर्तन गर्न आवश्यक उत्पादन प्रबन्धकले कम्पोनेन्टलाई नछोइकन त्यसो गर्न सक्छ। यो टोलीहरूको लागि एक अर्थपूर्ण परिचालन भिन्नता हो जहाँ फारम व्यवहार बारम्बार विकसित हुन्छ र सधैं इन्जिनियरहरू द्वारा संचालित हुँदैन। प्रत्येक दृष्टिकोण कहिले प्रयोग गर्ने? यहाँ मेरो लागि काम गर्ने थम्बको राम्रो नियम छ: फारम पूर्ण रूपमा मेटाउने कल्पना गर्नुहोस्। के गुमाउनुहुन्छ?
यदि यो स्क्रिन हो भने, तपाइँ घटक-संचालित फारमहरू चाहनुहुन्छ। यदि यो व्यापार तर्क हो, जस्तै थ्रेसहोल्डहरू, शाखा नियमहरू, र सशर्त आवश्यकताहरू जसले वास्तविक निर्णयहरू इन्कोड गर्दछ, तपाइँ स्किमा इन्जिन चाहनुहुन्छ।
त्यसै गरी, यदि तपाईंको मार्गमा आउने परिवर्तनहरू प्राय: लेबलहरू, क्षेत्रहरू, र लेआउटको बारेमा छन् भने, RHF ले तपाईंलाई राम्रो सेवा दिनेछ। यदि तिनीहरू सर्तहरू, नतिजाहरू, र नियमहरूको बारेमा हुन् जुन तपाईंको अप्स वा कानुनी टोलीले टिकट फाइल नगरिकन मंगलबार दिउँसो समायोजन गर्न आवश्यक पर्दछ, SurveyJS को साथ स्किमा मोडेल अधिक इमानदार फिट छ। यी दुई दृष्टिकोणहरू वास्तवमा एकअर्कासँग प्रतिस्पर्धामा छैनन्। तिनीहरूले समस्याका विभिन्न वर्गहरूलाई सम्बोधन गर्छन्, र बेवास्ता गर्न लायकको गल्ती तर्कको वजनमा अमूर्ततालाई बेमेल गर्नु हो — नियम प्रणालीलाई कम्पोनेन्टको रूपमा व्यवहार गर्ने किनभने त्यो परिचित उपकरण हो, वा नीति इन्जिनमा पुग्ने किनभने फारम तीन चरणहरूमा बढ्यो र सशर्त क्षेत्र प्राप्त भयो। हामीले यहाँ बनाएको फारम जानाजानी सीमाको नजिकै बसेको छ, भिन्नता उजागर गर्न पर्याप्त जटिल तर तुलनामा धाँधली भएको महसुस गर्न चरम छैन। धेरै जसो वास्तविक रूपहरू जुन तपाईंको कोडबेसमा अविचलित भएका छन् सायद त्यही सीमाको नजिकै बस्छन्, र प्रश्न सामान्यतया यो हो कि कसैले तिनीहरू वास्तवमा के हुन् भन्ने नाम दिएका छन्। प्रतिक्रिया हुक फारम + Zod प्रयोग गर्नुहोस् जब:
फारमहरू CRUD-उन्मुख छन्; तर्क उथले र UI-संचालित छ; इन्जिनियरहरू सबै व्यवहारको मालिक छन्; ब्याकइन्ड सत्यको स्रोत रहन्छ।
SurveJS प्रयोग गर्नुहोस् जब:
फारमहरू व्यापार निर्णयहरू सङ्केत गर्दछ; नियमहरू UI बाट स्वतन्त्र रूपमा विकसित हुन्छन्; तर्क देखिने, अडिट योग्य, वा संस्करण भएको हुनुपर्छ; गैर-इन्जिनियरहरूले व्यवहारलाई असर गर्छ; एउटै फारम धेरै फ्रन्टएन्डहरूमा चल्नु पर्छ।
