Энэхүү нийтлэлийг SurveyJS ивээн тэтгэсэн болно Ихэнх React хөгжүүлэгчид үүнийг чангаар хэлэлцэхгүйгээр хуваалцдаг оюун санааны загвар байдаг. Энэ маягтууд нь үргэлж бүрэлдэхүүн хэсэг байх ёстой. Энэ нь стек гэсэн үг:
Орон нутгийн мужид зориулсан React Hook маягт (хамгийн бага дахин дүрслэл, эргономикийн талбарын бүртгэл, зайлшгүй харилцан үйлчлэл). Баталгаажуулалтын Zod (оролтын зөв, хилийн баталгаажуулалт, төрөл аюулгүй задлан шинжлэх). Backend-д зориулсан React Query: илгээх, дахин оролдох, кэш хийх, серверийн синк хийх гэх мэт.
Таны нэвтрэх дэлгэц, тохиргооны хуудас, CRUD загвар зэрэг ихэнх маягтын хувьд энэ нь үнэхээр сайн ажилладаг. Хэсэг бүр үүргээ гүйцэтгэдэг, тэд цэвэрхэн зохиодог бөгөөд та өөрийн бүтээгдэхүүнийг үнэхээр ялгаж буй програмынхаа хэсгүүдэд шилжиж болно. Гэхдээ хааяа нэг маягт нь өмнөх хариултаас хамаарах харагдах байдлын дүрэм, эсвэл гурван талбараар дамждаг үүсмэл утгууд зэрэг зүйлсийг хуримтлуулж эхэлдэг. Бүр алгасах эсвэл ажиллаж байгаа нийт дүнгээр харуулах ёстой бүх хуудсууд ч байж магадгүй. Та эхний нөхцөлийг useWatch болон шугаман салбараар зохицуулдаг бөгөөд энэ нь зүгээр. Дараа нь өөр. Дараа нь та Zod схем тань ердийн байдлаар илэрхийлэх боломжгүй хөндлөн талбарын дүрмийг кодлохын тулд superRefine-д хүрч байна. Дараа нь алхам навигаци нь бизнесийн логикийг алдаж эхэлдэг. Хэзээ нэгэн цагт та бүтээсэн зүйлээ хараад энэ маягт нь UI биш гэдгийг ойлгодог. Энэ бол шийдвэр гаргах үйл явц бөгөөд бүрэлдэхүүний мод нь яг таны хадгалсан газар юм. Энэ бол миний бодлоор React дахь хэлбэрийн сэтгэцийн загвар эвдэрсэн бөгөөд энэ нь үнэхээр хэний ч буруу биш юм. RHF + Zod стек нь зориулалтын дагуу маш сайн. Асуудлын гол нь бид үүнийг хийсвэрлэл нь асуудалтай таарч байгаа үед үргэлжлүүлэн ашиглах хандлагатай байдаг, учир нь өөр хувилбар нь маягтын талаар бүхэлд нь өөр арга барилыг шаарддаг. Энэ нийтлэл нь энэ хувилбарын тухай юм. Үүнийг харуулахын тулд бид яг ижил олон шатлалт маягтыг хоёр удаа бүтээх болно:
React Hook Form + Zod нь React Query-д холбогдсон байна. Маягтыг бүрэлдэхүүн мод гэхээсээ илүү энгийн JSON схем гэж үздэг SurveyJS-тэй.
Ижил шаардлага, ижил нөхцөлт логик, төгсгөлд нь ижил API дуудлага. Дараа нь бид яг юу нүүсэн, юу үлдсэнийг зураглаж, аль загварыг хэзээ, хэзээ ашиглахаа шийдэх бодит арга замыг гаргах болно. Бидний барьж буй хэлбэр:
Энэ маягт нь 4 үе шаттай урсгалыг ашиглана: Алхам 1: Дэлгэрэнгүй мэдээлэл
Нэр (шаардлагатай), Имэйл (шаардлагатай, хүчинтэй формат).
Алхам 2: Захиалга
Нэгж үнэ, Тоо хэмжээ, Татварын хувь хэмжээ, Гарсан: Дунд нийлбэр, Татвар, Нийт.
Алхам 3: Бүртгэл ба санал хүсэлт
Та данстай юу? (Тийм/Үгүй) Хэрэв тийм → хэрэглэгчийн нэр + нууц үг бол хоёулаа шаардлагатай. Хэрэв Үгүй → 1-р алхамд имэйлийг аль хэдийн цуглуулсан.
Сэтгэл ханамжийн үнэлгээ (1–5) Хэрэв ≥ 4 бол → “Чи юунд дуртай байсан бэ?” гэж асуу. Хэрэв ≤ 2 → “Бид юуг сайжруулах вэ?” гэж асуу.
Алхам 4: Хянах
Нийт >= 100 бол л харагдана Эцсийн мэдүүлэг.
Энэ бол хэт туйлшрал биш юм. Гэхдээ энэ нь архитектурын ялгааг ил гаргахад хангалттай. 1-р хэсэг: Бүрэлдэхүүн хэсэг (React Hook Form + Zod) Суурилуулалт npm install react-hook-form zod @hookform/resolvers @tanstack/react-query
Зод схем Зод схемээс эхэлцгээе, учир нь энэ нь ихэвчлэн маягтын хэлбэрийг тогтоодог. Эхний хоёр алхамд - хувийн мэдээлэл, захиалгын оролт - бүх зүйл энгийн: шаардлагатай мөрүүд, хамгийн бага тоо, тоолол. Сонирхолтой хэсэг нь нөхцөлт дүрмийг илэрхийлэхийг оролдох үед эхэлдэг.
"zod" -аас { z } импортлох;
экспортын const formSchema = z.object({ firstName: z.string().min(1, "Шаардлагатай"), имэйл: z.string().email("Хүчингүй имэйл"), үнэ: z.number().min(0), тоо хэмжээ: z.number().min(1), taxRate: z.number(), hasAccount(), username(),"z:"z z.string().optional(), нууц үг: z.string().optional(), сэтгэл ханамж: z.number().min(1).max(5), эерэгFeedback:z.string().optional(), improvementFeedback: z.string().optional(),}).superRefine((өгөгдөл, ctxda) ="s. (!data.username) { ctx.addIssue({код: "хэрэглэгчийн нэр", зам: ["хэрэглэгчийн нэр"], мессеж: "Шаардлагатай" }); } if (!data.password || data.password.length < 6) { ctx.addIssue({код: "хэрэглэгч", үг "M"sp:}"); }
if (data.satisfaction >= 4 && !data.positiveFeedback) { ctx.addIssue({код: "захиалгат", зам: ["эерэг санал хүсэлт"], мессеж: "Таалагдсан зүйлээ хуваалцана уу" }); }
хэрэв (өгөгдөл.сэтгэл ханамж <= 2 && !data.improvementFeedback) { ctx.addIssue ({ код: "захиалгат", зам:["improvementFeedback"], мессеж: "Юуг сайжруулах талаар бидэнд хэлнэ үү" }); }});
экспортын төрөл FormData = z.infer
Zod-ийн төрлийн түвшний схем нь талбар чухал үед хамаарах дүрмийг бус объектын хэлбэрийг тодорхойлдог тул хэрэглэгчийн нэр болон нууц үг нь нөхцөлт шаардлагатай хэдий ч нэмэлт() хэлбэрээр бичигдсэн болохыг анхаарна уу. Нөхцөлт шаардлага нь дүрсийг баталгаажуулсны дараа ажилладаг бөгөөд бүрэн объект руу нэвтрэх боломжтой superRefine дотор байх ёстой. Энэ салалт нь алдаа биш юм; Энэ нь уг хэрэгсэлд зориулагдсан зүйл юм: superRefine нь схемийн бүтцэд өөрөө илэрхийлэх боломжгүй үед хөндлөн талбарын логик явдаг газар юм. Энд бас анхаарал татахуйц зүйл бол энэ схемд юуг илэрхийлэхгүй байгаа явдал юм. Энэ нь хуудасны тухай ойлголт, аль талбарууд аль цэг дээр харагдах тухай ойлголт, навигацийн тухай ойлголтгүй. Энэ бүхэн өөр газар амьдрах болно. Маягтын бүрэлдэхүүн хэсэг
"react-hook-form"-аас { useForm, useWatch } импортлох; "@hookform/resolvers/zod"-оос { zodResolver } импортлох; "@tanstack/react-query"-ээс { useMutation } импортлох; "react"-аас { useState, useMemo } импортлох; Import { formSchema}-аас FormSchema, төрөл "/;";
const STEPS = ["дэлгэрэнгүй", "захиалга", "акаунт", "хяналт"];
төрөл OrderPayload = FormData & { дэд нийлбэр: тоо; татвар: тоо; нийт: тоо };
экспортын функц RHFMultiStepForm() { const [алхам, setStep] = useState(0);
const мутаци = useMutation({ mutationFn: асинхронгуй (ачаалал: OrderPayload) => { const res = хүлээж авахыг хүлээж байна("/api/orders", { арга: "POST", гарчиг: { "Агуулгын төрөл": "application/json" }, их бие: JSON.stringify(ачаалал), }); хэрэв (!res.ok) шинэ алдаа гаргавал("Илгээж чадсангүй"); буцаах res.json(); }, });
const { бүртгэл, хяналт, handleSubmit, formState: { алдаа }, } = useForm
буцаах (
);}Үзэгний судалгааJS-03-RHF [салаатай] зургаа дахь удаагаа харна уу. Энд маш их зүйл болж байгаа бөгөөд бүх зүйл хаана болсныг анзаарахын тулд удаашрах нь зүйтэй.
Үүссэн утгууд - дэд нийлбэр, татвар, нийт - бүрэлдэхүүн хэсэгт useWatch болон useMemo-р тооцоолдог, учир нь тэдгээр нь амьд талбарын утгуудаас хамаардаг бөгөөд өөр байгалийн газар байхгүй. Хэрэглэгчийн нэр, нууц үг, эерэг санал хүсэлт, сайжруулах санал хүсэлтийн харагдах байдлын дүрмүүд нь JSX-д шугаман нөхцөл байдлаар ажилладаг. Алхам алгасах логик буюу нийт >= 100 болсон үед л гарч ирэх тойм хуудас нь showSubmit хувьсагч болон 3-р алхам дээр үзүүлэх нөхцөл дотор суулгагдсан. Навигаци нь зүгээр л бидний гараар нэмэгдүүлж байгаа useState тоолуур юм. React Query нь дахин оролдох, кэш хийх, хүчингүй болгох асуудлыг зохицуулдаг. Маягт нь зөвхөн батлагдсан өгөгдөлтэй mutation.mutate гэж нэрлэдэг.
Эдгээрийн аль нь ч буруу биш. Энэ нь хэлц үгийн хариу үйлдэл хэвээр байгаа бөгөөд RHF хэрхэн тусгаарлаж, дахин дүрслүүлсний ачаар бүрэлдэхүүн хэсэг нь нэлээд гүйцэтгэлтэй байдаг. Гэхдээ хэрэв та үүнийг бичээгүй хүнд өгч, хянан шалгах хуудас ямар нөхцөлд гарч ирэхийг тайлбарлахыг хүсвэл, тэд showSubmit, 3-р алхамын үзүүлэх нөхцөл, навигацын товчлуурын логикийг гурван тусдаа газар мөрдөж, нэг мөрөнд бичсэн байж болох дүрмийг сэргээх хэрэгтэй болно. Маягт нь ажилладаг, тийм ээ, гэхдээ зан төлөвийг системийн хувьд шалгах боломжгүй юм. Үүнийг оюун санааны хувьд гүйцэтгэх ёстой. Хамгийн гол нь үүнийг өөрчлөхөд инженерийн оролцоо шаардлагатай. Хяналтын алхам гарч ирэх үед тохируулах гэх мэт жижиг тохируулга ч гэсэн бүрэлдэхүүн хэсгийг засах, баталгаажуулалтыг шинэчлэх, татах хүсэлтийг нээх, хянан үзэхийг хүлээж, дахин байршуулах гэсэн үг юм. 2-р хэсэг: Схем дээр суурилсан (SurveyJS) Одоо ижил урсгалыг схем ашиглан бүтээцгээе. Суурилуулалт npm survey-core survey-react-ui @tanstack/react-query суулгана
survey-coreThe MIT-ийн лицензтэй, платформоос хамааралгүй ажиллах цагийн хөдөлгүүр нь SurveyJS-ийн маягтыг дүрслэх боломжийг олгодог бөгөөд энэ нь бидний анхаарах зүйл юм. Энэ нь JSON схемийг авч, үүнээс дотоод загварыг бүтээж, таны React бүрэлдэхүүн хэсэгт хамаарах бүх зүйлийг зохицуулдаг: харагдах байдлын илэрхийллийг үнэлэх, үүсмэл утгыг тооцоолох, хуудасны төлөвийг удирдах, баталгаажуулалтыг хянах, аль хуудсыг бодитоор харуулсан бол "бүрэн" гэж юу болохыг шийдэх. survey-react-ui Тухайн загварыг React-тэй холбодог UI / дүрслэх давхарга. Энэ нь үндсэндээ хөдөлгүүрийн төлөв өөрчлөгдөх бүрт дахин дүрслэгддэг <Судалгааны загвар={model} /> бүрэлдэхүүн хэсэг юм. SurveyJS UI номын санг Angular, Vue3 болон бусад олон фреймворкуудад ашиглах боломжтой.
Тэд хамтдаа танд хяналтын урсгалын нэг мөр бичихгүйгээр бүрэн ажиллагаатай, олон хуудас маягтын ажиллах цагийг өгдөг. Өмнө дурьдсанчлан схемийн формат нь өөрөө зүгээр л JSON юм - ямар ч DSL эсвэл ямар ч өмчлөлийн зүйл байхгүй. Та үүнийг дотор нь оруулах, файлаас импортлох, API-аас татаж авах эсвэл өгөгдлийн сангийн баганад хадгалах, ажиллах үед чийгшүүлэх боломжтой. Өгөгдөлтэй ижил маягт Энэ удаад JSON объект хэлбэрээр илэрхийлэгдсэн ижил маягт энд байна. Уг схем нь бүтэц, баталгаажуулалт, харагдах байдлын дүрэм, үүсмэл тооцоолол, хуудасны навигаци гэх мэт бүх зүйлийг тодорхойлж, түүнийг ажиллах үед үнэлдэг Загварт шилжүүлдэг. Энэ нь бүрэн эхээр нь дараах байдалтай байна.
export const surveySchema = { гарчиг: "Захиалгын урсгал", showProgressBar: "дээд", хуудсууд: [ {нэр: "дэлгэрэнгүй", элементүүд: [ {төрөл: "текст", нэр: "firstName", шаардлагатай: үнэн }, { төрөл: "текст", нэр: "и-мэйл", inputType: "и-мэйл", "шаардлагатай": "хүчинтэй: ID" [{ имэйл" }] } ] }, { нэр: "захиалга", элементүүд: [ { төрөл: "текст", нэр: "үнэ", inputType: "тоо", defaultValue: 0 }, { төрөл: "текст", нэр: "тоо хэмжээ", inputType: "тоо", defaultValue: 1 }, { төрөл: "унадаг",нэр: "taxRate", defaultValue: 0.1, сонголтууд: [ {утга: 0.05, текст: "5%" }, {утга: 0.1, текст: "10%" }, {утга: 0.15, текст: "15%" } ] }, {төрөл: "илэрхийлэл", нэр: "{subtotal" {}төрөл," "илэрхийлэл", нэр: "татвар", илэрхийлэл: "{дэд нийт} {taxRate}" }, { төрөл: "илэрхийлэл", нэр: "нийт", илэрхийлэл: "{дэд нийлбэр} + {татвар}" } ] }, { нэр: "данс", элементүүд: [ {төрөл: "радио бүлэг", нэр: "hasAccount", ["] төрөл ":" {t}", нэр: "хэрэглэгчийн нэр", visibleIf: "{hasAccount} = 'Тийм'", шаардлагатай: үнэн }, { төрөл: "текст", нэр: "нууц үг", inputType: "нууц үг", visibleIf: "{hasAccount} = 'Тийм'", шаардлагатай: үнэн, баталгаажуулагчууд: [{hasAccount} = 'Тийм': [{hasAccount}: "Тийм": "6-р бичвэр" тэмдэгт" }] }, { төрөл: "үнэлгээ", нэр: "сэтгэл ханамж", rateMin: 1, rateMax: 5 }, { төрөл: "сэтгэгдэл", нэр: "эерэг санал хүсэлт", visibleХэрэв: "{сэтгэл ханамж} >= 4" }, { төрөл: "сэтгэгдэл", нэр: "improvementFeed" <{satisfaction:" ] }, { нэр: "хяналт", visibleIf: "{нийт} >= 100", элементүүд: [] } ]};
Үүнийг RHF хувилбартай хэсэгхэн зуур харьцуулаарай.
Нөхцөлтэйгээр шаардлагатай хэрэглэгчийн нэр, нууц үг болох superRefine блок байхгүй болсон. visibleIf: "{hasAccount} = "Тийм""-г isRequired-тэй хослуулсан: true нь таны хайж олохыг хүссэн талбар дээрх хоёр асуудлыг хамтад нь зохицуулдаг. Дэд нийлбэр, татвар, нийлбэрийг тооцдог useWatch + useMemo гинж нь бие биенээ нэрээр нь иш татсан илэрхийллийн гурван талбараар солигдоно. RHF хувилбарт зөвхөн showSubmit-ээр дамжуулан мөшгих замаар сэргээн засварлах боломжтой байсан хянан үзэх хуудасны нөхцөл, 3-р алхам бол дүрслэх салбар. Эцэст нь хэлэхэд, навигацийн товчлуурын логик нь хуудасны объект дээрх ганц visibleIf шинж чанар юм.
Үүнтэй ижил логик байдаг. Зүгээр л схем нь бүрэлдэхүүн хэсгүүдэд тархахаас илүү тусад нь харагдахуйц амьдрах газрыг өгдөг. Түүнчлэн, схем нь дэд нийлбэр, татвар, нийлбэрийн төрөлд 'илэрхийлэл'-ийг ашигладаг болохыг анхаарна уу. Илэрхийлэл нь зөвхөн унших зориулалттай бөгөөд тооцоолсон утгыг харуулахад голчлон ашиглагддаг. SurveyJS нь статик агуулгын хувьд 'html' төрлийг дэмждэг боловч тооцоолсон утгуудын хувьд илэрхийлэл нь зөв сонголт юм. Одоо хариу үйлдэл хийх тал дээр. Тайлбарлах, оруулах Маш энгийн. onComplete утсыг API руугаа ижил аргаар холбогдоно уу — useMutation эсвэл энгийн таталтаар:
"react"-аас { useState, useEffect, useRef } импортлох; "@tanstack/react-query"-ээс { useMutation } импортлох; "судалгаа-гол"-оос { Загвар } импортлох; "судалгаа-реакт-ui"-аас { Судалгаа } импортлох;"судалгаа-гол/сурвалжлага-core.css" импорт;
экспортын функц SurveyForm() { const [загвар] = useState(() => шинэ загвар(surveySchema));
const мутаци = useMutation({ mutationFn: async (өгөгдөл) => { const res = хүлээж авахыг хүлээж байна("/api/orders", { арга: "POST", гарчиг: { "Агуулгын төрөл": "application/json" }, Үндсэн хэсэг: JSON.stringify(өгөгдөл), }); хэрэв (!res.ok) шинэ алдаа гаргавал("Илгээж чадсангүй"); буцаах res.json(); }, });
const mutationRef = useRef(мутаци); mutationRef.current = мутаци; useEffect(() => { const зохицуулагч = (илгээгч) => mutationRef.current.mutate(sender.data); model.onComplete.add(харьцуулагч); return () => model.onComplete.remove(харьцагч);}, [загвар]); // ref нь дүрслэх бүрд зохицуулагчийг дахин бүртгүүлэхээс зайлсхийдэг (мутацийн объектын таних тэмдэг өөрчлөгддөг)
буцах ( <> <Судалгааны загвар={model} /> {mutation.isError &&
Pen SurveyJS-03-SurveyJS [салаатай] зургаас харна уу.
Хэрэглэгч сүүлийн харагдах хуудасны төгсгөлд хүрэх үед onComplete ажилладаг. Хэрэв нийт дүн хэзээ ч 100-г давж, шүүмжийн хуудсыг алгасах юм бол SurveyJS "сүүлийн хуудас" гэж юу болохыг шийдэхээсээ өмнө харагдах байдлыг үнэлдэг тул зөв ажиллана. Дараа нь sender.data нь бүх хариултыг тооцоолсон утгуудын хамт (дэд нийлбэр, татвар, нийлбэр) нэгдүгээр зэрэглэлийн талбар болгон агуулдаг тул API ачаалал нь RHF хувилбарын onSubmit дээр гараар угсарсантай ижил байна. ThemutationRef загвар нь рэндэр болгонд өөрчлөгддөг утгын дээр тогтвортой үйл явдал зохицуулагч хэрэгтэй бол хаана ч хүрэх боломжтой бөгөөд SurveyJS-д хамаарах зүйл байхгүй.
React бүрэлдэхүүн хэсэг нь бизнесийн логикийг огт агуулаагүй. UseWatch, нөхцөлт JSX, алхам тоолуур, useMemo сүлжээ, superRefine байхгүй. React нь өөрийн сайн зүйлээ хийж байна: бүрэлдэхүүн хэсгийг үзүүлж, API дуудлагад холбох. Урвалаас юу гарсан бэ?
Санаа зоволт RHF стек SurveyJS Харагдах байдал JSX салбарууд visibleIf Үүсмэл утгууд useWatch / useMemo илэрхийлэл Талбай хоорондын дүрэм супер боловсронгуй болгох Схемийн нөхцөл Навигац алхам төлөв Хуудас visibleIf Дүрмийн байршил Файлуудад тараагдсан Схем дээр төвлөрсөн
React-д үлдэх зүйл бол зохион байгуулалт, загварчлал, илгээх утас, програмын нэгдмэл байдал, өөрөөр хэлбэл React нь үнэндээ зориулагдсан зүйл юм. Бусад бүх зүйл нь схемд шилжсэн бөгөөд схем нь зүгээр л JSON объект учраас үүнийг мэдээллийн санд хадгалах, програмын кодоос хамааралгүй хувилбар болгох, эсвэл байршуулах шаардлагагүйгээр дотоод хэрэглүүрээр дамжуулан засварлах боломжтой. Хяналтын хуудсыг өдөөх босгыг өөрчлөх шаардлагатай бүтээгдэхүүний менежер бүрэлдэхүүн хэсэгт хүрэлгүйгээр үүнийг хийх боломжтой. Энэ нь формын зан төлөв байнга өөрчлөгддөг бөгөөд инженерүүд үргэлж удирддаггүй багуудын хувьд чухал үйл ажиллагааны ялгаа юм. Арга тус бүрийг хэзээ ашиглах вэ? Энд надад тохирох сайн дүрэм байна: маягтыг бүхэлд нь устгана гэж төсөөлөөд үз дээ. Та юу алдах вэ?
Хэрэв энэ нь дэлгэц бол та бүрэлдэхүүн хэсэг дээр суурилсан маягтуудыг авахыг хүсч байна. Босго, салаалсан дүрэм, бодит шийдвэрийг кодлох нөхцөлт шаардлага гэх мэт бизнесийн логик бол та схемийн хөдөлгүүртэй болохыг хүсч байна.
Үүний нэгэн адил, хэрэв таны хийх өөрчлөлтүүд нь ихэвчлэн шошго, талбар, байршилтай холбоотой байвал RHF танд сайн үйлчлэх болно. Мягмар гарагийн үдээс хойш тасалбар мэдүүлэлгүйгээр танай үйл ажиллагаа эсвэл хуулийн баг тохируулах шаардлагатай нөхцөл, үр дүн, дүрмийн талаар ярьж байгаа бол SurveyJS-тэй схемийн загвар нь илүү үнэн зөв байх болно. Энэ хоёр хандлага нь хоорондоо үнэхээр өрсөлддөггүй. Тэд янз бүрийн ангиллын асуудлыг шийддэг бөгөөд зайлсхийх хэрэгтэй алдаа бол хийсвэрлэлийг логикийн жинтэй тааруулахгүй байх явдал юм - дүрмийн системийг танил хэрэглүүр учраас бүрэлдэхүүн хэсэг гэж үзэх, эсвэл маягт гурван алхам болж, нөхцөлт талбарыг олж авсан тул бодлогын хөдөлгүүрт хүрэх явдал юм. Бидний энд бүтээсэн хэлбэр нь хилийн ойролцоо зориудаар байрладаг бөгөөд ялгааг ил гаргахад хангалттай төвөгтэй боловч харьцуулалт нь хуурамч мэт санагдахгүй. Таны кодын санд тохиромжгүй болсон ихэнх бодит хэлбэрүүд нь яг тэр хилийн ойролцоо байх магадлалтай бөгөөд гол нь хэн нэгэн нь яг юу болохыг нь нэрлэсэн эсэхээс үл хамаарна. React Hook Form + Zod-г дараах тохиолдолд хэрэглэнэ.
Маягтууд нь CRUD-д чиглэсэн; Логик нь гүехэн бөгөөд UI-д суурилсан; Инженерүүд бүх зан үйлийг эзэмшдэг; Ар тал нь үнэний эх сурвалж хэвээр байна.
SurveyJS-г дараах тохиолдолд ашиглах:
Маягт нь бизнесийн шийдвэрийг кодлодог; Дүрэм нь UI-аас хамааралгүй өөрчлөгддөг; Логик нь харагдахуйц, шалгах боломжтой эсвэл хувилбартай байх ёстой; Инженер бус хүмүүс зан төлөвт нөлөөлдөг; Ижил маягт нь олон урд талдаа ажиллах ёстой.