এই নিবন্ধটি SurveyJS দ্বারা স্পনসর করা হয়েছে এমন একটি মানসিক মডেল রয়েছে যা বেশিরভাগ প্রতিক্রিয়া বিকাশকারীরা কখনও জোরে আলোচনা না করেই শেয়ার করে। যে ফর্ম সবসময় উপাদান হতে অনুমিত হয়. এর মানে একটি স্ট্যাক যেমন:
স্থানীয় রাজ্যের জন্য প্রতিক্রিয়া হুক ফর্ম (ন্যূনতম রি-রেন্ডার, ergonomic ক্ষেত্রের নিবন্ধন, অপরিহার্য মিথস্ক্রিয়া)। বৈধকরণের জন্য Zod (ইনপুট সঠিকতা, সীমানা যাচাইকরণ, টাইপ-নিরাপদ পার্সিং)। ব্যাকএন্ডের জন্য প্রতিক্রিয়া ক্যোয়ারী: জমা, পুনরায় চেষ্টা, ক্যাশিং, সার্ভার সিঙ্ক এবং আরও অনেক কিছু।
এবং বেশিরভাগ ফর্মের জন্য - আপনার লগইন স্ক্রীন, আপনার সেটিংস পৃষ্ঠা, আপনার CRUD মডেলগুলি - এটি সত্যিই ভাল কাজ করে৷ প্রতিটি অংশ তার কাজ করে, তারা পরিষ্কারভাবে রচনা করে এবং আপনি আপনার অ্যাপ্লিকেশনের অংশগুলিতে যেতে পারেন যা আসলে আপনার পণ্যকে আলাদা করে। কিন্তু প্রতি একবার কিছুক্ষণের মধ্যে, একটি ফর্ম দৃশ্যমানতার নিয়মগুলির মতো জিনিসগুলি জমা করতে শুরু করে যা পূর্ববর্তী উত্তরগুলির উপর নির্ভর করে, বা প্রাপ্ত মানগুলি যা তিনটি ক্ষেত্রের মধ্য দিয়ে ক্যাসকেড করে। হতে পারে এমনকি পুরো পৃষ্ঠাগুলি যা বাদ দেওয়া উচিত বা চলমান মোটের উপর ভিত্তি করে দেখানো উচিত। আপনি একটি useWatch এবং একটি ইনলাইন শাখার সাথে প্রথম শর্তসাপেক্ষে পরিচালনা করেন, যা ঠিক আছে। তারপর আরেকটা। তারপরে আপনি ক্রস-ফিল্ড নিয়মগুলিকে এনকোড করতে সুপাররিফাইনের কাছে পৌঁছেছেন যা আপনার Zod স্কিমা স্বাভাবিক উপায়ে প্রকাশ করতে পারে না। তারপরে, ধাপে ন্যাভিগেশন ব্যবসার যুক্তি ফাঁস শুরু করে। কিছু সময়ে, আপনি যা তৈরি করেছেন তা দেখেন এবং বুঝতে পারেন যে ফর্মটি আসলে আর UI নয়। এটি একটি সিদ্ধান্ত প্রক্রিয়ার বেশি, এবং উপাদান গাছটি ঠিক যেখানে আপনি এটি সংরক্ষণ করেছেন। এখানেই আমি মনে করি প্রতিক্রিয়ার ফর্মগুলির জন্য মানসিক মডেল ভেঙে যায় এবং এটি সত্যিই কারও দোষ নয়। আরএইচএফ + জোড স্ট্যাকটি যার জন্য ডিজাইন করা হয়েছিল তার জন্য দুর্দান্ত। সমস্যাটি হল যে আমরা এটিকে বিন্দুর আগে ব্যবহার করতে থাকি যেখানে এর বিমূর্ততাগুলি সমস্যার সাথে মেলে কারণ বিকল্পটির সম্পূর্ণরূপে ফর্ম সম্পর্কে চিন্তা করার একটি ভিন্ন উপায় প্রয়োজন। এই নিবন্ধটি সেই বিকল্প সম্পর্কে। এটি দেখানোর জন্য, আমরা একই মাল্টি-স্টেপ ফর্মটি দুবার তৈরি করব:
রিঅ্যাক্ট হুক ফর্ম + জোড জমা দেওয়ার জন্য রিঅ্যাক্ট কোয়েরির সাথে সংযুক্ত, SurveyJS এর সাথে, যা একটি ফর্মকে ডেটা হিসাবে বিবেচনা করে — একটি সাধারণ JSON স্কিমা — একটি উপাদান গাছের পরিবর্তে।
একই প্রয়োজনীয়তা, একই শর্তসাপেক্ষ যুক্তি, শেষে একই API কল। তারপরে আমরা ঠিক কী স্থানান্তরিত হয়েছে এবং কী রয়ে গেছে তা ম্যাপ করব এবং কোন মডেলটি আপনি ব্যবহার করবেন এবং কখন ব্যবহার করবেন তা নির্ধারণ করার জন্য একটি ব্যবহারিক উপায় তৈরি করব। আমরা যে ফর্মটি তৈরি করছি:
এই ফর্মটি একটি 4-পদক্ষেপ প্রবাহ ব্যবহার করবে: ধাপ 1: বিশদ বিবরণ
প্রথম নাম (প্রয়োজনীয়), ইমেল (প্রয়োজনীয়, বৈধ বিন্যাস)।
ধাপ 2: অর্ডার করুন
ইউনিট মূল্য, পরিমাণ, করের হার, প্রাপ্ত: সাবটোটাল, ট্যাক্স, মোট
ধাপ 3: অ্যাকাউন্ট এবং প্রতিক্রিয়া
আপনি একটি অ্যাকাউন্ট আছে? (হ্যাঁ/না) যদি হ্যাঁ → ব্যবহারকারীর নাম + পাসওয়ার্ড, উভয়ই প্রয়োজন। যদি না হয় → ইমেইল ইতিমধ্যেই ধাপ 1 এ সংগ্রহ করা হয়েছে।
সন্তুষ্টি রেটিং (1-5) যদি ≥ 4 → জিজ্ঞাসা করে "আপনি কি পছন্দ করেছেন?" যদি ≤ 2 → জিজ্ঞাসা করে "আমরা কি উন্নতি করতে পারি?"
ধাপ 4: পর্যালোচনা করুন
মোট >= 100 হলেই দেখা যায় চূড়ান্ত জমা।
এই চরম নয়. তবে এটি স্থাপত্যগত পার্থক্য প্রকাশ করার জন্য যথেষ্ট। পার্ট 1: কম্পোনেন্ট-চালিত (প্রতিক্রিয়া হুক ফর্ম + জোড) ইনস্টলেশন npm install react-hook-form zod @hookform/resolvers @tanstack/react-query
জোড স্কিমা আসুন Zod স্কিমা দিয়ে শুরু করা যাক, কারণ এটি সাধারণত যেখানে ফর্মের আকৃতি প্রতিষ্ঠিত হয়। প্রথম দুই ধাপের জন্য — ব্যক্তিগত বিবরণ এবং অর্ডার ইনপুট — সবকিছুই সোজা: প্রয়োজনীয় স্ট্রিং, ন্যূনতম সংখ্যা এবং একটি enum। আপনি শর্তসাপেক্ষ নিয়ম প্রকাশ করার চেষ্টা করার সময় আকর্ষণীয় অংশ শুরু হয়।
"zod" থেকে { z } আমদানি করুন;
রপ্তানি কনস্ট ফর্মস্কেমা = z.অবজেক্ট({ firstName: z.string().min(1, "আবশ্যক"), ইমেল: z.string().email("অবৈধ ইমেল"), মূল্য: z.number().min(0), পরিমাণ: z.number().min(1), ট্যাক্স রেট: z.number().min(1), ট্যাক্স রেট: z.number(", [Yumeunt(), আছে "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 (fine, }) super == (data.hasAccount === "হ্যাঁ") { if (!data.username) { ctx.addIssue({ কোড: "কাস্টম", পথ: ["ব্যবহারকারীর নাম"], বার্তা: "প্রয়োজনীয়" }); ["পাসওয়ার্ড"], বার্তা: "সর্বনিম্ন ৬ অক্ষর" } });
if (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" থেকে, "maata" টাইপ করুন, "ডিমা" টাইপ করুন।
const STEPS = ["বিস্তারিত", "অর্ডার", "অ্যাকাউন্ট", "রিভিউ"];
টাইপ করুন OrderPayload = FormData & { সাবটোটাল: সংখ্যা; ট্যাক্স: সংখ্যা; মোট: সংখ্যা };
এক্সপোর্ট ফাংশন RHFMultiStepForm() { const [step, setStep] = useState(0);
const mutation = useMutation({ mutationFn: async (payload: OrderPayload) => { const res = আনার অপেক্ষা করুন("/api/orders", { পদ্ধতি: "পোস্ট", শিরোনাম: { "Content-Type": "application/json" }, বডি: JSON.stringify(পেলোড), }); যদি (!res.ok) নতুন ত্রুটি নিক্ষেপ ("সাবমিট করতে ব্যর্থ"); res.json(); }, });
const { register, control, handleSubmit, formState: { errors }, } = useForm
ফেরত দিন (
);}পেন সার্ভে JS-03-RHF [কাঁটাযুক্ত] ছয়টি বিলুপ্তির দ্বারা দেখুন। এখানে অনেক কিছু ঘটছে, এবং জিনিসগুলি কোথায় শেষ হয়েছে তা লক্ষ্য করার জন্য ধীরগতি করা মূল্যবান।
প্রাপ্ত মানগুলি — সাবটোটাল, ট্যাক্স, মোট — UseWatch এবং useMemo-এর মাধ্যমে কম্পোনেন্টে গণনা করা হয় কারণ তারা লাইভ ফিল্ডের মানগুলির উপর নির্ভর করে এবং তাদের জন্য অন্য কোনও প্রাকৃতিক জায়গা নেই। ব্যবহারকারীর নাম, পাসওয়ার্ড, পজিটিভ ফিডব্যাক এবং উন্নতি ফিডব্যাকের দৃশ্যমানতা নিয়মগুলি JSX-এ ইনলাইন শর্তসাপেক্ষে লাইভ। স্টেপ-স্কিপিং লজিক — রিভিউ পৃষ্ঠাটি তখনই প্রদর্শিত হয় যখন মোট >= 100 — শো-সাবমিট ভেরিয়েবলের মধ্যে এমবেড করা হয় এবং ধাপ 3-এ রেন্ডার শর্ত থাকে। নেভিগেশন নিজেই একটি useState কাউন্টার যা আমরা ম্যানুয়ালি বৃদ্ধি করছি। প্রতিক্রিয়া ক্যোয়ারী পুনরায় চেষ্টা, ক্যাশিং এবং অবৈধকরণ পরিচালনা করে। ফর্মটি শুধুমাত্র বৈধ ডেটা সহ mutation.mutate কল করে।
এর কোনটিই ভুল নয়। এটি এখনও ইডিওম্যাটিক রিঅ্যাক্ট, এবং কম্পোনেন্টটি বেশ পারফরম্যান্ট ধন্যবাদ যেভাবে RHF পুনরায় রেন্ডারকে বিচ্ছিন্ন করে। কিন্তু আপনি যদি এটি এমন কাউকে দিতেন যিনি এটি লিখেননি এবং তাদের ব্যাখ্যা করতে বলুন যে পর্যালোচনা পৃষ্ঠাটি কোন পরিস্থিতিতে প্রদর্শিত হবে, তাদের শো-সাবমিট, ধাপ 3 রেন্ডার শর্ত এবং নেভি বোতাম যুক্তির মাধ্যমে ট্রেস করতে হবে — তিনটি পৃথক জায়গা — একটি নিয়ম পুনর্গঠন করতে যা এক লাইনে বলা যেতে পারে। ফর্মটি কাজ করে, হ্যাঁ, কিন্তু আচরণটি একটি সিস্টেম হিসাবে সত্যিই পরিদর্শনযোগ্য নয়। এটা মানসিকভাবে কার্যকর করতে হবে। আরও গুরুত্বপূর্ণ, এটি পরিবর্তন করার জন্য ইঞ্জিনিয়ারিং জড়িত থাকা প্রয়োজন। এমনকি একটি ছোট খামচি, যেমন পর্যালোচনা পদক্ষেপটি দেখানো হলে সামঞ্জস্য করা, মানে উপাদান সম্পাদনা করা, বৈধতা আপডেট করা, একটি পুল অনুরোধ খোলা, পর্যালোচনার জন্য অপেক্ষা করা এবং আবার স্থাপন করা। পার্ট 2: স্কিমা-চালিত (সার্ভেজেএস) এখন একটি স্কিমা ব্যবহার করে একই প্রবাহ তৈরি করা যাক। ইনস্টলেশন npm সার্ভে-কোর সার্ভে-রিঅ্যাক্ট-ইউআই @tanstack/react-query ইনস্টল করুন
সার্ভে-কোরএমআইটি-লাইসেন্সযুক্ত প্ল্যাটফর্ম-স্বাধীন রানটাইম ইঞ্জিন যা SurveyJS-এর ফর্ম রেন্ডারিংকে ক্ষমতা দেয় — যে অংশটি আমরা এখানে যত্নশীল। এটি একটি JSON স্কিমা নেয়, এটি থেকে একটি অভ্যন্তরীণ মডেল তৈরি করে এবং অন্যথায় আপনার প্রতিক্রিয়া উপাদানে থাকা সমস্ত কিছু পরিচালনা করে: দৃশ্যমানতার অভিব্যক্তি মূল্যায়ন করা, প্রাপ্ত মান গণনা করা, পৃষ্ঠার অবস্থা পরিচালনা করা, বৈধতা ট্র্যাক করা এবং কোন পৃষ্ঠাগুলি আসলে দেখানো হয়েছে তা দেওয়া "সম্পূর্ণ" মানে কী তা নির্ধারণ করা। সার্ভে-রিঅ্যাক্ট-ইউআই/রেন্ডারিং লেয়ার যা সেই মডেলটিকে রিঅ্যাক্টের সাথে সংযুক্ত করে। এটি মূলত একটি <সার্ভে মডেল={মডেল} /> উপাদান যা ইঞ্জিনের অবস্থার পরিবর্তন হলেই পুনরায় রেন্ডার হয়। SurveyJS UI লাইব্রেরিগুলি Angular, Vue3 এবং অন্যান্য অনেক ফ্রেমওয়ার্কের জন্যও উপলব্ধ।
একসাথে, তারা আপনাকে একটি সম্পূর্ণ কার্যকরী, বহু-পৃষ্ঠা ফর্ম রানটাইম দেয় নিয়ন্ত্রণ প্রবাহের একটি লাইন না লিখে। স্কিমা ফর্ম্যাটটি নিজেই, যেমনটি আগে বলা হয়েছে, শুধুমাত্র একটি JSON — কোন DSL বা মালিকানা কিছু নয়। আপনি এটিকে ইনলাইন করতে পারেন, এটি একটি ফাইল থেকে আমদানি করতে পারেন, এটি একটি API থেকে আনতে পারেন বা এটি একটি ডাটাবেস কলামে সংরক্ষণ করতে পারেন এবং রানটাইমে এটি হাইড্রেট করতে পারেন৷ একই ফর্ম, ডেটা হিসাবে এখানে একই ফর্ম, এবার JSON অবজেক্ট হিসাবে প্রকাশ করা হয়েছে। স্কিমা সবকিছুকে সংজ্ঞায়িত করে: গঠন, বৈধতা, দৃশ্যমানতার নিয়ম, প্রাপ্ত গণনা, পৃষ্ঠা নেভিগেশন — এবং এটিকে একটি মডেলের কাছে হস্তান্তর করে যা রানটাইমে এটিকে মূল্যায়ন করে। এটি সম্পূর্ণরূপে দেখতে কেমন তা এখানে:
export const surveySchema = { শিরোনাম: "অর্ডার ফ্লো", showProgressBar: "top", পৃষ্ঠা: [ { name: "details", উপাদান: [ { type: "text", name: "firstName", isRequired: true }, { type: "text", name: "email", inputType: "email", isRequired: "true", "ইমেইল টাইপ" [ইমেল টাইপ: সত্য, ইমেল টাইপ }] } ] }, { নাম: "অর্ডার", উপাদান: [ { প্রকার: "টেক্সট", নাম: "মূল্য", ইনপুট টাইপ: "সংখ্যা", ডিফল্ট মান: 0 }, { প্রকার: "টেক্সট", নাম: "পরিমাণ", ইনপুট টাইপ: "সংখ্যা", ডিফল্ট মান: 1 }, { প্রকার: "ড্রপডাউন",নাম: "করের হার", ডিফল্ট মান: 0.1, পছন্দ: [ { মান: 0.05, পাঠ্য: "5%" }, { মান: 0.1, পাঠ্য: "10%" }, { মান: 0.15, পাঠ্য: "15%" } ] }, { প্রকার: "প্রকাশ", নাম: "প্রকাশ্য: {তাল}}, "প্রকাশ্য" {তাল}} প্রকার: "এক্সপ্রেশন", নাম: "কর", অভিব্যক্তি: "{সাবটোটাল} {ট্যাক্সরেট}" }, { প্রকার: "প্রকাশ", নাম: "মোট", অভিব্যক্তি: "{উপ-টোটাল} + {ট্যাক্স}" } ] }, {নাম: "অ্যাকাউন্ট", উপাদান: [ { প্রকার: "রেডিওগ্রুপ", নাম: "হ্যাসঅ্যাক}", "পছন্দ:" {হ্যাসঅ্যাক}" প্রকার: "টেক্সট", নাম: "ব্যবহারকারীর নাম", দৃশ্যমান যদি: "{hasAccount} = 'হ্যাঁ'", isRequired: true }, { type: "text", name: "password", inputType: "password", visibleIf: "{hasAccount} = 'হ্যাঁ'", isRequired: true: 6 টেক্সট, টেক্সট টাইপ করুন, {6} "সর্বনিম্ন 6 অক্ষর" }] }, { প্রকার: "রেটিং", নাম: "সন্তুষ্টি", রেটমিন: 1, রেটম্যাক্স: 5 }, { প্রকার: "মন্তব্য", নাম: "পজিটিভ ফিডব্যাক", দৃশ্যমান যদি: "{সন্তুষ্টি} >= 4" }, {টাইপ: "মন্তব্য", নাম: "অনুমোদিত", "অনুমোদিত" <= 2" } ] }, { name: "review", visibleIf: "{total} >= 100", উপাদান: [] } ]};
এক মুহূর্তের জন্য RHF সংস্করণের সাথে এটি তুলনা করুন।
সুপাররিফাইন ব্লক যে শর্তসাপেক্ষে প্রয়োজন ব্যবহারকারীর নাম এবং পাসওয়ার্ড চলে গেছে। visibleIf: "{hasAccount} = 'হ্যাঁ'" isRequired এর সাথে মিলিত: সত্য উভয় উদ্বেগকে একত্রে পরিচালনা করে, মাঠে নিজেই, যেখানে আপনি তাদের খুঁজে পাওয়ার আশা করবেন। useWatch + useMemo চেইন যা সাবটোটাল, ট্যাক্স এবং মোট গণনা করে তিনটি এক্সপ্রেশন ফিল্ড দ্বারা প্রতিস্থাপিত হয় যা একে অপরকে নামের দ্বারা উল্লেখ করে। পর্যালোচনা পৃষ্ঠার শর্ত, যা RHF সংস্করণে শুধুমাত্র শো-সাবমিট, ধাপ 3 রেন্ডার শাখার মাধ্যমে ট্রেস করে পুনর্গঠনযোগ্য ছিল। এবং পরিশেষে, নেভি বোতাম যুক্তি একটি একক দৃশ্যমানIf পৃষ্ঠা বস্তুর সম্পত্তি.
সেখানেও একই যুক্তি। এটা ঠিক যে স্কিমা এটিকে বসবাসের একটি জায়গা দেয় যেখানে এটি বিচ্ছিন্নভাবে দৃশ্যমান, বরং উপাদান জুড়ে ছড়িয়ে পড়ে। এছাড়াও, মনে রাখবেন যে স্কিমা টাইপ ব্যবহার করে: সাবটোটাল, ট্যাক্স এবং মোটের জন্য 'এক্সপ্রেশন'। এক্সপ্রেশন শুধুমাত্র পঠনযোগ্য এবং প্রধানত গণনা করা মান প্রদর্শন করতে ব্যবহৃত হয়। সার্ভেজেএস স্ট্যাটিক বিষয়বস্তুর জন্য টাইপ: 'html' সমর্থন করে, কিন্তু গণনা করা মানগুলির জন্য, অভিব্যক্তিটি সঠিক পছন্দ। এখন প্রতিক্রিয়া দিক জন্য. রেন্ডারিং এবং জমা খুব সহজ. ওয়্যার onComplete আপনার API-তে একইভাবে — ইউজ মিউটেশন বা প্লেইন ফেচের মাধ্যমে:
"react" থেকে { useState, useEffect, useRef } আমদানি করুন; "@tanstack/react-query" থেকে { useMutation } আমদানি করুন; "survey-core" থেকে { মডেল } আমদানি করুন; "survey-react-ui" থেকে { সমীক্ষা } আমদানি করুন; "survey-core/cs-survey"-আমদানি করুন
এক্সপোর্ট ফাংশন SurveyForm() { const [model] = useState(() => new Model(surveySchema));
const mutation = useMutation({ mutationFn: async (data) => { const res = আনার অপেক্ষা করুন("/api/orders", { পদ্ধতি: "পোস্ট", শিরোনাম: { "Content-Type": "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); return () => model.onComplete.remove(হ্যান্ডলার); }, [মডেল]); // রেফ প্রতি রেন্ডার হ্যান্ডলারকে পুনরায় নিবন্ধন করা এড়ায় (মিউটেশন অবজেক্ট আইডেন্টিটি পরিবর্তন)
ফিরে <> <সার্ভে মডেল={মডেল} /> {mutation.isError &&
পেন সার্ভে JS-03-SurveyJS [কাঁটাযুক্ত] ছয়টি বিলুপ্তির দ্বারা দেখুন।
ব্যবহারকারী যখন শেষ দৃশ্যমান পৃষ্ঠার শেষে পৌঁছায় তখন onComplete ফায়ার হয়। তাই যদি মোট 100 অতিক্রম না করে এবং পর্যালোচনা পৃষ্ঠাটি বাদ দেওয়া হয়, তবে এটি এখনও সঠিকভাবে ফায়ার করে কারণ SurveyJS "শেষ পৃষ্ঠা" এর অর্থ কী তা নির্ধারণ করার আগে দৃশ্যমানতা মূল্যায়ন করে। তারপর, sender.data-এ প্রথম শ্রেণীর ক্ষেত্র হিসাবে গণনা করা মান (সাবটোটাল, ট্যাক্স, মোট) সহ সমস্ত উত্তর রয়েছে, তাই এপিআই পেলোডটি RHF সংস্করণটি onSubmit-এ ম্যানুয়ালি একত্রিত করা একই রকম। দmutationRef প্যাটার্ন সেই একই একটি যা আপনি যে কোনও জায়গায় পৌঁছাতে চান যেখানে আপনার একটি স্থিতিশীল ইভেন্ট হ্যান্ডলার প্রয়োজন এমন একটি মান যা প্রতিটি রেন্ডারে পরিবর্তিত হয় - এটি সম্পর্কে সার্ভেজেএস-নির্দিষ্ট কিছুই নেই।
প্রতিক্রিয়া উপাদানে আর কোনো ব্যবসায়িক যুক্তি নেই। কোন ইউজওয়াচ নেই, কোন শর্তসাপেক্ষ JSX নেই, কোন স্টেপ কাউন্টার নেই, কোন মেমো চেইন নেই, সুপাররিফাইন নেই। রিঅ্যাক্ট সেই কাজটি করছে যা আসলে ভালো: একটি কম্পোনেন্ট রেন্ডার করা এবং এটিকে একটি API কলে ওয়্যারিং করা। কি প্রতিক্রিয়া আউট সরানো?
উদ্বেগ আরএইচএফ স্ট্যাক সার্ভে জেএস দৃশ্যমানতা জেএসএক্স শাখা দৃশ্যমান যদি প্রাপ্ত মান useWatch/useMemo অভিব্যক্তি ক্রস-ফিল্ড নিয়ম সুপাররিফাইন স্কিমার শর্ত নেভিগেশন ধাপ রাষ্ট্র পৃষ্ঠা দৃশ্যমান যদি নিয়মের অবস্থান ফাইল জুড়ে বিতরণ স্কিমা মধ্যে কেন্দ্রীভূত
রিঅ্যাক্টে যা থাকে তা হল লেআউট, স্টাইলিং, সাবমিশন ওয়্যারিং এবং অ্যাপ ইন্টিগ্রেশন, যা বলতে গেলে, রিঅ্যাক্ট আসলে যে জিনিসগুলির জন্য ডিজাইন করা হয়েছে। অন্য সবকিছু স্কিমাতে স্থানান্তরিত হয়েছে, এবং স্কিমাটি শুধুমাত্র একটি JSON অবজেক্ট, এটি একটি ডাটাবেসে সংরক্ষণ করা যেতে পারে, আপনার অ্যাপ্লিকেশন কোড থেকে স্বাধীনভাবে সংস্করণ করা যেতে পারে, বা কোনও স্থাপনার প্রয়োজন ছাড়াই অভ্যন্তরীণ টুলিংয়ের মাধ্যমে সম্পাদনা করা যেতে পারে। একজন প্রোডাক্ট ম্যানেজার যার থ্রেশহোল্ড পরিবর্তন করতে হবে যা রিভিউ পৃষ্ঠাটিকে ট্রিগার করে কম্পোনেন্ট স্পর্শ না করেই তা করতে পারে। এটি দলগুলির জন্য একটি অর্থপূর্ণ অপারেশনাল পার্থক্য যেখানে ফর্ম আচরণ ঘন ঘন বিকশিত হয় এবং সর্বদা ইঞ্জিনিয়ারদের দ্বারা চালিত হয় না। কখন প্রতিটি পদ্ধতি ব্যবহার করবেন? এখানে থাম্বের একটি ভাল নিয়ম যা আমার জন্য কাজ করে: ফর্মটি সম্পূর্ণরূপে মুছে ফেলার কল্পনা করুন। আপনি কি হারাবেন?
এটি স্ক্রিন হলে, আপনি উপাদান-চালিত ফর্ম চান। যদি এটি ব্যবসায়িক যুক্তি হয়, যেমন থ্রেশহোল্ড, শাখার নিয়ম এবং শর্তসাপেক্ষ প্রয়োজনীয়তা যা বাস্তব সিদ্ধান্তগুলিকে এনকোড করে, আপনি একটি স্কিমা ইঞ্জিন চান।
একইভাবে, যদি আপনার পথে আসা পরিবর্তনগুলি বেশিরভাগই লেবেল, ক্ষেত্র এবং লেআউট সম্পর্কে হয়, তাহলে RHF আপনাকে ভাল পরিবেশন করবে। যদি সেগুলি শর্ত, ফলাফল এবং নিয়মগুলি সম্পর্কে হয় যা আপনার অপারেশন বা আইনি দলকে মঙ্গলবার বিকেলে টিকিট ফাইল না করে সামঞ্জস্য করতে হতে পারে, তাহলে SurveyJS-এর সাথে স্কিমা মডেলটি আরও সৎ উপযুক্ত। এই দুটি পন্থা আসলে একে অপরের সাথে প্রতিযোগিতার মধ্যে নেই। তারা বিভিন্ন শ্রেণীর সমস্যার সমাধান করে, এবং এড়ানোর যোগ্য ভুলটি হল যুক্তির ওজনের সাথে বিমূর্ততাকে অমিল করা — একটি নিয়ম সিস্টেমকে একটি উপাদানের মতো আচরণ করা কারণ এটি পরিচিত টুল, অথবা একটি নীতি ইঞ্জিনের কাছে পৌঁছানো কারণ একটি ফর্ম তিনটি ধাপে বৃদ্ধি পেয়েছে এবং একটি শর্তাধীন ক্ষেত্র অর্জন করেছে৷ আমরা এখানে যে ফর্মটি তৈরি করেছি তা ইচ্ছাকৃতভাবে সীমানার কাছাকাছি বসে, পার্থক্যটি প্রকাশ করার জন্য যথেষ্ট জটিল কিন্তু এতটা চরম নয় যে তুলনাটি কারচুপির মনে হয়। বেশিরভাগ বাস্তব রূপ যা আপনার কোডবেসে অবাস্তব হয়ে উঠেছে সম্ভবত সেই একই সীমানার কাছাকাছি বসে আছে এবং প্রশ্নটি সাধারণত হয় যে তারা আসলে কি নাম দিয়েছে কিনা। প্রতিক্রিয়া হুক ফর্ম + জোড ব্যবহার করুন যখন:
ফর্মগুলি CRUD-ভিত্তিক; যুক্তি অগভীর এবং UI-চালিত; প্রকৌশলীরা সকল আচরণের মালিক; ব্যাকএন্ড সত্যের উৎস থেকে যায়।
সার্ভেজেএস ব্যবহার করুন যখন:
ফর্মগুলি ব্যবসায়িক সিদ্ধান্তগুলিকে এনকোড করে; নিয়মগুলি UI থেকে স্বাধীনভাবে বিকশিত হয়; যুক্তি অবশ্যই দৃশ্যমান, নিরীক্ষণযোগ্য বা সংস্করণ হতে হবে; অ-প্রকৌশলী আচরণ প্রভাবিত করে; একই ফর্ম একাধিক ফ্রন্টএন্ড জুড়ে চলতে হবে।
