ეს სტატია დაფინანსებულია SurveyJS-ის მიერ არსებობს გონებრივი მოდელი, რომელსაც უმეტესობა React-ის დეველოპერები აზიარებენ მასზე ხმამაღლა განხილვის გარეშე. რომ ფორმები ყოველთვის უნდა იყოს კომპონენტები. ეს ნიშნავს დასტას, როგორიცაა:
React Hook Form ადგილობრივი მდგომარეობისთვის (მინიმალური ხელახალი რენდერები, ერგონომიული ველის რეგისტრაცია, იმპერატიული ურთიერთქმედება). Zod ვალიდაციისთვის (შეყვანის სისწორე, საზღვრების დადასტურება, ტიპის უსაფრთხო პარსინგი). უპასუხეთ შეკითხვას backend-ისთვის: წარდგენა, ხელახალი ცდები, ქეშირება, სერვერის სინქრონიზაცია და ა.შ.
და ფორმების უმრავლესობისთვის - თქვენი შესვლის ეკრანები, თქვენი პარამეტრების გვერდები, თქვენი CRUD მოდალები - ეს ძალიან კარგად მუშაობს. თითოეული ნაწილი თავის საქმეს აკეთებს, ისინი სუფთად ქმნიან და თქვენ შეგიძლიათ გადახვიდეთ თქვენი განაცხადის იმ ნაწილებზე, რომლებიც რეალურად განასხვავებენ თქვენს პროდუქტს. მაგრამ დროდადრო, ფორმა იწყებს ისეთი ნივთების დაგროვებას, როგორიცაა ხილვადობის წესები, რომლებიც დამოკიდებულია ადრინდელ პასუხებზე, ან მიღებული მნიშვნელობები, რომლებიც კასკადირდება სამ ველში. შესაძლოა, მთელი გვერდებიც კი, რომლებიც უნდა გამოტოვოთ ან ნაჩვენები იყოს გაშვებული ჯამიდან გამომდინარე. თქვენ ამუშავებთ პირველ პირობითს useWatch-ით და inline განშტოებით, რაც კარგია. მერე სხვა. შემდეგ თქვენ მიისწრაფვით superRefine-ისთვის, რათა დაშიფროთ ველური ჯვარედინი წესები, რომლებსაც თქვენი Zod სქემა ვერ გამოხატავს ნორმალურად. შემდეგ, ნაბიჯების ნავიგაცია იწყებს ბიზნეს ლოგიკის გაჟონვას. რაღაც მომენტში, თქვენ უყურებთ რა ააშენეთ და ხვდებით, რომ ფორმა ნამდვილად აღარ არის UI. ეს უფრო გადაწყვეტილების პროცესია და კომპონენტის ხე სწორედ იქაა, სადაც ის შეინახე. აქ ვფიქრობ, რომ React-ში ფორმების გონებრივი მოდელი იშლება და ეს ნამდვილად არავის ბრალი არ არის. RHF + Zod სტეკი შესანიშნავია იმაში, რისთვისაც შეიქმნა. საქმე იმაშია, რომ ჩვენ ვაგრძელებთ მის გამოყენებას იმ წერტილიდან, სადაც მისი აბსტრაქციები ემთხვევა პრობლემას, რადგან ალტერნატივა ფორმებზე სრულიად განსხვავებულ აზროვნებას მოითხოვს. ეს სტატია ეხება ამ ალტერნატივას. ამის საჩვენებლად, ჩვენ ორჯერ ავაშენებთ ზუსტად იგივე მრავალსაფეხურიან ფორმას:
React Hook Form + Zod-ით, რომელიც დაკავშირებულია React Query-ზე წარდგენისთვის, SurveyJS-ით, რომელიც ფორმას განიხილავს როგორც მონაცემს - მარტივი JSON სქემა - და არა კომპონენტის ხეს.
იგივე მოთხოვნები, იგივე პირობითი ლოგიკა, იგივე API გამოძახება ბოლოს. შემდეგ ჩვენ ზუსტად დავსახავთ რუკას, თუ რა გადავიდა და რა დარჩა, და გამოვყოფთ პრაქტიკულ გზას იმის გადასაწყვეტად, რომელი მოდელი და როდის უნდა გამოიყენოთ. ფორმა, რომელსაც ჩვენ ვაშენებთ:
ეს ფორმა გამოიყენებს 4-საფეხურიან ნაკადს: ნაბიჯი 1: დეტალები
სახელი (აუცილებელია), ელფოსტა (აუცილებელი, სწორი ფორმატი).
ნაბიჯი 2: შეკვეთა
ერთეულის ფასი, რაოდენობა, გადასახადის განაკვეთი, მიღებული: ქვეჯამური, გადასახადი, სულ.
ნაბიჯი 3: ანგარიში და გამოხმაურება
გაქვთ ანგარიში? (დიახ/არა) თუ დიახ → მომხმარებლის სახელი + პაროლი, ორივე აუცილებელია. თუ არა → ელფოსტა უკვე შეგროვებული ნაბიჯი 1.
კმაყოფილების რეიტინგი (1–5) თუ ≥ 4 → იკითხეთ "რა მოგეწონათ?" თუ ≤ 2 → იკითხეთ "რა შეგვიძლია გავაუმჯობესოთ?"
ნაბიჯი 4: განხილვა
გამოჩნდება მხოლოდ იმ შემთხვევაში, თუ სულ >= 100 საბოლოო წარდგენა.
ეს არ არის უკიდურესი. მაგრამ საკმარისია არქიტექტურული განსხვავებების გამოვლენა. ნაწილი 1: კომპონენტზე ორიენტირებული (React Hook Form + Zod) ინსტალაცია npm დააინსტალირე react-hook-form zod @hookform/resolvers @tanstack/react-query
ზოდის სქემა დავიწყოთ Zod-ის სქემით, რადგან, როგორც წესი, აქ ყალიბდება ფორმის ფორმა. პირველი ორი ნაბიჯისთვის - პერსონალური დეტალები და შეკვეთის შეყვანა - ყველაფერი მარტივია: საჭირო სტრიქონები, ნომრები მინიმუმებით და რიცხვი. საინტერესო ნაწილი იწყება, როცა ცდილობ პირობითი წესების გამოხატვას.
იმპორტი { z } "zod"-დან;
ექსპორტი const formSchema = z.object({ firstName: z.string().min(1, "საჭირო"), ელფოსტა: z.string().email("არასწორი ელფოსტა"), ფასი: z.number().min(0), რაოდენობა: z.number().min(1), taxRate: z.number(), hasAccount:(No"]esum. z.string().სურვილისამებრ(), პაროლი: z.string().სურვილისამებრ(), კმაყოფილება: z.number().min(1).max(5), დადებითი გამოხმაურება: z.string().სურვილისამებრ(), გაუმჯობესებაგამოხმაურება: z.string().სურვილისამებრ(),}).superRefine((data, {Afsda)=ha"{Afsda) =ha"= (!data.username) {ctx.addIssue({cod: "custom", path: ["username"], message: "Required" } } if (!data.password || data.password.length < 6) {ctx.addIssue({cod: "password"]"); }
if (data.satisfaction >= 4 && !data.positiveFeedback) { ctx.addIssue({ კოდი: "ჩვეულებრივი", ბილიკი: ["positiveFeedback"], შეტყობინება: "გთხოვთ გააზიაროთ ის, რაც მოგეწონათ" }); }
if (data.satisfaction <= 2 && !data.improvementFeedback) { ctx.addIssue({ კოდი: "საბაჟო", გზა:["improvementFeedback"], შეტყობინება: "გთხოვთ გვითხრათ რა გავაუმჯობესოთ" }); }});
ექსპორტის ტიპი FormData = z.infer
გაითვალისწინეთ, რომ მომხმარებლის სახელი და პაროლი აკრეფილია როგორც არასავალდებულო() მიუხედავად იმისა, რომ ისინი პირობითად საჭიროა, რადგან Zod-ის ტიპის დონის სქემა აღწერს ობიექტის ფორმას და არა წესებს, რომლებიც არეგულირებს ველებს მნიშვნელობას. პირობითი მოთხოვნა უნდა იცხოვროს superRefine-ში, რომელიც მუშაობს ფორმის დამოწმების შემდეგ და აქვს წვდომა სრულ ობიექტზე. რომ განცალკევება არ არის ნაკლი; ეს არის მხოლოდ ის, რისთვისაც ინსტრუმენტია შექმნილი: superRefine არის ის ადგილი, სადაც ჯვარედინი ველის ლოგიკა მიდის, როდესაც მისი გამოხატვა შეუძლებელია თავად სქემის სტრუქტურაში. აქ ასევე აღსანიშნავია ის, რასაც ეს სქემა არ გამოხატავს. მას არ აქვს გვერდების კონცეფცია, არ აქვს კონცეფცია იმისა, თუ რომელი ველები რომელ წერტილში ჩანს და არც ნავიგაციის კონცეფცია. ეს ყველაფერი სხვაგან იცხოვრებს. ფორმის კომპონენტი
იმპორტი { useForm, useWatch } "react-hook-form"-დან;იმპორტი { zodResolver }-დან "@hookform/resolvers/zod";იმპორტი {useMutation }-დან "@tanstack/react-query";იმპორტი {useState, useMemo } "react"-დან;import type {formSchema"-დან;
const STEPS = ["დეტალები", "შეკვეთა", "ანგარიში", "მიმოხილვა"];
აკრიფეთ OrderPayload = FormData & { subtotal: ნომერი; გადასახადი: ნომერი; სულ: ნომერი };
ექსპორტის ფუნქცია RHFMultiStepForm() { const [ნაბიჯი, setStep] = useState(0);
const mutation = useMutation({ mutationFn: async (payload: OrderPayload) => { const res = ელოდება მიღებას("/api/orders", { მეთოდი: "POST", headers: { "Content-Type": "application/json" }, სხეული: JSON.stringify(payload), }); თუ (!res.ok) ჩააგდოს ახალი შეცდომა ("ვერ იქნა გაგზავნილი"); დაბრუნება res.json(); }, });
const { register, control, handleSubmit, formState: { errors }, } = useForm
დაბრუნება (
);}იხილეთ კალამი SurveyJS-03-RHF [ჩანგალი] sixthextinction-ით. აქ საკმაოდ ბევრი რამ ხდება და ღირს შენელება, რათა შეამჩნიოთ სად დასრულდა ყველაფერი.
მიღებული მნიშვნელობები - ქვეტოტალი, გადასახადი, ჯამი - კომპონენტში გამოითვლება useWatch-ისა და useMemo-ის მეშვეობით, რადგან ისინი დამოკიდებულია ცოცხალი ველის მნიშვნელობებზე და მათთვის სხვა ბუნებრივი ადგილი არ არის. მომხმარებლის სახელის, პაროლის, დადებითი გამოხმაურების და გაუმჯობესების გამოხმაურების ხილვადობის წესები JSX-ში შემოსული პირობითია. ნაბიჯის გამოტოვების ლოგიკა — განხილვის გვერდი გამოჩნდება მხოლოდ მაშინ, როდესაც სულ >= 100 — ჩართულია showSubmit ცვლადში და რენდერის მდგომარეობა მე-3 საფეხურზე. თავად ნავიგაცია არის მხოლოდ useState მრიცხველი, რომელსაც ჩვენ ხელით ვამატებთ. React Query ამუშავებს განმეორებით ცდებს, ქეშირებას და გაუქმებას. ფორმა უბრალოდ მოუწოდებს mutation.mutate დადასტურებული მონაცემებით.
არცერთი ეს არ არის არასწორი, თავისთავად. ეს ჯერ კიდევ იდიომურია React და კომპონენტი საკმაოდ ეფექტურია იმის წყალობით, თუ როგორ ხდება RHF იზოლაციის ხელახალი რენდირება. მაგრამ თუ ამას გადასცემდით ვინმეს, ვინც არ დაწერა და სთხოვეთ ახსნას, რა პირობებში ჩნდება განხილვის გვერდი, მათ უნდა გაეცნოთ showSubmit, ნაბიჯი 3 რენდერის მდგომარეობა და ნავიგაციის ღილაკის ლოგიკა - სამი ცალკე ადგილი - აღადგინონ წესი, რომელიც შეიძლებოდა ერთ სტრიქონში ყოფილიყო მითითებული. ფორმა მუშაობს, დიახ, მაგრამ ქცევა ნამდვილად არ არის შესამოწმებელი, როგორც სისტემა. ეს უნდა განხორციელდეს გონებრივად. რაც მთავარია, მისი შეცვლა მოითხოვს ინჟინერიის ჩართულობას. მცირე შესწორებაც კი, როგორიცაა კორექტირება, როდესაც მიმოხილვის ნაბიჯი გამოჩნდება, ნიშნავს კომპონენტის რედაქტირებას, ვალიდაციის განახლებას, გაყვანის მოთხოვნის გახსნას, განხილვის მოლოდინს და ხელახლა დანერგვას. ნაწილი 2: სქემაზე ორიენტირებული (SurveyJS) ახლა ავაშენოთ იგივე ნაკადი სქემის გამოყენებით. ინსტალაცია npm დააინსტალირე survey-core survey-react-ui @tanstack/react-query
survey-core MIT-ის ლიცენზირებული პლატფორმისგან დამოუკიდებელი გაშვების ძრავა, რომელიც უზრუნველყოფს SurveyJS-ის ფორმების რენდერირებას - ნაწილი, რომელიც ჩვენ აქ გვაინტერესებს. ის იღებს JSON სქემას, აშენებს მისგან შიდა მოდელს და ამუშავებს ყველაფერს, რაც სხვაგვარად იცხოვრებდა თქვენს React კომპონენტში: ხილვადობის გამონათქვამების შეფასება, მიღებული მნიშვნელობების გამოთვლა, გვერდის მდგომარეობის მართვა, ვალიდაციის თვალყურის დევნება და იმის გადაწყვეტა, თუ რას ნიშნავს „სრული“ იმის გათვალისწინებით, თუ რომელი გვერდები იყო რეალურად ნაჩვენები.
survey-react-ui UI / რენდერის ფენა, რომელიც აკავშირებს ამ მოდელს React-თან. ეს არსებითად არის
ისინი ერთად მოგცემენ სრულად ფუნქციონალურ, მრავალგვერდიანი ფორმის გაშვებას კონტროლის ნაკადის ერთი ხაზის დაწერის გარეშე. თავად სქემის ფორმატი არის, როგორც უკვე აღვნიშნეთ, მხოლოდ JSON – არ არის DSL ან რაიმე საკუთრება. თქვენ შეგიძლიათ შეიყვანოთ ის, იმპორტი იქონიოთ ფაილიდან, მიიღოთ ის API-დან, ან შეინახოთ იგი მონაცემთა ბაზის სვეტში და დატენიანოთ გაშვების დროს. იგივე ფორმა, როგორც მონაცემები აქ არის იგივე ფორმა, ამჯერად გამოხატული, როგორც JSON ობიექტი. სქემა განსაზღვრავს ყველაფერს: სტრუქტურას, ვალიდაციას, ხილვადობის წესებს, გამოთვლებს, გვერდის ნავიგაციას - და გადასცემს მას მოდელს, რომელიც აფასებს მას გაშვების დროს. აი, როგორ გამოიყურება ეს სრულად:
ექსპორტი const surveySchema = {სათაური: "Order Flow", showProgressBar: "top", გვერდები: [ { name: "details", ელემენტები: [ {type: "text", name: "firstName", isRequired: true }, {type: "text", name: "email", inputType: "email", isRequired: "email", isRequired: "email", isRequired: "email": }] } ] }, { სახელი: "შეკვეთა", ელემენტები: [ { ტიპი: "ტექსტი", დასახელება: "ფასი", inputType: "number", defaultValue: 0 }, {type: "text", name: "quantity", inputType: "number", defaultValue: 1 }, {type: "Dropdown",სახელი: "taxRate", defaultValue: 0.1, არჩევანი: [ { value: 0.05, text: "5%" }, { value: 0.1, text: "10%" }, { value: 0.15, text: "15%" } ] }, { type: "expression", დასახელება: "quity type:" "გამოხატვა", დასახელება: "გადასახადი", გამოთქმა: "{subtotal} {taxRate}" }, {type: "expression", სახელი: "total", გამოთქმა: "{subtotal} + {tax}" } ] }, { name: "account", ელემენტები: [ { type: "radiogroup", name: "hasAccount] "no:"tip", "extest": "username", visualIf: "{hasAccount} = 'დიახ'", isRequired: true }, { type: "text", name: "password", inputType: "password", visualIf: "{hasAccount} = 'დიახ'", isRequired: true, ვალიდატორები: [{ type: "text", 6, mins:" ტიპი: "რეიტინგი", სახელი: "კმაყოფილება", rateMin: 1, rateMax: 5 }, { type: "comment", name: "positiveFeedback", visualIf: "{satisfaction} >= 4" }, {type: "comment", name: "improvementFeedback", visualIf: "{satisfaction", "viewIf: "{satisfaction"" <}} visualIf: "{სულ} >= 100", ელემენტები: [] } ]};
შეადარე ეს RHF ვერსიას ერთი წუთით.
superRefine ბლოკი, რომელიც პირობითად მოითხოვდა მომხმარებლის სახელსა და პაროლს, გაქრა. visualIf: "{hasAccount} = 'დიახ'" ერთად isRequired: true ამუშავებს ორივე პრობლემას ერთად, თავად ველზე, სადაც თქვენ უნდა იპოვოთ ისინი. useWatch + useMemo ჯაჭვი, რომელიც გამოთვლიდა ქვეჯამს, გადასახადს და ჯამს, შეიცვალა სამი გამოხატვის ველით, რომლებიც მიუთითებენ ერთმანეთს სახელით. განხილვის გვერდის მდგომარეობა, რომელიც RHF ვერსიაში რეკონსტრუქციული იყო მხოლოდ showSubmit-ის მეშვეობით, ნაბიჯი 3 რენდერის ფილიალში. და ბოლოს, ნავი ღილაკის ლოგიკა არის გვერდის ობიექტზე ერთი visualIf თვისება.
იგივე ლოგიკაა. უბრალოდ, სქემა აძლევს მას საცხოვრებელ ადგილს, სადაც ის იზოლირებულად ჩანს, ვიდრე გავრცელდეს კომპონენტზე. ასევე, გაითვალისწინეთ, რომ სქემა იყენებს ტიპს: „გამოხატვა“ ქვეჯამისთვის, გადასახადისთვის და ჯამისთვის. გამოხატვა არის მხოლოდ წაკითხვადი და გამოიყენება ძირითადად გამოთვლილი მნიშვნელობების საჩვენებლად. SurveyJS ასევე მხარს უჭერს ტიპს: 'html' სტატიკური შინაარსისთვის, მაგრამ გამოთვლილი მნიშვნელობებისთვის გამოხატვა სწორი არჩევანია. ახლა React მხარისთვის. გაწევა და წარდგენა ძალიან მარტივი. დააკავშირეთ onComplete თქვენს API-ზე იმავე გზით - useMutation-ის ან უბრალო გამოტანის მეშვეობით:
იმპორტი { useState, useEffect, useRef } "react"-დან; იმპორტი { useMutation } "@tanstack/react-query"-დან; იმპორტი { Model }-დან "survey-core";იმპორტი { Survey } საწყისი "survey-react-ui";იმპორტი "survey-core/curvey";core.
ექსპორტის ფუნქცია SurveyForm() { const [model] = useState(() => new Model(surveySchema));
const mutation = useMutation({ mutationFn: ასინქრონული (მონაცემები) => { const res = ელოდება მიღებას("/api/orders", { მეთოდი: "POST", headers: { "Content-Type": "application/json" }, სხეული: JSON.stringify(data), }); თუ (!res.ok) ჩააგდოს ახალი შეცდომა ("ვერ იქნა გაგზავნილი"); დაბრუნება res.json(); }, });
const mutationRef = useRef(mutation); mutationRef.current = მუტაცია; useEffect(() => {const handler = (გამგზავნი) => mutationRef.current.mutate(sender.data); model.onComplete.add(handler); return () => model.onComplete.remove(handler); }, [model]); // ref თავიდან აიცილებს დამმუშავებლის ხელახლა რეგისტრაციას ყოველი რენდერი (მუტაციის ობიექტის იდენტურობა იცვლება)
დაბრუნება (
<>
იხილეთ Pen SurveyJS-03-SurveyJS [forked] by sixthextinction.
onComplete ირთვება, როდესაც მომხმარებელი მიაღწევს ბოლო ხილული გვერდის ბოლოს. ასე რომ, თუ ჯამი არასოდეს გადააჭარბებს 100-ს და მიმოხილვის გვერდი გამოტოვებულია, ის მაინც სწორად ირთვება, რადგან SurveyJS აფასებს ხილვადობას, სანამ გადაწყვეტს რას ნიშნავს „ბოლო გვერდი“. შემდეგ, sender.data შეიცავს ყველა პასუხს გამოთვლილ მნიშვნელობებთან ერთად (ქვეჯამობა, გადასახადი, ჯამი), როგორც პირველი კლასის ველები, ასე რომ, API დატვირთვა იდენტურია RHF-ის ვერსიის ხელით აწყობილი onSubmit-ში. ThemutationRef ნიმუში არის იგივე, რასაც მიაღწიეთ ყველგან, სადაც გჭირდებათ სტაბილური მოვლენის დამმუშავებელი მნიშვნელობაზე, რომელიც იცვლება ყოველ რენდერზე – არაფერია SurveyJS-ისთვის სპეციფიკური.
React კომპონენტი საერთოდ აღარ შეიცავს რაიმე ბიზნეს ლოგიკას. არ არის useWatch, პირობითი JSX, ნაბიჯების მრიცხველი, useMemo ჯაჭვი, superRefine. React აკეთებს იმას, რისთვისაც რეალურად კარგია: კომპონენტის რენდერი და API ზარის გაყვანილობა. რა გადავიდა Out Of React?
შეშფოთება RHF დასტა SurveyJS ხილვადობა JSX ფილიალები ხილული თუ მიღებული მნიშვნელობები useWatch / useMemo გამოხატულება ჯვარედინი ველის წესები სუპერდახვეწა სქემის პირობები ნავიგაცია ნაბიჯის მდგომარეობა გვერდი ხილული თუ წესის ადგილმდებარეობა განაწილებულია ფაილებში ცენტრალიზებული სქემაში
რაც რჩება React-ში არის განლაგება, სტილი, წარდგენის გაყვანილობა და აპლიკაციის ინტეგრაცია, რაც იმას ნიშნავს, რომ React რეალურად არის შექმნილი. ყველაფერი დანარჩენი გადავიდა სქემაში და იმის გამო, რომ სქემა მხოლოდ JSON ობიექტია, მისი შენახვა შესაძლებელია მონაცემთა ბაზაში, თქვენი აპლიკაციის კოდისგან დამოუკიდებლად დამოუკიდებლად ვერსიის შენახვა, ან შიდა ხელსაწყოების რედაქტირება განლაგების საჭიროების გარეშე. პროდუქტის მენეჯერს, რომელსაც უნდა შეცვალოს მიმოხილვის გვერდის ამოქმედების ზღვარი, შეუძლია ამის გაკეთება კომპონენტზე შეხების გარეშე. ეს არის მნიშვნელოვანი საოპერაციო განსხვავება იმ გუნდებისთვის, სადაც ფორმის ქცევა ხშირად ვითარდება და ყოველთვის არ არის ამოძრავებული ინჟინრების მიერ. როდის გამოვიყენოთ თითოეული მიდგომა? აქ არის კარგი წესი, რომელიც მუშაობს ჩემთვის: წარმოიდგინეთ, რომ მთლიანად წაშალოთ ფორმა. რას დაკარგავდი?
თუ ეს ეკრანებია, გსურთ კომპონენტზე ორიენტირებული ფორმები. თუ ეს არის ბიზნეს ლოგიკა, როგორიცაა ზღურბლები, განშტოების წესები და პირობითი მოთხოვნები, რომლებიც კოდირებს რეალურ გადაწყვეტილებებს, თქვენ გჭირდებათ სქემის ძრავა.
ანალოგიურად, თუ ცვლილებები, რომლებიც თქვენს გზაზე მოდის, ძირითადად ეხება ეტიკეტებს, ველებს და განლაგებას, RHF კარგად მოგემსახურებათ. თუ ისინი ეხება პირობებს, შედეგებს და წესებს, რომელთა კორექტირებაც თქვენს ოპერაციებს ან იურიდიულ გუნდს შეიძლება დასჭირდეს სამშაბათს ნაშუადღევს ბილეთის წარდგენის გარეშე, SurveyJS-ის სქემის მოდელი უფრო პატიოსანია. ეს ორი მიდგომა ნამდვილად არ ეწინააღმდეგება ერთმანეთს. ისინი მიმართავენ სხვადასხვა კლასის პრობლემებს და შეცდომა, რომლის თავიდან აცილებაც ღირს, არის აბსტრაქციის შეუსაბამობა ლოგიკის წონასთან - წესების სისტემის კომპონენტად მიქცევა, რადგან ეს ნაცნობი ინსტრუმენტია, ან პოლიტიკის ძრავის მიღწევა, რადგან ფორმა გაიზარდა სამ საფეხურამდე და შეიძინა პირობითი ველი. ფორმა, რომელიც ჩვენ აქ ავაშენეთ, მიზანმიმართულად დგას საზღვრის მახლობლად, საკმარისად რთული, რათა გამოავლინოს განსხვავება, მაგრამ არც ისე ექსტრემალური, რომ შედარება გაყალბებულად ჩანდეს. უძრავი ფორმების უმეტესობა, რომლებიც თქვენს კოდების ბაზაში უხერხული გახდა, ალბათ, იმავე საზღვრებთან დგას და, როგორც წესი, ჩნდება კითხვა, დაასახელა თუ არა ვინმემ, თუ რა არის სინამდვილეში. გამოიყენეთ React Hook Form + Zod როდესაც:
ფორმები არის CRUD-ზე ორიენტირებული; ლოგიკა არის არაღრმა და UI-ზე ორიენტირებული; ინჟინრები ფლობენ ყველა ქცევას; Backend რჩება ჭეშმარიტების წყაროდ.
გამოიყენეთ SurveyJS, როდესაც:
ფორმები შიფრავს ბიზნეს გადაწყვეტილებებს; წესები ვითარდება UI-სგან დამოუკიდებლად; ლოგიკა უნდა იყოს ხილული, აუდიტორული ან ვერსიირებული; არაინჟინრები გავლენას ახდენენ ქცევაზე; ერთი და იგივე ფორმა უნდა გადიოდეს მრავალ ფრონტზე.
