ఈ కథనం SurveyJS ద్వారా స్పాన్సర్ చేయబడింది చాలా మంది రియాక్ట్ డెవలపర్లు బిగ్గరగా చర్చించకుండా భాగస్వామ్యం చేసే మానసిక నమూనా ఉంది. ఆ రూపాలు ఎల్లప్పుడూ భాగాలుగా భావించబడతాయి. దీని అర్థం ఇలాంటి స్టాక్:
స్థానిక స్థితి కోసం రియాక్ట్ హుక్ ఫారమ్ (కనీస రీ-రెండర్లు, ఎర్గోనామిక్ ఫీల్డ్ రిజిస్ట్రేషన్, అత్యవసర పరస్పర చర్య). ధ్రువీకరణ కోసం Zod (ఇన్పుట్ ఖచ్చితత్వం, సరిహద్దు ధ్రువీకరణ, టైప్-సేఫ్ పార్సింగ్). బ్యాకెండ్ కోసం రియాక్ట్ క్వెరీ: సమర్పణ, పునఃప్రయత్నాలు, కాషింగ్, సర్వర్ సమకాలీకరణ మరియు మొదలైనవి.
మరియు మెజారిటీ ఫారమ్ల కోసం — మీ లాగిన్ స్క్రీన్లు, మీ సెట్టింగ్ల పేజీలు, మీ CRUD మోడల్స్ — ఇది నిజంగా బాగా పని చేస్తుంది. ప్రతి భాగం దాని పనిని చేస్తుంది, అవి శుభ్రంగా కంపోజ్ చేస్తాయి మరియు మీరు మీ ఉత్పత్తిని వేరు చేసే మీ అప్లికేషన్ యొక్క భాగాలకు వెళ్లవచ్చు. కానీ ప్రతిసారీ, ఒక ఫారమ్ మునుపటి సమాధానాలపై ఆధారపడిన విజిబిలిటీ నియమాలు లేదా మూడు ఫీల్డ్ల ద్వారా క్యాస్కేడ్ చేసే ఉత్పన్న విలువలు వంటి వాటిని సేకరించడం ప్రారంభిస్తుంది. స్కిప్ చేయబడే లేదా నడుస్తున్న మొత్తం ఆధారంగా చూపబడే మొత్తం పేజీలు కూడా ఉండవచ్చు. మీరు యూజ్వాచ్ మరియు ఇన్లైన్ బ్రాంచ్తో మొదటి షరతును నిర్వహిస్తారు, ఇది మంచిది. తర్వాత మరొకటి. మీ Zod స్కీమా సాధారణ పద్ధతిలో వ్యక్తీకరించలేని క్రాస్-ఫీల్డ్ నియమాలను ఎన్కోడ్ చేయడానికి మీరు సూపర్రిఫైన్ను చేరుకుంటున్నారు. అప్పుడు, స్టెప్ నావిగేషన్ వ్యాపార లాజిక్ను లీక్ చేయడం ప్రారంభిస్తుంది. ఏదో ఒక సమయంలో, మీరు ఏమి నిర్మించారో చూసి, ఆ ఫారమ్ నిజంగా UI కాదని తెలుసుకుంటారు. ఇది మరింత నిర్ణయాత్మక ప్రక్రియ, మరియు కాంపోనెంట్ ట్రీ మీరు దానిని నిల్వ చేసిన చోటే ఉంటుంది. ఇక్కడే రియాక్ట్లోని ఫారమ్ల మానసిక నమూనా విచ్ఛిన్నమైందని నేను భావిస్తున్నాను మరియు ఇది నిజంగా ఎవరి తప్పు కాదు. RHF + Zod స్టాక్ డిజైన్ చేయబడిన దానిలో అద్భుతమైనది. సమస్య ఏమిటంటే, దాని సంగ్రహణలు సమస్యతో సరిపోలే బిందువును దాటి మనం దాన్ని ఉపయోగిస్తూనే ఉంటాము ఎందుకంటే ప్రత్యామ్నాయానికి పూర్తిగా రూపాల గురించి వేరే ఆలోచనా విధానం అవసరం. ఈ వ్యాసం ఆ ప్రత్యామ్నాయం గురించి. దీన్ని చూపించడానికి, మేము ఒకే బహుళ-దశల ఫారమ్ను రెండుసార్లు నిర్మిస్తాము:
సమర్పణ కోసం రియాక్ట్ క్వెరీకి రియాక్ట్ హుక్ ఫారమ్ + Zod వైర్డుతో, సర్వేజేఎస్తో, ఇది ఫారమ్ను డేటాగా పరిగణిస్తుంది - సాధారణ JSON స్కీమా - కాంపోనెంట్ ట్రీగా కాకుండా.
అవే అవసరాలు, అదే షరతులతో కూడిన తర్కం, చివరిలో అదే API కాల్. అప్పుడు మేము ఏది తరలించబడిందో మరియు ఏది నిలిచిందో ఖచ్చితంగా మ్యాప్ చేస్తాము మరియు మీరు ఏ మోడల్ని మరియు ఎప్పుడు ఉపయోగించాలో నిర్ణయించడానికి ఒక ఆచరణాత్మక మార్గాన్ని రూపొందిస్తాము. మేము నిర్మిస్తున్న రూపం:
ఈ ఫారమ్ 4-దశల ప్రవాహాన్ని ఉపయోగిస్తుంది: దశ 1: వివరాలు
మొదటి పేరు (అవసరం), ఇమెయిల్ (అవసరం, చెల్లుబాటు అయ్యే ఫార్మాట్).
దశ 2: ఆర్డర్
యూనిట్ ధర, పరిమాణం, పన్ను రేటు, ఉద్భవించింది: ఉపమొత్తం, పన్ను, మొత్తం.
దశ 3: ఖాతా & అభిప్రాయం
మీకు ఖాతా ఉందా? (అవును/కాదు) అవును అయితే → వినియోగదారు పేరు + పాస్వర్డ్, రెండూ అవసరం. లేకపోతే → ఇమెయిల్ ఇప్పటికే దశ 1లో సేకరించబడింది.
సంతృప్తి రేటింగ్ (1–5) ఒకవేళ ≥ 4 → “మీకు ఏది నచ్చింది?” అని అడిగితే ఒకవేళ ≤ 2 → “మేము ఏమి మెరుగుపరచగలము?” అని అడిగితే
దశ 4: సమీక్షించండి
మొత్తం >= 100 అయితే మాత్రమే కనిపిస్తుంది తుది సమర్పణ.
ఇది విపరీతమైనది కాదు. కానీ వాస్తు వ్యత్యాసాలను బహిర్గతం చేయడానికి ఇది సరిపోతుంది. పార్ట్ 1: కాంపోనెంట్-డ్రైవెన్ (రియాక్ట్ హుక్ ఫారమ్ + జోడ్) సంస్థాపన npm ఇన్స్టాల్ రియాక్ట్-హుక్-ఫారమ్ zod @hookform/resolvers @tanstack/react-query
జోడ్ స్కీమా Zod స్కీమాతో ప్రారంభిద్దాం, ఎందుకంటే సాధారణంగా ఇక్కడ ఫారమ్ యొక్క ఆకృతి ఏర్పడుతుంది. మొదటి రెండు దశల కోసం - వ్యక్తిగత వివరాలు మరియు ఆర్డర్ ఇన్పుట్లు - ప్రతిదీ సూటిగా ఉంటుంది: అవసరమైన స్ట్రింగ్లు, కనిష్ట సంఖ్యలతో కూడిన సంఖ్యలు మరియు ఎన్యూమ్. మీరు షరతులతో కూడిన నియమాలను వ్యక్తీకరించడానికి ప్రయత్నించినప్పుడు ఆసక్తికరమైన భాగం ప్రారంభమవుతుంది.
"zod" నుండి {z } దిగుమతి;
ఎగుమతి const formSchema = z.object({ firstName: z.string().min(1, "అవసరం"), ఇమెయిల్: z.string().email("చెల్లని ఇమెయిల్"), ధర: z.number().min(0), పరిమాణం: z.number().min(1), taxRate: z.ncumberunt z.enum(["అవును", "లేదు"]), వినియోగదారు పేరు: z.string().ఐచ్ఛిక(), పాస్వర్డ్: z.string().ఐచ్ఛిక(), సంతృప్తి: z.number().min(1).max(5), పాజిటివ్ అభిప్రాయం: z.string().supptional(), మెరుగుదల ctx) => { if (data.hasAccount === "Yes") { if (!data.username) { ctx.addIssue({code: "custom", path: ["username"], message: "Required" }); {!data.password. 6d. "కస్టమ్", మార్గం: ["పాస్వర్డ్"], సందేశం: "కనిష్ట 6 అక్షరాలు" });
అయితే (data.satisfaction >= 4 && !data.positiveFeedback) { ctx.addIssue({ కోడ్: "కస్టమ్", మార్గం: ["పాజిటివ్ ఫీడ్బ్యాక్"], సందేశం: "దయచేసి మీకు నచ్చిన దాన్ని భాగస్వామ్యం చేయండి" }); }
ఉంటే (data.satisfaction <= 2 && !data.improvementFeedback) { ctx.addIssue({ కోడ్: "కస్టమ్", మార్గం:["మెరుగుదల అభిప్రాయం"], సందేశం: "దయచేసి ఏమి మెరుగుపరచాలో మాకు చెప్పండి" }); }});
ఎగుమతి రకం FormData = z.infer
Zod యొక్క టైప్-లెవల్ స్కీమా ఆబ్జెక్ట్ ఆకారాన్ని వివరిస్తుంది, ఫీల్డ్లు ముఖ్యమైనప్పుడు నియమాలు కాకుండా, షరతులతో అవసరం అయినప్పటికీ వినియోగదారు పేరు మరియు పాస్వర్డ్ ఐచ్ఛికం()గా టైప్ చేయబడిందని గమనించండి. షరతులతో కూడిన ఆవశ్యకత సూపర్రిఫైన్లో నివసించాలి, ఇది ఆకారం ధృవీకరించబడిన తర్వాత నడుస్తుంది మరియు పూర్తి వస్తువుకు ప్రాప్యతను కలిగి ఉంటుంది. ఆ విభజన లోపం కాదు; ఇది సాధనం కోసం రూపొందించబడినది: సూపర్ రిఫైన్ అనేది స్కీమా నిర్మాణంలో వ్యక్తీకరించబడనప్పుడు క్రాస్-ఫీల్డ్ లాజిక్ ఎక్కడికి వెళుతుంది. ఈ స్కీమా వ్యక్తం చేయనిది కూడా ఇక్కడ గుర్తించదగినది. దీనికి పేజీల కాన్సెప్ట్ లేదు, ఏ సమయంలో ఏ ఫీల్డ్లు కనిపిస్తాయి అనే భావన లేదు మరియు నావిగేషన్ కాన్సెప్ట్ లేదు. అవన్నీ వేరే చోట నివసిస్తాయి. ఫారమ్ కాంపోనెంట్
"react-hook-form" నుండి {useForm, useWatch}ని దిగుమతి చేయండి;"@hookform/resolvers/zod" నుండి {zodResolver }ని దిగుమతి చేయండి;
const STEPS = ["వివరాలు", "ఆర్డర్", "ఖాతా", "సమీక్ష"];
టైప్ ఆర్డర్ పేలోడ్ = ఫారమ్డేటా & {ఉపమొత్తం: సంఖ్య; పన్ను: సంఖ్య; మొత్తం: సంఖ్య};
ఎగుమతి ఫంక్షన్ RHFMultiStepForm() {const [step, setStep] = useState(0);
const mutation = useMutation({ mutationFn: async (పేలోడ్: OrderPayload) => { const res = పొందేందుకు వేచి ఉండండి("/api/orders", { పద్ధతి: "పోస్ట్", శీర్షికలు: { "కంటెంట్-రకం": "application/json" }, శరీరం: JSON.stringify(పేలోడ్), }); ఒకవేళ (!res.ok) కొత్త లోపాన్ని ("సమర్పించడంలో విఫలమైంది"); res.json(); }, });
const {రిజిస్టర్, కంట్రోల్, హ్యాండిల్సబ్మిట్, ఫారమ్స్టేట్: {లోపాలు }, } = యూజ్ఫార్మ్
తిరిగి (
);}పెన్ సర్వేJS-03-RHF [ఫోర్క్డ్] బై సిక్స్థక్స్టింక్షన్ చూడండి. ఇక్కడ చాలా చాలా జరుగుతున్నాయి మరియు విషయాలు ఎక్కడ ముగిశాయో గమనించడానికి నెమ్మదిగా ఉండటం విలువ.
ఉత్పన్నమైన విలువలు - సబ్టోటల్, టాక్స్, టోటల్ - యూజ్వాచ్ మరియు యూజ్మెమో ద్వారా కాంపోనెంట్లో గణించబడతాయి ఎందుకంటే అవి లైవ్ ఫీల్డ్ విలువలపై ఆధారపడి ఉంటాయి మరియు వాటికి వేరే సహజ స్థానం లేదు. వినియోగదారు పేరు, పాస్వర్డ్, పాజిటివ్ ఫీడ్బ్యాక్ మరియు మెరుగుదల కోసం విజిబిలిటీ నియమాలు JSXలో ఇన్లైన్ షరతుల వలె ఉంటాయి. స్టెప్-స్కిప్పింగ్ లాజిక్ — సమీక్ష పేజీ మొత్తం >= 100 ఉన్నప్పుడు మాత్రమే కనిపిస్తుంది — షోసబ్మిట్ వేరియబుల్లో పొందుపరచబడింది మరియు స్టెప్ 3లోని రెండర్ కండిషన్. నావిగేషన్ అనేది మనం మాన్యువల్గా పెంచుతున్న యూజ్స్టేట్ కౌంటర్ మాత్రమే. రియాక్ట్ క్వెరీ మళ్లీ ప్రయత్నాలు, కాషింగ్ మరియు చెల్లుబాటును నిర్వహిస్తుంది. ఫారమ్ ధృవీకరించబడిన డేటాతో mutation.mutate అని పిలుస్తుంది.
ఇవేమీ తప్పు కాదు, ప్రతిగా. ఇది ఇప్పటికీ ఇడియోమాటిక్ రియాక్ట్, మరియు RHF ఐసోలేట్లు రీ-రెండర్లను ఎలా ఉపయోగిస్తుందనే దానికి కృతజ్ఞతలు. కానీ మీరు దీన్ని వ్రాయని వారికి అందజేసి, సమీక్ష పేజీ ఏ పరిస్థితులలో కనిపిస్తుందో వివరించమని వారిని అడిగితే, వారు షోసబ్మిట్, స్టెప్ 3 రెండర్ కండిషన్ మరియు నావ్ బటన్ లాజిక్ - మూడు వేర్వేరు స్థలాల ద్వారా ఒక లైన్లో పేర్కొనబడే నియమాన్ని పునర్నిర్మించవలసి ఉంటుంది. ఫారమ్ పనిచేస్తుంది, అవును, కానీ ప్రవర్తన వ్యవస్థగా నిజంగా తనిఖీ చేయబడదు. దానిని మానసికంగా అమలు చేయాలి. మరీ ముఖ్యంగా, దీన్ని మార్చడానికి ఇంజనీరింగ్ ప్రమేయం అవసరం. సమీక్ష దశ కనిపించినప్పుడు సర్దుబాటు చేయడం వంటి చిన్న సర్దుబాటు అయినా, కాంపోనెంట్ను సవరించడం, ధ్రువీకరణను నవీకరించడం, పుల్ అభ్యర్థనను తెరవడం, సమీక్ష కోసం వేచి ఉండటం మరియు మళ్లీ అమలు చేయడం. పార్ట్ 2: స్కీమా-డ్రైవెన్ (సర్వేJS) ఇప్పుడు స్కీమాను ఉపయోగించి అదే ప్రవాహాన్ని రూపొందిద్దాం. సంస్థాపన npm ఇన్స్టాల్ సర్వే-కోర్ సర్వే-రియాక్ట్-ui @tanstack/react-query
సర్వే-కోర్ సర్వేజేఎస్ ఫారమ్ రెండరింగ్కు శక్తినిచ్చే MIT-లైసెన్స్ ప్లాట్ఫారమ్-స్వతంత్ర రన్టైమ్ ఇంజిన్ — మేము ఇక్కడ శ్రద్ధ వహించే భాగం. ఇది JSON స్కీమాను తీసుకుంటుంది, దాని నుండి అంతర్గత నమూనాను రూపొందిస్తుంది మరియు మీ రియాక్ట్ కాంపోనెంట్లో నివసించే ప్రతిదానిని నిర్వహిస్తుంది: విజిబిలిటీ ఎక్స్ప్రెషన్లను మూల్యాంకనం చేయడం, ఉత్పన్నమైన విలువలను కంప్యూటింగ్ చేయడం, పేజీ స్థితిని నిర్వహించడం, ధ్రువీకరణను ట్రాక్ చేయడం మరియు వాస్తవానికి ఏ పేజీలు చూపబడతాయో “పూర్తి” అంటే ఏమిటో నిర్ణయించడం. సర్వే-రియాక్ట్-uiఆ మోడల్ను రియాక్ట్కి కనెక్ట్ చేసే UI / రెండరింగ్ లేయర్. ఇది తప్పనిసరిగా <సర్వే మోడల్={మోడల్} /> భాగం, ఇది ఇంజిన్ స్థితి మారినప్పుడల్లా మళ్లీ రెండర్ అవుతుంది. SurveyJS UI లైబ్రరీలు కోణీయ, Vue3 మరియు అనేక ఇతర ఫ్రేమ్వర్క్ల కోసం కూడా అందుబాటులో ఉన్నాయి.
కలిసి, వారు మీకు పూర్తి ఫంక్షనల్, బహుళ-పేజీ ఫారమ్ రన్టైమ్ను ఒకే లైన్ కంట్రోల్ ఫ్లో రాయకుండా అందిస్తారు. స్కీమా ఫార్మాట్ కూడా, ముందు చెప్పినట్లుగా, కేవలం JSON మాత్రమే - DSL లేదా ఏదైనా యాజమాన్యం. మీరు దీన్ని ఇన్లైన్ చేయవచ్చు, ఫైల్ నుండి దిగుమతి చేసుకోవచ్చు, API నుండి పొందవచ్చు లేదా డేటాబేస్ కాలమ్లో నిల్వ చేయవచ్చు మరియు రన్టైమ్లో దాన్ని హైడ్రేట్ చేయవచ్చు. అదే ఫారమ్, డేటా వలె ఇక్కడ అదే ఫారమ్ ఉంది, ఈసారి JSON ఆబ్జెక్ట్గా వ్యక్తీకరించబడింది. స్కీమా ప్రతిదీ నిర్వచిస్తుంది: నిర్మాణం, ధ్రువీకరణ, దృశ్యమానత నియమాలు, ఉత్పన్నమైన లెక్కలు, పేజీ నావిగేషన్ - మరియు దానిని రన్టైమ్లో మూల్యాంకనం చేసే మోడల్కి అందజేస్తుంది. ఇది పూర్తిగా ఎలా ఉంటుందో ఇక్కడ ఉంది:
ఎగుమతి const surveySchema = {శీర్షిక: "ఆర్డర్ ఫ్లో", showProgressBar: "టాప్", పేజీలు: [ {పేరు: "వివరాలు", మూలకాలు: [ { రకం: "వచనం", పేరు: "firstName", isRequired: true }, {type: "text", name: "email", inputType: "required: "email "ఇమెయిల్", వచనం: "చెల్లని ఇమెయిల్" }] } ] }, {పేరు: "ఆర్డర్", మూలకాలు: [ { రకం: "వచనం", పేరు: "ధర", ఇన్పుట్టైప్: "సంఖ్య", డిఫాల్ట్ విలువ: 0 }, { రకం: "వచనం", పేరు: "పరిమాణం", ఇన్పుట్ టైప్, డిఫాల్ట్వి: 1 రకం: "సంఖ్య" "డ్రాప్ డౌన్",పేరు: "taxRate", defaultValue: 0.1, ఎంపికలు: [ {విలువ: 0.05, వచనం: "5%" }, {విలువ: 0.1, వచనం: "10%" }, {విలువ: 0.15, వచనం: "15%" } ] }, {type: "expression", tal name: "sub to "{quantity" }, { రకం: "వ్యక్తీకరణ", పేరు: "పన్ను", వ్యక్తీకరణ: "{subtotal} {taxRate}" }, { రకం: "వ్యక్తీకరణ", పేరు: "మొత్తం", వ్యక్తీకరణ: "{subtotal} + {tax}" } ] }, { పేరు: "ఖాతా", మూలకాలు: [ {రకం, పేరు, "రేడియోగ్రూప్" Ac" ఎంపిక: "లేదు"] }, {రకం: "వచనం", పేరు: "యూజర్ పేరు", కనిపించినట్లయితే: "{hasAccount} = 'అవును'", ఇది అవసరం: నిజం }, { రకం: "వచనం", పేరు: "పాస్వర్డ్", ఇన్పుట్ రకం: "పాస్వర్డ్", కనిపించినట్లయితే: "{hasAccount}}, చెల్లుబాటు అయ్యేవి కనిష్ట పొడవు: 6, వచనం: "కనిష్ట 6 అక్షరాలు" }] }, { రకం: "రేటింగ్", పేరు: "సంతృప్తి", రేటుమిన్: 1, రేటుమాక్స్: 5 }, { రకం: "వ్యాఖ్య", పేరు: "పాజిటివ్ ఫీడ్బ్యాక్", కనిపించినట్లయితే: "{సంతృప్తి}, >= 4 రకం పేరు: " "improvementFeedback", కనిపించేది అయితే: "{సంతృప్తి} <= 2" } ] }, {పేరు: "సమీక్ష", కనిపించినట్లయితే: "{మొత్తం} >= 100", మూలకాలు: [] } ]};
దీన్ని ఒక క్షణం RHF వెర్షన్తో పోల్చండి.
షరతులతో అవసరమైన వినియోగదారు పేరు మరియు పాస్వర్డ్ సూపర్రెఫైన్ బ్లాక్ పోయింది. visualIf: "{hasAccount} = 'అవును'"తో కలిపి అవసరం: ట్రూ రెండు ఆందోళనలను కలిపి, ఫీల్డ్లోనే, మీరు వాటిని కనుగొనాలనుకుంటున్న చోట నిర్వహిస్తుంది. ఉపమొత్తం, పన్ను మరియు మొత్తాన్ని గణించిన useWatch + useMemo చైన్ మూడు వ్యక్తీకరణ ఫీల్డ్లతో భర్తీ చేయబడింది, అవి ఒకదానికొకటి పేరు ద్వారా సూచించబడతాయి. సమీక్ష పేజీ పరిస్థితి, ఇది RHF సంస్కరణలో కేవలం showSubmit, దశ 3 రెండర్ శాఖ ద్వారా ట్రేస్ చేయడం ద్వారా మాత్రమే పునర్నిర్మించబడుతుంది. చివరగా, పేజీ ఆబ్జెక్ట్లో ఆస్తి కనిపించినట్లయితే nav బటన్ లాజిక్ అనేది ఒకే ఒక్కటి.
అదే లాజిక్ ఉంది. స్కీమా అది అంతటా వ్యాపించకుండా, ఒంటరిగా కనిపించే చోట నివసించడానికి ఒక స్థలాన్ని ఇస్తుంది. అలాగే, స్కీమా ఉపమొత్తం, పన్ను మరియు మొత్తం కోసం రకాన్ని ఉపయోగిస్తుందని గమనించండి: 'వ్యక్తీకరణ'. వ్యక్తీకరణ చదవడానికి మాత్రమే మరియు లెక్కించిన విలువలను ప్రదర్శించడానికి ప్రధానంగా ఉపయోగించబడుతుంది. SurveyJS రకానికి కూడా మద్దతు ఇస్తుంది: స్టాటిక్ కంటెంట్ కోసం 'html', కానీ లెక్కించిన విలువలకు, వ్యక్తీకరణ సరైన ఎంపిక. ఇప్పుడు రియాక్ట్ వైపు. రెండరింగ్ మరియు సమర్పణ చాలా సింపుల్. వైర్ ఆన్ కంప్లీట్ మీ APIకి అదే విధంగా — యూజ్మ్యుటేషన్ లేదా సాదా పొందడం ద్వారా:
"react" నుండి {useState, useEffect, useRef }ని దిగుమతి చేయండి;"@tanstack/react-query" నుండి {useMutation}ని దిగుమతి చేయండి;"survey-core" నుండి {మోడల్}ని దిగుమతి చేయండి;
ఎగుమతి ఫంక్షన్ SurveyForm() {const [model] = useState(() => కొత్త మోడల్(surveySchema));
const mutation = useMutation({ mutationFn: async (డేటా) => { const res = పొందేందుకు వేచి ఉండండి("/api/orders", { పద్ధతి: "పోస్ట్", శీర్షికలు: { "కంటెంట్-రకం": "application/json" }, శరీరం: JSON.stringify(డేటా), }); ఒకవేళ (!res.ok) కొత్త లోపాన్ని ("సమర్పించడంలో విఫలమైంది"); res.json(); }, });
const mutationRef = useRef(మ్యుటేషన్); mutationRef.current = మ్యుటేషన్; useEffect(() => {const handler = (sender) => mutationRef.current.mutate(sender.data); model.onComplete.add(handler); రిటర్న్ () => model.onComplete.remove(handler);}, [model]); // ref ప్రతి రెండర్ హ్యాండ్లర్ను తిరిగి నమోదు చేయడాన్ని నివారిస్తుంది (మ్యుటేషన్ ఆబ్జెక్ట్ గుర్తింపు మార్పులు)
తిరిగి ( <> <సర్వే మోడల్={model} /> {mutation.isError &&
పెన్ సర్వేJS-03-SurveyJS [ఫోర్క్డ్] బై సిక్స్త్టింక్షన్ని చూడండి.
వినియోగదారు చివరిగా కనిపించే పేజీ ముగింపుకు చేరుకున్నప్పుడు onComplete కాల్పులు జరుపుతుంది. కాబట్టి మొత్తం ఎప్పుడూ 100 దాటకపోతే మరియు సమీక్ష పేజీని దాటవేయబడితే, అది ఇప్పటికీ సరిగ్గా పని చేస్తుంది ఎందుకంటే SurveyJS "చివరి పేజీ" అంటే ఏమిటో నిర్ణయించే ముందు దృశ్యమానతను అంచనా వేస్తుంది. అప్పుడు, sender.data అన్ని సమాధానాలను లెక్కించిన విలువలతో పాటు (ఉపమొత్తం, పన్ను, మొత్తం) ఫస్ట్-క్లాస్ ఫీల్డ్లుగా కలిగి ఉంటుంది, కాబట్టి API పేలోడ్ ఆన్సబ్మిట్లో RHF వెర్షన్ మాన్యువల్గా అసెంబుల్ చేసిన దానికి సమానంగా ఉంటుంది. దిmutationRef నమూనా మీరు ప్రతి రెండర్లో మారే విలువపై స్థిరమైన ఈవెంట్ హ్యాండ్లర్ అవసరమయ్యే ప్రతి చోటా మీరు చేరుకోగలిగేది అదే.
రియాక్ట్ భాగం ఇకపై ఎలాంటి వ్యాపార తర్కాన్ని కలిగి ఉండదు. యూజ్వాచ్ లేదు, షరతులతో కూడిన JSX లేదు, స్టెప్ కౌంటర్ లేదు, యూజ్మెమో చైన్ లేదు, సూపర్రిఫైన్ లేదు. రియాక్ట్ అనేది వాస్తవానికి ఏది మంచిదో అది చేస్తోంది: కాంపోనెంట్ను రెండరింగ్ చేయడం మరియు దానిని API కాల్కి వైరింగ్ చేయడం. రియాక్ట్ నుండి ఏమి బయటకు వచ్చింది?
ఆందోళన RHF స్టాక్ సర్వేJS దృశ్యమానత JSX శాఖలు కనిపిస్తే ఉత్పన్నమైన విలువలు useWatch / useMemo వ్యక్తీకరణ క్రాస్ ఫీల్డ్ నియమాలు సూపర్ రిఫైన్ స్కీమా పరిస్థితులు నావిగేషన్ దశ స్థితి ఉంటే పేజీ కనిపిస్తుంది నియమం స్థానం ఫైల్లలో పంపిణీ చేయబడింది స్కీమాలో కేంద్రీకృతమై ఉంది
రియాక్ట్లో ఉండేవి లేఅవుట్, స్టైలింగ్, సబ్మిషన్ వైరింగ్ మరియు యాప్ ఇంటిగ్రేషన్, అంటే రియాక్ట్ నిజానికి డిజైన్ చేయబడినది. మిగతావన్నీ స్కీమాలోకి తరలించబడ్డాయి మరియు స్కీమా కేవలం JSON ఆబ్జెక్ట్ అయినందున, అది డేటాబేస్లో నిల్వ చేయబడుతుంది, మీ అప్లికేషన్ కోడ్తో సంబంధం లేకుండా స్వతంత్రంగా వెర్షన్ చేయబడుతుంది లేదా డిప్లాయ్ అవసరం లేకుండా అంతర్గత సాధనం ద్వారా సవరించబడుతుంది. సమీక్ష పేజీని ట్రిగ్గర్ చేసే థ్రెషోల్డ్ని మార్చాల్సిన ఉత్పత్తి మేనేజర్, కాంపోనెంట్ను తాకకుండానే చేయవచ్చు. ఫారమ్ ప్రవర్తన తరచుగా అభివృద్ధి చెందుతుంది మరియు ఎల్లప్పుడూ ఇంజనీర్లచే నడపబడని బృందాలకు ఇది అర్ధవంతమైన కార్యాచరణ వ్యత్యాసం. ప్రతి విధానాన్ని ఎప్పుడు ఉపయోగించాలి? నా కోసం పని చేసే ఒక మంచి నియమం ఇక్కడ ఉంది: ఫారమ్ను పూర్తిగా తొలగించడాన్ని ఊహించుకోండి. మీరు ఏమి కోల్పోతారు?
ఇది స్క్రీన్లైతే, మీకు కాంపోనెంట్ ఆధారిత ఫారమ్లు కావాలి. థ్రెషోల్డ్లు, బ్రాంచ్ నియమాలు మరియు నిజమైన నిర్ణయాలను ఎన్కోడ్ చేసే షరతులతో కూడిన అవసరాలు వంటి వ్యాపార తర్కం అయితే, మీకు స్కీమా ఇంజిన్ కావాలి.
అదేవిధంగా, మీ మార్గంలో వచ్చే మార్పులు ఎక్కువగా లేబుల్లు, ఫీల్డ్లు మరియు లేఅవుట్కు సంబంధించినవి అయితే, RHF మీకు బాగా ఉపయోగపడుతుంది. అవి షరతులు, ఫలితాలు మరియు నిబంధనలకు సంబంధించినవి అయితే, మీ ops లేదా చట్టపరమైన బృందం మంగళవారం మధ్యాహ్నం టిక్కెట్ను దాఖలు చేయకుండా సర్దుబాటు చేయవలసి ఉంటుంది, SurveyJSతో స్కీమా మోడల్ మరింత నిజాయితీగా సరిపోతుంది. ఈ రెండు విధానాలు నిజంగా ఒకదానికొకటి పోటీగా లేవు. అవి వివిధ రకాల సమస్యలను పరిష్కరిస్తాయి మరియు తర్కం యొక్క బరువుకు సంగ్రహణ సరిపోలకుండా ఉండటమే తప్పని నివారించడం విలువైనది - నియమ వ్యవస్థను ఒక భాగం వలె పరిగణించడం ఎందుకంటే అది సుపరిచితమైన సాధనం, లేదా ఒక ఫారమ్ మూడు దశలకు పెరిగి షరతులతో కూడిన ఫీల్డ్ను పొందడం వలన పాలసీ ఇంజిన్ను చేరుకోవడం. మేము ఇక్కడ నిర్మించిన ఆకృతి ఉద్దేశపూర్వకంగా సరిహద్దుకు సమీపంలో ఉంది, తేడాను బహిర్గతం చేసేంత క్లిష్టంగా ఉంటుంది, కానీ పోలిక మోసపూరితంగా అనిపించేంత తీవ్రంగా లేదు. మీ కోడ్బేస్లో విపరీతంగా మారిన చాలా వాస్తవ రూపాలు బహుశా అదే సరిహద్దుకు సమీపంలోనే ఉంటాయి మరియు సాధారణంగా ఎవరికి వారు అసలు పేరు పెట్టారా అనేది ప్రశ్న. ఎప్పుడు రియాక్ట్ హుక్ ఫారమ్ + Zod ఉపయోగించండి:
ఫారమ్లు CRUD-ఆధారితమైనవి; తర్కం నిస్సారమైనది మరియు UI ఆధారితమైనది; ఇంజనీర్లు అన్ని ప్రవర్తనలను కలిగి ఉంటారు; బ్యాకెండ్ సత్యానికి మూలం.
సర్వేజెఎస్ని ఎప్పుడు ఉపయోగించండి:
ఫారమ్లు వ్యాపార నిర్ణయాలను ఎన్కోడ్ చేస్తాయి; నియమాలు UI నుండి స్వతంత్రంగా అభివృద్ధి చెందుతాయి; లాజిక్ తప్పనిసరిగా కనిపించాలి, ఆడిట్ చేయదగినది లేదా సంస్కరణలో ఉండాలి; ఇంజనీర్లు కానివారు ప్రవర్తనను ప్రభావితం చేస్తారు; ఒకే ఫారమ్ తప్పనిసరిగా బహుళ ఫ్రంటెండ్లలో అమలు చేయాలి.
