આ લેખ SurveyJS દ્વારા પ્રાયોજિત છે એક માનસિક મોડલ છે જે મોટા ભાગના React ડેવલપર્સ તેને ક્યારેય મોટેથી ચર્ચા કર્યા વિના શેર કરે છે. તે સ્વરૂપો હંમેશા ઘટકો હોવાનું માનવામાં આવે છે. આનો અર્થ એક સ્ટેક છે જેમ કે:
સ્થાનિક રાજ્ય માટે પ્રતિક્રિયા હૂક ફોર્મ (ન્યૂનતમ રી-રેન્ડર, અર્ગનોમિક ક્ષેત્ર નોંધણી, આવશ્યક ક્રિયાપ્રતિક્રિયા). માન્યતા માટે Zod (ઇનપુટ શુદ્ધતા, સીમા માન્યતા, પ્રકાર-સલામત પદચ્છેદન). બેકએન્ડ માટે પ્રતિક્રિયા ક્વેરી: સબમિશન, ફરીથી પ્રયાસો, કેશીંગ, સર્વર સમન્વયન, અને તેથી વધુ.
અને મોટાભાગના સ્વરૂપો માટે — તમારી લોગિન સ્ક્રીન, તમારા સેટિંગ્સ પૃષ્ઠો, તમારા CRUD મોડલ્સ — આ ખરેખર સારી રીતે કામ કરે છે. દરેક ભાગ તેનું કામ કરે છે, તેઓ સ્વચ્છ રીતે કંપોઝ કરે છે, અને તમે તમારી એપ્લિકેશનના ભાગો પર આગળ વધી શકો છો જે ખરેખર તમારા ઉત્પાદનને અલગ પાડે છે. પરંતુ દરેક સમયે, એક ફોર્મ દૃશ્યતા નિયમો જેવી વસ્તુઓ એકઠા કરવાનું શરૂ કરે છે જે અગાઉના જવાબો પર આધાર રાખે છે, અથવા વ્યુત્પન્ન મૂલ્યો કે જે ત્રણ ક્ષેત્રોમાંથી પસાર થાય છે. કદાચ આખા પૃષ્ઠો પણ કે જે ચાલતા કુલના આધારે છોડવા અથવા બતાવવા જોઈએ. તમે યુઝવૉચ અને ઇનલાઇન શાખા સાથે પ્રથમ શરતી સંભાળો છો, જે સારું છે. પછી બીજું. પછી તમે ક્રોસ-ફિલ્ડ નિયમોને એન્કોડ કરવા માટે સુપરરિફાઇન પર પહોંચી રહ્યાં છો કે જે તમારી Zod સ્કીમા સામાન્ય રીતે વ્યક્ત કરી શકતી નથી. પછી, સ્ટેપ નેવિગેશન બિઝનેસ લોજીક લીક કરવાનું શરૂ કરે છે. અમુક સમયે, તમે જે બનાવ્યું છે તે જુઓ અને સમજો કે ફોર્મ હવે ખરેખર UI નથી. તે એક નિર્ણય પ્રક્રિયા છે, અને ઘટક વૃક્ષ તે જ છે જ્યાં તમે તેને સંગ્રહિત કરવાનું થયું. આ તે છે જ્યાં મને લાગે છે કે પ્રતિક્રિયામાં સ્વરૂપો માટેનું માનસિક મોડેલ તૂટી જાય છે, અને તે ખરેખર કોઈની ભૂલ નથી. RHF + Zod સ્ટેક તેના માટે ડિઝાઇન કરવામાં આવ્યું હતું તે માટે ઉત્તમ છે. મુદ્દો એ છે કે અમે તેનો ઉપયોગ તે બિંદુથી આગળ ચાલુ રાખવાનું વલણ ધરાવીએ છીએ જ્યાં તેના અમૂર્તતા સમસ્યા સાથે મેળ ખાય છે કારણ કે વૈકલ્પિકને સંપૂર્ણપણે સ્વરૂપો વિશે વિચારવાની અલગ રીતની જરૂર છે. આ લેખ તે વિકલ્પ વિશે છે. આ બતાવવા માટે, અમે ચોક્કસ સમાન મલ્ટિ-સ્ટેપ ફોર્મ બે વાર બનાવીશું:
સબમિશન માટે પ્રતિક્રિયા ક્વેરી માટે રીએક્ટ હૂક ફોર્મ + Zod વાયર સાથે, SurveyJS સાથે, જે ફોર્મને ડેટા તરીકે ગણે છે — એક સરળ JSON સ્કીમા — એક ઘટક વૃક્ષને બદલે.
સમાન જરૂરિયાતો, સમાન શરતી તર્ક, અંતે સમાન API કૉલ. પછી અમે બરાબર શું ખસેડ્યું અને શું રહ્યું તેનો નકશો બનાવીશું અને તમારે કયા મોડલનો અને ક્યારે ઉપયોગ કરવો જોઈએ તે નક્કી કરવા માટે એક વ્યવહારુ રીત તૈયાર કરીશું. અમે જે ફોર્મ બનાવી રહ્યા છીએ:
આ ફોર્મ 4-પગલાંના પ્રવાહનો ઉપયોગ કરશે: પગલું 1: વિગતો
પ્રથમ નામ (જરૂરી), ઇમેઇલ (જરૂરી, માન્ય ફોર્મેટ).
પગલું 2: ઓર્ડર
એકમની કિંમત, જથ્થો, કર દર, વ્યુત્પન્ન: પેટાટોટલ, કર, કુલ.
પગલું 3: એકાઉન્ટ અને પ્રતિસાદ
શું તમારી પાસે એકાઉન્ટ છે? (હા/ના) જો હા → વપરાશકર્તા નામ + પાસવર્ડ, બંને જરૂરી છે. જો ના હોય તો → ઈમેઈલ પહેલાથી જ સ્ટેપ 1 માં એકત્રિત કરેલ છે.
સંતોષ રેટિંગ (1-5) જો ≥ 4 → પૂછે કે "તમને શું ગમ્યું?" જો ≤ 2 → પૂછે કે "આપણે શું સુધારી શકીએ?"
પગલું 4: સમીક્ષા કરો
જો કુલ >= 100 હોય તો જ દેખાય છે અંતિમ સબમિશન.
આ આત્યંતિક નથી. પરંતુ તે આર્કિટેક્ચરલ તફાવતોને છતી કરવા માટે પૂરતું છે. ભાગ 1: ઘટક-સંચાલિત (પ્રતિક્રિયા હૂક ફોર્મ + Zod) સ્થાપન npm install react-hook-form zod @hookform/resolvers @tanstack/react-query
ઝોડ સ્કીમા ચાલો Zod સ્કીમાથી શરૂઆત કરીએ, કારણ કે સામાન્ય રીતે તે જ જગ્યાએ ફોર્મનો આકાર સ્થાપિત થાય છે. પ્રથમ બે પગલાઓ માટે - વ્યક્તિગત વિગતો અને ઓર્ડર ઇનપુટ્સ - બધું જ સરળ છે: જરૂરી શબ્દમાળાઓ, ન્યૂનતમ સાથે સંખ્યાઓ અને એક એનમ. જ્યારે તમે શરતી નિયમોને વ્યક્ત કરવાનો પ્રયાસ કરો છો ત્યારે રસપ્રદ ભાગ શરૂ થાય છે.
"zod" માંથી { z } આયાત કરો;
export const formSchema = z.object({ firstName: z.string().min(1, "Required"), email: z.string().email("Invalid email"), કિંમત: z.number().min(0), quantity: z.number().min(1), tax Rate: z.number().min(1), tax Rate: z.number(", "જરૂરી"), છે. "ના"]), વપરાશકર્તાનામ: 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 (fine) = ( ct }) super = (data.hasAccount === "હા") { if (!data.username) { ctx.addIssue({ code: "custom", path: ["username"], message: "Required" }); } if (!data.password || data.password.length x. 6. cuss: "code: {addI) ["પાસવર્ડ"], સંદેશ: "ન્યૂનતમ 6 અક્ષરો" } });
જો (data.satisfaction >= 4 && !data.positiveFeedback) { ctx.addIssue({ code: "custom", path: ["positiveFeedback"], સંદેશ: "કૃપા કરીને તમને જે ગમ્યું તે શેર કરો" }); }
જો (data.satisfaction <= 2 && !data.improvementFeedback) { ctx.addIssue({ કોડ: "કસ્ટમ", પાથ:["improvementfeedback"], સંદેશ: "કૃપા કરીને અમને જણાવો કે શું સુધારવું છે" }); }});
નિકાસ પ્રકાર FormData = z.infer
નોંધ લો કે વપરાશકર્તાનામ અને પાસવર્ડને વૈકલ્પિક() તરીકે ટાઈપ કરવામાં આવ્યા છે, તેમ છતાં તેઓ શરતી રીતે જરૂરી છે કારણ કે Zod ની પ્રકાર-સ્તરની સ્કીમા ઑબ્જેક્ટના આકારનું વર્ણન કરે છે, જ્યારે ફીલ્ડ્સ મહત્વના હોય ત્યારે નિયમન કરતા નિયમોનું નહીં. શરતી જરૂરિયાત સુપરરિફાઇનની અંદર રહે છે, જે આકાર માન્ય થયા પછી ચાલે છે અને સંપૂર્ણ ઑબ્જેક્ટની ઍક્સેસ ધરાવે છે. એ વિચ્છેદ એ દોષ નથી; તે ફક્ત તે જ છે જેના માટે ટૂલ ડિઝાઇન કરવામાં આવ્યું છે: સુપરરિફાઇન તે છે જ્યાં ક્રોસ-ફીલ્ડ લોજિક જાય છે જ્યારે તે સ્કીમા સ્ટ્રક્ચરમાં જ વ્યક્ત કરી શકાતું નથી. અહીં જે નોંધપાત્ર છે તે એ છે કે આ સ્કીમા શું વ્યક્ત કરતી નથી. તેમાં પૃષ્ઠોનો કોઈ ખ્યાલ નથી, કયા ક્ષેત્રો કયા બિંદુએ દૃશ્યમાન છે તેનો કોઈ ખ્યાલ નથી, અને નેવિગેશનનો કોઈ ખ્યાલ નથી. તે બધા બીજે ક્યાંક જીવશે. ફોર્મ ઘટક
"react-hook-form" માંથી { useForm, useWatch } આયાત કરો; "@hookform/resolvers/zod" માંથી { zodResolver } આયાત કરો; "@tanstack/react-query" માંથી { useMutation } આયાત કરો; "react" માંથી { useState, useMemo } આયાત કરો; "react" માંથી આયાત કરો, "માતા/માટે" ફોર્મ માંથી આયાત કરો.
const STEPS = ["વિગતો", "ઓર્ડર", "એકાઉન્ટ", "સમીક્ષા"];
પ્રકાર OrderPayload = FormData & { ઉપટોટલ: સંખ્યા; કર: નંબર; કુલ: સંખ્યા };
નિકાસ કાર્ય RHFMultiStepForm() { const [step, setStep] = useState(0);
const mutation = useMutation({ mutationFn: async (payload: OrderPayload) => { const res = લાવવાની રાહ જુઓ("/api/orders", { પદ્ધતિ: "પોસ્ટ", હેડર્સ: { "સામગ્રી-પ્રકાર": "એપ્લિકેશન/જેસન" }, મુખ્ય ભાગ: JSON.stringify(પેલોડ), }); જો (!res.ok) નવી ભૂલ ફેંકી દે ("સબમિટ કરવામાં નિષ્ફળ"); પરત res.json(); }, });
const { રજીસ્ટર, કંટ્રોલ, હેન્ડલ સબમિટ, ફોર્મસ્ટેટ: { ભૂલો }, } = useForm
પરત કરો (
);}પેન સર્વે JS-03-RHF [ફોર્ક્ડ] છઠ્ઠી લુપ્તતા જુઓ. અહીં ઘણું બધું થઈ રહ્યું છે, અને વસ્તુઓ ક્યાં સમાપ્ત થઈ તે નોંધવું ધીમુ કરવા યોગ્ય છે.
વ્યુત્પન્ન મૂલ્યો — પેટાટોટલ, કર, કુલ — ઘટકોમાં UseWatch અને useMemo દ્વારા ગણતરી કરવામાં આવે છે કારણ કે તે લાઇવ ફીલ્ડ મૂલ્યો પર આધાર રાખે છે અને તેમના માટે અન્ય કોઈ કુદરતી સ્થાન નથી. વપરાશકર્તાનામ, પાસવર્ડ, હકારાત્મક પ્રતિસાદ અને સુધારણા ફીડબેક માટે દૃશ્યતા નિયમો JSX માં ઇનલાઇન શરત તરીકે રહે છે. સ્ટેપ-સ્કિપિંગ લોજિક — રિવ્યૂ પેજ ત્યારે જ દેખાય છે જ્યારે કુલ >= 100 — શો સબમિટ વેરિયેબલમાં એમ્બેડ કરવામાં આવે અને સ્ટેપ 3 પર રેન્ડર શરત હોય. નેવિગેશન પોતે જ એક યુઝસ્ટેટ કાઉન્ટર છે જેને અમે મેન્યુઅલી વધારી રહ્યા છીએ. રીએક્ટ ક્વેરી ફરીથી પ્રયાસો, કેશીંગ અને અમાન્યતાનું સંચાલન કરે છે. ફોર્મ માત્ર માન્ય ડેટા સાથે mutation.mutate કૉલ કરે છે.
આમાંથી કંઈ ખોટું નથી, પ્રતિ સે. આ હજુ પણ રૂઢિપ્રયોગાત્મક પ્રતિક્રિયા છે, અને RHF કેવી રીતે રિ-રેન્ડર્સને અલગ કરે છે તેના માટે ઘટક તદ્દન પરફોર્મન્સ છે. પરંતુ જો તમે આને કોઈ એવી વ્યક્તિને સોંપો કે જેમણે તે લખ્યું ન હોય અને સમીક્ષા પૃષ્ઠ કઈ પરિસ્થિતિઓમાં દેખાય છે તે સમજાવવા માટે તેમને કહો, તો તેઓએ showSubmit, સ્ટેપ 3 રેન્ડર શરત અને નેવી બટન લોજિક — ત્રણ અલગ-અલગ સ્થાનો — એક જ લીટીમાં કહી શકાય તેવા નિયમનું પુનર્નિર્માણ કરવું પડશે. ફોર્મ કામ કરે છે, હા, પરંતુ વર્તણૂક સિસ્ટમ તરીકે ખરેખર નિરીક્ષણ કરી શકાય તેવું નથી. તેને માનસિક રીતે ચલાવવાની જરૂર છે. વધુ અગત્યનું, તેને બદલવા માટે એન્જિનિયરિંગની સંડોવણીની જરૂર છે. એક નાનો ઝટકો પણ, જેમ કે જ્યારે સમીક્ષા પગલું દેખાય ત્યારે સમાયોજિત કરવું, એટલે ઘટકને સંપાદિત કરવું, માન્યતા અપડેટ કરવી, પુલ વિનંતી ખોલવી, સમીક્ષાની રાહ જોવી અને ફરીથી ગોઠવવું. ભાગ 2: સ્કીમા આધારિત (સર્વેજેએસ) ચાલો હવે સ્કીમાનો ઉપયોગ કરીને સમાન પ્રવાહ બનાવીએ. સ્થાપન npm ઇન્સ્ટૉલ સર્વે-કોર સર્વે-રિએક્ટ-ui @tanstack/react-query
સર્વે-કોર MIT-લાઈસન્સ ધરાવતું પ્લેટફોર્મ-સ્વતંત્ર રનટાઈમ એન્જિન જે SurveyJS ના ફોર્મ રેન્ડરિંગને શક્તિ આપે છે - તે ભાગ જેની અમે અહીં કાળજી રાખીએ છીએ. તે JSON સ્કીમા લે છે, તેમાંથી એક આંતરિક મોડલ બનાવે છે, અને તે દરેક વસ્તુને હેન્ડલ કરે છે જે અન્યથા તમારા પ્રતિક્રિયા ઘટકમાં રહે છે: દૃશ્યતા અભિવ્યક્તિઓનું મૂલ્યાંકન કરવું, વ્યુત્પન્ન મૂલ્યોની ગણતરી કરવી, પૃષ્ઠ સ્થિતિનું સંચાલન કરવું, માન્યતા ટ્રૅક કરવી અને "સંપૂર્ણ" નો અર્થ શું છે તે નક્કી કરવું કે કયા પૃષ્ઠો ખરેખર બતાવવામાં આવ્યા હતા. સર્વે-રિએક્ટ-uiThe UI / રેન્ડરિંગ લેયર જે તે મોડેલને પ્રતિક્રિયા સાથે જોડે છે. તે અનિવાર્યપણે એક <સર્વે મોડલ={મોડેલ} /> ઘટક છે જે જ્યારે પણ એન્જિનની સ્થિતિ બદલાય છે ત્યારે ફરીથી રેન્ડર થાય છે. SurveyJS UI લાઇબ્રેરીઓ કોણીય, Vue3 અને અન્ય ઘણા ફ્રેમવર્ક માટે પણ ઉપલબ્ધ છે.
એકસાથે, તેઓ તમને નિયંત્રણ પ્રવાહની એક લીટી લખ્યા વિના સંપૂર્ણ કાર્યાત્મક, બહુ-પૃષ્ઠ ફોર્મ રનટાઇમ આપે છે. સ્કીમા ફોર્મેટ પોતે, અગાઉ કહ્યું તેમ, માત્ર એક JSON છે — કોઈ DSL અથવા કંઈપણ માલિકીનું નથી. તમે તેને ઇનલાઇન કરી શકો છો, તેને ફાઇલમાંથી આયાત કરી શકો છો, તેને API માંથી આનયન કરી શકો છો અથવા તેને ડેટાબેઝ કૉલમમાં સ્ટોર કરી શકો છો અને રનટાઇમ પર તેને હાઇડ્રેટ કરી શકો છો. સમાન ફોર્મ, ડેટા તરીકે અહીં તે જ સ્વરૂપ છે, આ વખતે JSON ઑબ્જેક્ટ તરીકે વ્યક્ત કરવામાં આવ્યું છે. સ્કીમા દરેક વસ્તુને વ્યાખ્યાયિત કરે છે: માળખું, માન્યતા, દૃશ્યતા નિયમો, વ્યુત્પન્ન ગણતરીઓ, પૃષ્ઠ નેવિગેશન — અને તેને એક મોડેલને સોંપે છે જે રનટાઇમ પર તેનું મૂલ્યાંકન કરે છે. તે સંપૂર્ણ રીતે શું દેખાય છે તે અહીં છે:
export const surveySchema = { શીર્ષક: "ઓર્ડર ફ્લો", showProgressBar: "ટોપ", પૃષ્ઠો: [ { નામ: "વિગતો", તત્વો: [ { પ્રકાર: "ટેક્સ્ટ", નામ: "પ્રથમ નામ", isRequired: true }, { type: "text", name: "email", inputType: "email", isRequired: "True:" "ઇમેલ ટાઇપ", "ઇમેલ ટાઇપ" }] } ] }, { નામ: "ઓર્ડર", ઘટકો: [ { પ્રકાર: "ટેક્સ્ટ", નામ: "કિંમત", ઇનપુટ પ્રકાર: "નંબર", ડિફૉલ્ટ મૂલ્ય: 0 }, { પ્રકાર: "ટેક્સ્ટ", નામ: "જથ્થા", ઇનપુટ પ્રકાર: "નંબર", ડિફૉલ્ટ મૂલ્ય: 1 }, { પ્રકાર: "ડ્રોપડાઉન",નામ: "ટૅક્સરેટ", ડિફૉલ્ટમૂલ્ય: 0.1, પસંદગીઓ: [ { મૂલ્ય: 0.05, ટેક્સ્ટ: "5%" }, { મૂલ્ય: 0.1, ટેક્સ્ટ: "10%" }, { મૂલ્ય: 0.15, ટેક્સ્ટ: "15%" } ] }, { પ્રકાર: "અભિવ્યક્તિ", નામ: "સબતો:}}, "પ્રકાર:" {પ્રાપ્તિ}, "પ્રતિભાવ: }} પ્રકાર: "અભિવ્યક્તિ", નામ: "કર", અભિવ્યક્તિ: "{સબટોટલ} {taxRate}" }, { પ્રકાર: "અભિવ્યક્તિ", નામ: "કુલ", અભિવ્યક્તિ: "{સબટોટલ} + {ટેક્સ}" } ] }, {નામ: "એકાઉન્ટ", ઘટકો: [ { પ્રકાર: "રેડિયોગ્રુપ", નામ: "{subtotal}" {taxRate}" }, [ { type: "radiogroup", name: "hasoAc}", [hasoN], "withsAc}" type: "text", name: "username", visibleIf: "{hasAccount} = 'Yes'", isRequired: true }, { type: "text", name: "password", inputType: "password", visibleIf: "{hasAccount} = 'Yes'", isRequired: true, text: 6, validators "ઓછામાં ઓછા 6 અક્ષરો" }] }, { પ્રકાર: "રેટિંગ", નામ: "સંતોષ", દર: 1, દર મહત્તમ: 5 }, { પ્રકાર: "ટિપ્પણી", નામ: "પોઝિટિવ ફીડબેક", દૃશ્યક્ષમ જો: "{સંતોષ} >= 4" }, { પ્રકાર: "ટિપ્પણી", નામ: "ઇએમએફએટીબેક", નામ: "સંતોષી" <= 2" } ] }, { નામ: "સમીક્ષા", દૃશ્યમાન જો: "{કુલ} >= 100", ઘટકો: [] } ]};
એક ક્ષણ માટે આરએચએફ સંસ્કરણ સાથે આની તુલના કરો.
સુપરરિફાઇન બ્લોક કે જે શરતી રીતે જરૂરી વપરાશકર્તાનામ અને પાસવર્ડ ગયો છે. visibleIf: "{hasAccount} = 'હા'" isRequired સાથે જોડાયેલું: સાચું બંને ચિંતાઓને એકસાથે સંભાળે છે, ક્ષેત્ર પર જ, જ્યાં તમે તેમને શોધવાની અપેક્ષા રાખશો. UseWatch + useMemo સાંકળ કે જે સબટોટલ, ટેક્સ અને ટોટલની ગણતરી કરે છે તે ત્રણ અભિવ્યક્તિ ફીલ્ડ્સ દ્વારા બદલવામાં આવે છે જે એકબીજાને નામ દ્વારા સંદર્ભિત કરે છે. સમીક્ષા પૃષ્ઠ શરત, જે RHF સંસ્કરણમાં ફક્ત showSubmit, પગલું 3 રેન્ડર શાખા દ્વારા ટ્રેસ કરીને પુનઃનિર્માણ કરી શકાય તેવી હતી. અને છેલ્લે, એનએવી બટન લોજિક એ સિંગલ દૃશ્યમાન છે, જો પૃષ્ઠ ઑબ્જેક્ટ પર મિલકત છે.
ત્યાં પણ એ જ તર્ક છે. તે માત્ર એટલું જ છે કે સ્કીમા તેને રહેવા માટે એક સ્થાન આપે છે જ્યાં તે એકલતામાં દેખાય છે, તેના બદલે સમગ્ર ઘટકમાં ફેલાય છે. ઉપરાંત, નોંધ કરો કે સ્કીમા પ્રકારનો ઉપયોગ કરે છે: સબટોટલ, ટેક્સ અને કુલ માટે 'અભિવ્યક્તિ'. અભિવ્યક્તિ ફક્ત વાંચવા માટે છે અને તેનો ઉપયોગ મુખ્યત્વે ગણતરી કરેલ મૂલ્યો દર્શાવવા માટે થાય છે. SurveyJS સ્થિર સામગ્રી માટે પ્રકાર: 'html' ને પણ સમર્થન આપે છે, પરંતુ ગણતરી કરેલ મૂલ્યો માટે, અભિવ્યક્તિ એ યોગ્ય પસંદગી છે. હવે પ્રતિક્રિયા બાજુ માટે. રેન્ડરીંગ અને સબમિશન ખૂબ જ સરળ. તમારા API પર તે જ રીતે વાયર onComplete કરો — યુઝ મ્યુટેશન અથવા પ્લેન ફેચ દ્વારા:
"react" માંથી { useState, useEffect, useRef } આયાત કરો; "@tanstack/react-query" માંથી { useMutation } આયાત કરો; "survey-core" માંથી { મોડલ } આયાત કરો; "survey-react-ui" માંથી { સર્વે } આયાત કરો; "survey-core/survey"-આયાત કરો;
નિકાસ કાર્ય સર્વેફોર્મ() { const [model] = useState(() => નવું મોડલ(સર્વે સ્કીમા));
const mutation = useMutation({ mutationFn: async (ડેટા) => { const res = લાવવાની રાહ જુઓ("/api/orders", { પદ્ધતિ: "પોસ્ટ", હેડર્સ: { "સામગ્રી-પ્રકાર": "એપ્લિકેશન/જેસન" }, મુખ્ય ભાગ: 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); return () => model.onComplete.remove(handler); }, [model]); // રેફ દરેક રેન્ડર હેન્ડલરને ફરીથી નોંધણી કરવાનું ટાળે છે (મ્યુટેશન ઑબ્જેક્ટ ઓળખમાં ફેરફાર)
પરત ( <> <સર્વે મોડલ={model} /> {mutation.isError &&
પેન સર્વે JS-03-SurveyJS [ફોર્ક્ડ] છઠ્ઠી વિક્ષેપ દ્વારા જુઓ.
જ્યારે વપરાશકર્તા છેલ્લા દૃશ્યમાન પૃષ્ઠના અંત સુધી પહોંચે છે ત્યારે સંપૂર્ણ ફાયર થાય છે. તેથી જો કુલ કદ ક્યારેય 100 ને વટાવતું નથી અને સમીક્ષા પૃષ્ઠ છોડવામાં આવે છે, તો પણ તે યોગ્ય રીતે ચાલુ થાય છે કારણ કે SurveyJS "છેલ્લું પૃષ્ઠ" નો અર્થ શું છે તે નક્કી કરતા પહેલા દૃશ્યતાનું મૂલ્યાંકન કરે છે. તે પછી, sender.data ફર્સ્ટ-ક્લાસ ફીલ્ડ્સ તરીકે ગણતરી કરેલ મૂલ્યો (સબટોટલ, ટેક્સ, કુલ) સાથે તમામ જવાબો ધરાવે છે, તેથી API પેલોડ એ RHF વર્ઝન onSubmit માં મેન્યુઅલી એસેમ્બલ કરેલા સમાન છે. આmutationRef પેટર્ન એ જ છે જ્યાં તમે દરેક રેન્ડર પર બદલાતા મૂલ્ય પર સ્થિર ઇવેન્ટ હેન્ડલરની જરૂર હોય ત્યાં પહોંચશો - તેના વિશે સર્વેજેએસ-વિશિષ્ટ કંઈ નથી.
પ્રતિક્રિયા ઘટકમાં હવે કોઈપણ વ્યવસાય તર્ક શામેલ નથી. વોચનો કોઈ ઉપયોગ નથી, કોઈ શરતી JSX નથી, કોઈ સ્ટેપ કાઉન્ટર નથી, કોઈ મેમો ચેન નથી, કોઈ સુપરરિફાઈન નથી. પ્રતિક્રિયા એ તે કરી રહી છે જેમાં તે ખરેખર સારું છે: એક ઘટકને રેન્ડર કરવું અને તેને API કૉલમાં વાયરિંગ કરવું. શું પ્રતિક્રિયા બહાર ખસેડવામાં?
ચિંતા આરએચએફ સ્ટેક સર્વે જેએસ દૃશ્યતા JSX શાખાઓ દૃશ્યમાન જો વ્યુત્પન્ન મૂલ્યો યુઝવોચ / મેમોનો ઉપયોગ કરો અભિવ્યક્તિ ક્રોસ-ફીલ્ડ નિયમો સુપરરિફાઇન સ્કીમા શરતો નેવિગેશન પગલું રાજ્ય પૃષ્ઠ દૃશ્યમાન જો નિયમ સ્થાન ફાઇલોમાં વિતરિત સ્કીમામાં કેન્દ્રીયકૃત
રિએક્ટમાં જે રહે છે તે લેઆઉટ, સ્ટાઇલ, સબમિશન વાયરિંગ અને એપ ઇન્ટિગ્રેશન છે, જે કહેવાનો અર્થ એ છે કે રિએક્ટ જે વસ્તુઓ માટે ડિઝાઇન કરવામાં આવી છે. બાકીનું બધું સ્કીમામાં ખસેડવામાં આવ્યું છે, અને કારણ કે સ્કીમા માત્ર એક JSON ઑબ્જેક્ટ છે, તેને ડેટાબેઝમાં સંગ્રહિત કરી શકાય છે, તમારા એપ્લિકેશન કોડથી સ્વતંત્ર રીતે વર્ઝન કરી શકાય છે અથવા ડિપ્લોયની જરૂર વગર આંતરિક ટૂલિંગ દ્વારા સંપાદિત કરી શકાય છે. એક પ્રોડક્ટ મેનેજર કે જેને રિવ્યુ પેજને ટ્રિગર કરતી થ્રેશોલ્ડ બદલવાની જરૂર છે તે ઘટકને સ્પર્શ કર્યા વિના તે કરી શકે છે. તે ટીમો માટે એક અર્થપૂર્ણ ઓપરેશનલ તફાવત છે જ્યાં ફોર્મ વર્તન વારંવાર વિકસિત થાય છે અને હંમેશા એન્જિનિયરો દ્વારા સંચાલિત નથી. દરેક અભિગમનો ઉપયોગ ક્યારે કરવો? અહીં એક સારો નિયમ છે જે મારા માટે કામ કરે છે: ફોર્મને સંપૂર્ણપણે કાઢી નાખવાની કલ્પના કરો. તમે શું ગુમાવશો?
જો તે સ્ક્રીન છે, તો તમારે ઘટક-સંચાલિત સ્વરૂપો જોઈએ છે. જો તે વ્યવસાયિક તર્ક છે, જેમ કે થ્રેશોલ્ડ, શાખાના નિયમો અને શરતી આવશ્યકતાઓ જે વાસ્તવિક નિર્ણયોને એન્કોડ કરે છે, તો તમારે સ્કીમા એન્જિન જોઈએ છે.
તેવી જ રીતે, જો તમારી રીતે આવતા ફેરફારો મોટાભાગે લેબલ્સ, ફીલ્ડ્સ અને લેઆઉટ વિશે હોય, તો RHF તમને સારું કામ કરશે. જો તે શરતો, પરિણામો અને નિયમો વિશે હોય કે જે તમારી ઑપ્સ અથવા કાનૂની ટીમને ટિકિટ ફાઇલ કર્યા વિના મંગળવારે બપોરે સમાયોજિત કરવાની જરૂર પડી શકે છે, તો SurveyJS સાથેનું સ્કીમા મોડલ વધુ પ્રમાણિક ફિટ છે. આ બે અભિગમો ખરેખર એકબીજા સાથે સ્પર્ધામાં નથી. તેઓ સમસ્યાઓના વિવિધ વર્ગોને સંબોધિત કરે છે, અને ટાળવા યોગ્ય ભૂલ એ તર્કના વજન સાથે અમૂર્તતા સાથે મેળ ખાતી નથી - એક નિયમ સિસ્ટમને એક ઘટકની જેમ ટ્રીટ કરવી કારણ કે તે પરિચિત સાધન છે, અથવા પોલિસી એન્જિન સુધી પહોંચવું કારણ કે ફોર્મ ત્રણ પગલા સુધી વધ્યું અને શરતી ક્ષેત્ર પ્રાપ્ત કર્યું. અમે અહીં બનાવેલ ફોર્મ ઇરાદાપૂર્વક સીમાની નજીક બેસે છે, તફાવતને ઉજાગર કરવા માટે પૂરતું જટિલ પરંતુ એટલું આત્યંતિક નથી કે સરખામણીમાં કઠોર લાગે. મોટાભાગના વાસ્તવિક સ્વરૂપો કે જે તમારા કોડબેઝમાં અનિશ્ચિત બન્યા છે તે કદાચ તે જ સીમાની નજીક બેસે છે, અને પ્રશ્ન સામાન્ય રીતે ફક્ત એ જ છે કે શું કોઈએ નામ આપ્યું છે કે તેઓ ખરેખર શું છે. પ્રતિક્રિયા હૂક ફોર્મ + Zod નો ઉપયોગ કરો જ્યારે:
ફોર્મ CRUD-લક્ષી છે; તર્ક છીછરા અને UI-આધારિત છે; એન્જિનિયરો તમામ વર્તનના માલિક છે; બેકએન્ડ સત્યનો સ્ત્રોત રહે છે.
સર્વેજેએસનો ઉપયોગ કરો જ્યારે:
ફોર્મ્સ વ્યવસાયિક નિર્ણયોને એન્કોડ કરે છે; નિયમો UI થી સ્વતંત્ર રીતે વિકસિત થાય છે; તર્ક દૃશ્યમાન, ઓડિટેબલ અથવા વર્ઝન થયેલ હોવું જોઈએ; બિન-એન્જિનિયરો વર્તનને પ્રભાવિત કરે છે; સમાન ફોર્મ બહુવિધ આગળના ભાગમાં ચાલવું જોઈએ.
