ಈ ಲೇಖನವು SurveyJS ನಿಂದ ಪ್ರಾಯೋಜಿತವಾಗಿದೆ ಹೆಚ್ಚಿನ ರಿಯಾಕ್ಟ್ ಡೆವಲಪರ್ಗಳು ಅದನ್ನು ಜೋರಾಗಿ ಚರ್ಚಿಸದೆ ಹಂಚಿಕೊಳ್ಳುವ ಮಾನಸಿಕ ಮಾದರಿಯಿದೆ. ಆ ರೂಪಗಳು ಯಾವಾಗಲೂ ಘಟಕಗಳಾಗಿರಬೇಕು. ಇದರರ್ಥ ಈ ರೀತಿಯ ಸ್ಟಾಕ್:
ಸ್ಥಳೀಯ ರಾಜ್ಯಕ್ಕಾಗಿ ಹುಕ್ ಫಾರ್ಮ್ ಅನ್ನು ಪ್ರತಿಕ್ರಿಯಿಸಿ (ಕನಿಷ್ಠ ಮರು-ರೆಂಡರ್ಗಳು, ದಕ್ಷತಾಶಾಸ್ತ್ರದ ಕ್ಷೇತ್ರ ನೋಂದಣಿ, ಕಡ್ಡಾಯ ಸಂವಹನ). ಮೌಲ್ಯೀಕರಣಕ್ಕಾಗಿ Zod (ಇನ್ಪುಟ್ ಸರಿಯಾಗಿರುವುದು, ಗಡಿ ಮೌಲ್ಯೀಕರಣ, ಪ್ರಕಾರ-ಸುರಕ್ಷಿತ ಪಾರ್ಸಿಂಗ್). ಬ್ಯಾಕೆಂಡ್ಗಾಗಿ ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರಶ್ನೆ: ಸಲ್ಲಿಕೆ, ಮರುಪ್ರಯತ್ನಗಳು, ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆ, ಸರ್ವರ್ ಸಿಂಕ್, ಇತ್ಯಾದಿ.
ಮತ್ತು ಬಹುಪಾಲು ಫಾರ್ಮ್ಗಳಿಗೆ - ನಿಮ್ಮ ಲಾಗಿನ್ ಪರದೆಗಳು, ನಿಮ್ಮ ಸೆಟ್ಟಿಂಗ್ಗಳ ಪುಟಗಳು, ನಿಮ್ಮ CRUD ಮಾದರಿಗಳು - ಇದು ನಿಜವಾಗಿಯೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ತುಣುಕು ಅದರ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ, ಅವುಗಳು ಸ್ವಚ್ಛವಾಗಿ ಸಂಯೋಜಿಸುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ವಾಸ್ತವವಾಗಿ ಪ್ರತ್ಯೇಕಿಸುವ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಭಾಗಗಳಿಗೆ ನೀವು ಹೋಗಬಹುದು. ಆದರೆ ಪ್ರತಿ ಬಾರಿಯೂ, ಒಂದು ಫಾರ್ಮ್ ಹಿಂದಿನ ಉತ್ತರಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಗೋಚರತೆಯ ನಿಯಮಗಳು ಅಥವಾ ಮೂರು ಕ್ಷೇತ್ರಗಳ ಮೂಲಕ ಕ್ಯಾಸ್ಕೇಡ್ ಮಾಡುವ ಮೌಲ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಬಹುಶಃ ಸಂಪೂರ್ಣ ಪುಟಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಬೇಕು ಅಥವಾ ಚಾಲನೆಯಲ್ಲಿರುವ ಮೊತ್ತವನ್ನು ಆಧರಿಸಿ ತೋರಿಸಬೇಕು. ನೀವು ಯೂಸ್ವಾಚ್ ಮತ್ತು ಇನ್ಲೈನ್ ಶಾಖೆಯೊಂದಿಗೆ ಮೊದಲ ಷರತ್ತುಬದ್ಧತೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತೀರಿ, ಅದು ಉತ್ತಮವಾಗಿದೆ. ನಂತರ ಇನ್ನೊಂದು. ನಿಮ್ಮ Zod ಸ್ಕೀಮಾವು ಸಾಮಾನ್ಯ ರೀತಿಯಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಲು ಸಾಧ್ಯವಾಗದ ಕ್ರಾಸ್-ಫೀಲ್ಡ್ ನಿಯಮಗಳನ್ನು ಎನ್ಕೋಡ್ ಮಾಡಲು ನೀವು ಸೂಪರ್ ರಿಫೈನ್ ಅನ್ನು ತಲುಪುತ್ತಿರುವಿರಿ. ನಂತರ, ಹಂತದ ನ್ಯಾವಿಗೇಷನ್ ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಸೋರಿಕೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಕೆಲವು ಹಂತದಲ್ಲಿ, ನೀವು ನಿರ್ಮಿಸಿರುವುದನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ ಮತ್ತು ಫಾರ್ಮ್ ಇನ್ನು ಮುಂದೆ ನಿಜವಾಗಿಯೂ UI ಅಲ್ಲ ಎಂದು ಅರಿತುಕೊಳ್ಳುತ್ತೀರಿ. ಇದು ಹೆಚ್ಚು ನಿರ್ಧಾರ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ, ಮತ್ತು ಘಟಕ ಟ್ರೀ ನೀವು ಅದನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಂಭವಿಸಿದ ಸ್ಥಳವಾಗಿದೆ. ಇಲ್ಲಿಯೇ ರಿಯಾಕ್ಟ್ನಲ್ಲಿನ ರೂಪಗಳ ಮಾನಸಿಕ ಮಾದರಿಯು ಒಡೆಯುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ಇದು ನಿಜವಾಗಿಯೂ ಯಾರ ತಪ್ಪೂ ಅಲ್ಲ. RHF + Zod ಸ್ಟಾಕ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ್ದಕ್ಕಾಗಿ ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ಸಮಸ್ಯೆಯೆಂದರೆ, ಅದರ ಅಮೂರ್ತತೆಗಳು ಸಮಸ್ಯೆಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಹಂತದಿಂದ ನಾವು ಅದನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ ಏಕೆಂದರೆ ಪರ್ಯಾಯವು ರೂಪಗಳ ಬಗ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಯೋಚಿಸುವ ಅಗತ್ಯವಿದೆ. ಈ ಲೇಖನವು ಆ ಪರ್ಯಾಯದ ಬಗ್ಗೆ. ಇದನ್ನು ತೋರಿಸಲು, ನಾವು ಒಂದೇ ಬಹು-ಹಂತದ ಫಾರ್ಮ್ ಅನ್ನು ಎರಡು ಬಾರಿ ನಿರ್ಮಿಸುತ್ತೇವೆ:
ಸಲ್ಲಿಕೆಗಾಗಿ ಪ್ರಶ್ನೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ರಿಯಾಕ್ಟ್ ಹುಕ್ ಫಾರ್ಮ್ + ಝೋಡ್ ತಂತಿಯೊಂದಿಗೆ, ಸರ್ವೆಜೆಎಸ್ನೊಂದಿಗೆ, ಒಂದು ಫಾರ್ಮ್ ಅನ್ನು ಡೇಟಾ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ - ಒಂದು ಸರಳವಾದ JSON ಸ್ಕೀಮಾ - ಬದಲಿಗೆ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀ.
ಅದೇ ಅವಶ್ಯಕತೆಗಳು, ಅದೇ ಷರತ್ತುಬದ್ಧ ತರ್ಕ, ಕೊನೆಯಲ್ಲಿ ಅದೇ API ಕರೆ. ನಂತರ ನಾವು ನಿಖರವಾಗಿ ಏನನ್ನು ಸರಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವುದು ಉಳಿದಿದೆ ಎಂಬುದನ್ನು ನಾವು ಮ್ಯಾಪ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ನೀವು ಯಾವ ಮಾದರಿಯನ್ನು ಮತ್ತು ಯಾವಾಗ ಬಳಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವನ್ನು ರೂಪಿಸುತ್ತೇವೆ. ನಾವು ನಿರ್ಮಿಸುತ್ತಿರುವ ಫಾರ್ಮ್:
ಈ ಫಾರ್ಮ್ 4-ಹಂತದ ಹರಿವನ್ನು ಬಳಸುತ್ತದೆ: ಹಂತ 1: ವಿವರಗಳು
ಮೊದಲ ಹೆಸರು (ಅಗತ್ಯವಿದೆ), ಇಮೇಲ್ (ಅಗತ್ಯವಿದೆ, ಮಾನ್ಯ ಸ್ವರೂಪ).
ಹಂತ 2: ಆದೇಶ
ಘಟಕ ಬೆಲೆ, ಪ್ರಮಾಣ, ತೆರಿಗೆ ದರ, ಪಡೆದ: ಉಪಮೊತ್ತ, ತೆರಿಗೆ, ಒಟ್ಟು.
ಹಂತ 3: ಖಾತೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ
ನೀವು ಖಾತೆಯನ್ನು ಹೊಂದಿದ್ದೀರಾ? (ಹೌದು/ಇಲ್ಲ) ಹೌದು ಎಂದಾದರೆ → ಬಳಕೆದಾರಹೆಸರು + ಪಾಸ್ವರ್ಡ್, ಎರಡೂ ಅಗತ್ಯವಿದೆ. ಒಂದು ವೇಳೆ ಇಲ್ಲ → ಇಮೇಲ್ ಅನ್ನು ಈಗಾಗಲೇ ಹಂತ 1 ರಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
ತೃಪ್ತಿಯ ರೇಟಿಂಗ್ (1–5) ≥ 4 → "ನೀವು ಏನು ಇಷ್ಟಪಟ್ಟಿದ್ದೀರಿ?" ಎಂದು ಕೇಳಿದರೆ ≤ 2 → ಕೇಳಿದರೆ "ನಾವು ಏನನ್ನು ಸುಧಾರಿಸಬಹುದು?"
ಹಂತ 4: ವಿಮರ್ಶೆ
ಒಟ್ಟು >= 100 ಆಗಿದ್ದರೆ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಅಂತಿಮ ಸಲ್ಲಿಕೆ.
ಇದು ವಿಪರೀತವಲ್ಲ. ಆದರೆ ವಾಸ್ತುಶಿಲ್ಪದ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ಸಾಕು. ಭಾಗ 1: ಘಟಕ-ಚಾಲಿತ (ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಹುಕ್ ಫಾರ್ಮ್ + ಜೋಡ್) ಅನುಸ್ಥಾಪನೆ npm ಇನ್ಸ್ಟಾಲ್ ರಿಯಾಕ್ಟ್-ಹುಕ್-ಫಾರ್ಮ್ ಜೋಡ್ @ಹೂಕ್ಫಾರ್ಮ್/ರೆಸಾಲ್ವರ್ಸ್ @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), ತೆರಿಗೆ ದರ: z.ncumber z.enum(["ಹೌದು", "ಇಲ್ಲ"]), ಬಳಕೆದಾರಹೆಸರು: z.string().ಐಚ್ಛಿಕ(), ಪಾಸ್ವರ್ಡ್: z.string().ಐಚ್ಛಿಕ(), ತೃಪ್ತಿ: z.number().min(1).max(5), ಧನಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆ: z.string().supptional(), ಸುಧಾರಣೆ(optional(optional),}). ctx) => {if (data.hasAccount === "ಹೌದು") {if (!data.username) {ctx.addIssue({ಕೋಡ್: "ಕಸ್ಟಮ್", ಮಾರ್ಗ: ["ಬಳಕೆದಾರರ ಹೆಸರು"], ಸಂದೇಶ: "ಅಗತ್ಯವಿದೆ" }); {!data.password. "ಕಸ್ಟಮ್", ಮಾರ್ಗ: ["ಪಾಸ್ವರ್ಡ್"], ಸಂದೇಶ: "ಕನಿಷ್ಟ 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 } ಆಮದು ಮಾಡಿ; "@tanstack/react-query" ನಿಂದ {useMutation} ಆಮದು ಮಾಡಿ;
const STEPS = ["ವಿವರಗಳು", "ಆದೇಶ", "ಖಾತೆ", "ವಿಮರ್ಶೆ"];
ಆರ್ಡರ್ ಪೇಲೋಡ್ ಅನ್ನು ಟೈಪ್ ಮಾಡಿ = ಫಾರ್ಮ್ಡೇಟಾ & { ಉಪಮೊತ್ತ: ಸಂಖ್ಯೆ; ತೆರಿಗೆ: ಸಂಖ್ಯೆ; ಒಟ್ಟು: ಸಂಖ್ಯೆ};
ರಫ್ತು ಕಾರ್ಯ RHFMultiStepForm() {const [ಹಂತ, ಸೆಟ್ಸ್ಟೆಪ್] = useState(0);
const mutation = ಬಳಕೆ ರೂಪಾಂತರ({ mutationFn: async (ಪೇಲೋಡ್: OrderPayload) => { const res = ಪಡೆದುಕೊಳ್ಳಲು ನಿರೀಕ್ಷಿಸಿ("/api/orders", { ವಿಧಾನ: "ಪೋಸ್ಟ್", ಹೆಡರ್ಗಳು: { "ಕಂಟೆಂಟ್-ಟೈಪ್": "ಅಪ್ಲಿಕೇಶನ್/ಜೆಸನ್" }, ದೇಹ: JSON.stringify(ಪೇಲೋಡ್), }); ಒಂದು ವೇಳೆ (!res.ok) ಹೊಸ ದೋಷ ("ಸಲ್ಲಿಸಲು ವಿಫಲವಾಗಿದೆ"); ರಿಟರ್ನ್ res.json(); }, });
const {ರಿಜಿಸ್ಟರ್, ಕಂಟ್ರೋಲ್, ಹ್ಯಾಂಡಲ್ ಸಲ್ಲಿಸಿ, ಫಾರ್ಮ್ ಸ್ಟೇಟ್: {ದೋಷಗಳು }, } = useForm
ಹಿಂತಿರುಗಿ (
);}ಪೆನ್ ಸರ್ವೆಜೆಎಸ್-03-ಆರ್ಎಚ್ಎಫ್ [ಫೋರ್ಕ್ಡ್] ಬೈ ಸಿಕ್ಸ್ತ್ಟಿಂಕ್ಷನ್ ಅನ್ನು ನೋಡಿ. ಇಲ್ಲಿ ಬಹಳಷ್ಟು ನಡೆಯುತ್ತಿದೆ, ಮತ್ತು ವಿಷಯಗಳು ಎಲ್ಲಿ ಕೊನೆಗೊಂಡವು ಎಂಬುದನ್ನು ಗಮನಿಸಲು ನಿಧಾನಗೊಳಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಪಡೆದ ಮೌಲ್ಯಗಳು - ಉಪಮೊತ್ತ, ತೆರಿಗೆ, ಒಟ್ಟು - ಯೂಸ್ವಾಚ್ ಮತ್ತು ಯೂಸ್ಮೆಮೊ ಮೂಲಕ ಘಟಕದಲ್ಲಿ ಗಣಿಸಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಅವು ಲೈವ್ ಫೀಲ್ಡ್ ಮೌಲ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಮತ್ತು ಅವುಗಳಿಗೆ ಬೇರೆ ಯಾವುದೇ ನೈಸರ್ಗಿಕ ಸ್ಥಳವಿಲ್ಲ. ಬಳಕೆದಾರಹೆಸರು, ಪಾಸ್ವರ್ಡ್, ಧನಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆ, ಮತ್ತು ಸುಧಾರಣೆಗಾಗಿ ಗೋಚರತೆಯ ನಿಯಮಗಳು JSX ನಲ್ಲಿ ಇನ್ಲೈನ್ ಷರತ್ತುಬದ್ಧವಾಗಿ ಲೈವ್. ಸ್ಟೆಪ್-ಸ್ಕಿಪ್ಪಿಂಗ್ ಲಾಜಿಕ್ — ವಿಮರ್ಶೆ ಪುಟವು ಒಟ್ಟು >= 100 ಇದ್ದಾಗ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ — ಶೋಸಬ್ಮಿಟ್ ವೇರಿಯೇಬಲ್ನಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಹಂತ 3 ರಲ್ಲಿ ರೆಂಡರ್ ಷರತ್ತು. ನ್ಯಾವಿಗೇಶನ್ ಸ್ವತಃ ನಾವು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತಿರುವ ಯೂಸ್ ಸ್ಟೇಟ್ ಕೌಂಟರ್ ಆಗಿದೆ. ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರಶ್ನೆಯು ಮರುಪ್ರಯತ್ನಗಳು, ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆ ಮತ್ತು ಅಮಾನ್ಯೀಕರಣವನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ. ಫಾರ್ಮ್ ಕೇವಲ ಮೌಲ್ಯೀಕರಿಸಿದ ಡೇಟಾದೊಂದಿಗೆ mutation.mutate ಎಂದು ಕರೆಯುತ್ತದೆ.
ಇದರಲ್ಲಿ ಯಾವುದೂ ತಪ್ಪಲ್ಲ, ಶೇ. ಇದು ಇನ್ನೂ ಭಾಷಾವೈಶಿಷ್ಟ್ಯದ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿದೆ ಮತ್ತು RHF ಅನ್ನು ಹೇಗೆ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಘಟಕವು ಸಾಕಷ್ಟು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿದೆ. ಆದರೆ ನೀವು ಇದನ್ನು ಬರೆಯದ ಯಾರಿಗಾದರೂ ಹಸ್ತಾಂತರಿಸಿದರೆ ಮತ್ತು ವಿಮರ್ಶೆ ಪುಟವು ಯಾವ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಅವರನ್ನು ಕೇಳಿದರೆ, ಅವರು ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಹೇಳಬಹುದಾದ ನಿಯಮವನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲು showSubmit, ಹಂತ 3 ರೆಂಡರ್ ಸ್ಥಿತಿ ಮತ್ತು ನ್ಯಾವ್ ಬಟನ್ ಲಾಜಿಕ್ - ಮೂರು ಪ್ರತ್ಯೇಕ ಸ್ಥಳಗಳ ಮೂಲಕ ಪತ್ತೆಹಚ್ಚಬೇಕು. ಫಾರ್ಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಹೌದು, ಆದರೆ ನಡವಳಿಕೆಯು ನಿಜವಾಗಿಯೂ ಸಿಸ್ಟಮ್ ಆಗಿ ಪರಿಶೀಲಿಸಲಾಗುವುದಿಲ್ಲ. ಅದನ್ನು ಮಾನಸಿಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು. ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿ, ಅದನ್ನು ಬದಲಾಯಿಸಲು ಎಂಜಿನಿಯರಿಂಗ್ ಒಳಗೊಳ್ಳುವಿಕೆಯ ಅಗತ್ಯವಿದೆ. ವಿಮರ್ಶೆಯ ಹಂತವು ಕಾಣಿಸಿಕೊಂಡಾಗ ಸರಿಹೊಂದಿಸುವಂತಹ ಸಣ್ಣ ಟ್ವೀಕ್ ಕೂಡ, ಅಂದರೆ ಘಟಕವನ್ನು ಸಂಪಾದಿಸುವುದು, ಮೌಲ್ಯೀಕರಣವನ್ನು ನವೀಕರಿಸುವುದು, ಪುಲ್ ವಿನಂತಿಯನ್ನು ತೆರೆಯುವುದು, ವಿಮರ್ಶೆಗಾಗಿ ಕಾಯುವುದು ಮತ್ತು ಮತ್ತೆ ನಿಯೋಜಿಸುವುದು. ಭಾಗ 2: ಸ್ಕೀಮಾ-ಚಾಲಿತ (ಸರ್ವೆಜೆಎಸ್) ಈಗ ಸ್ಕೀಮಾವನ್ನು ಬಳಸಿಕೊಂಡು ಅದೇ ಹರಿವನ್ನು ನಿರ್ಮಿಸೋಣ. ಅನುಸ್ಥಾಪನೆ npm ಇನ್ಸ್ಟಾಲ್ ಸರ್ವೆ-ಕೋರ್ ಸಮೀಕ್ಷೆ-ರಿಯಾಕ್ಟ್-ಯುಐ @tanstack/react-query
ಸಮೀಕ್ಷೆ-ಕೋರ್ಎಂಐಟಿ-ಪರವಾನಗಿ ಪಡೆದ ಪ್ಲಾಟ್ಫಾರ್ಮ್-ಸ್ವತಂತ್ರ ರನ್ಟೈಮ್ ಎಂಜಿನ್, ಇದು ಸರ್ವೆಜೆಎಸ್ನ ಫಾರ್ಮ್ ರೆಂಡರಿಂಗ್ಗೆ ಶಕ್ತಿ ನೀಡುತ್ತದೆ - ನಾವು ಇಲ್ಲಿ ಕಾಳಜಿ ವಹಿಸುವ ಭಾಗ. ಇದು JSON ಸ್ಕೀಮಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದರಿಂದ ಆಂತರಿಕ ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ರಿಯಾಕ್ಟ್ ಕಾಂಪೊನೆಂಟ್ನಲ್ಲಿ ವಾಸಿಸುವ ಎಲ್ಲವನ್ನೂ ನಿರ್ವಹಿಸುತ್ತದೆ: ಗೋಚರತೆಯ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು, ಪಡೆದ ಮೌಲ್ಯಗಳನ್ನು ಕಂಪ್ಯೂಟಿಂಗ್ ಮಾಡುವುದು, ಪುಟ ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸುವುದು, ಮೌಲ್ಯೀಕರಣವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಮತ್ತು ಯಾವ ಪುಟಗಳನ್ನು ನಿಜವಾಗಿ ತೋರಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು "ಸಂಪೂರ್ಣ" ಎಂದರೆ ಏನೆಂದು ನಿರ್ಧರಿಸುವುದು. ಸಮೀಕ್ಷೆ-ರಿಯಾಕ್ಟ್-ಯುಐ ಯುಐ / ರೆಂಡರಿಂಗ್ ಲೇಯರ್ ಆ ಮಾದರಿಯನ್ನು ರಿಯಾಕ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ಇದು ಮೂಲಭೂತವಾಗಿ ಒಂದು <ಸಮೀಕ್ಷಾ ಮಾದರಿ={ಮಾದರಿ} /> ಘಟಕವಾಗಿದ್ದು ಅದು ಎಂಜಿನ್ನ ಸ್ಥಿತಿಯು ಬದಲಾದಾಗಲೆಲ್ಲಾ ಮರು ಸಲ್ಲಿಸುತ್ತದೆ. SurveyJS UI ಲೈಬ್ರರಿಗಳು ಕೋನೀಯ, Vue3 ಮತ್ತು ಇತರ ಹಲವು ಚೌಕಟ್ಟುಗಳಿಗೆ ಲಭ್ಯವಿದೆ.
ಒಟ್ಟಾಗಿ, ಅವರು ನಿಮಗೆ ಸಂಪೂರ್ಣ ಕ್ರಿಯಾತ್ಮಕ, ಬಹು-ಪುಟ ಫಾರ್ಮ್ ರನ್ಟೈಮ್ ಅನ್ನು ಒಂದೇ ಸಾಲಿನ ನಿಯಂತ್ರಣ ಹರಿವನ್ನು ಬರೆಯದೆ ನೀಡುತ್ತಾರೆ. ಸ್ಕೀಮಾ ಸ್ವರೂಪವು ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಕೇವಲ JSON ಆಗಿದೆ - ಯಾವುದೇ DSL ಅಥವಾ ಸ್ವಾಮ್ಯದ ಯಾವುದೂ ಇಲ್ಲ. ನೀವು ಅದನ್ನು ಇನ್ಲೈನ್ ಮಾಡಬಹುದು, ಫೈಲ್ನಿಂದ ಆಮದು ಮಾಡಿಕೊಳ್ಳಬಹುದು, ಅದನ್ನು API ನಿಂದ ಪಡೆದುಕೊಳ್ಳಬಹುದು ಅಥವಾ ಡೇಟಾಬೇಸ್ ಕಾಲಮ್ನಲ್ಲಿ ಅದನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ರನ್ಟೈಮ್ನಲ್ಲಿ ಅದನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡಬಹುದು. ಅದೇ ಫಾರ್ಮ್, ಡೇಟಾದಂತೆ ಅದೇ ಫಾರ್ಮ್ ಇಲ್ಲಿದೆ, ಈ ಬಾರಿ JSON ವಸ್ತುವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗಿದೆ. ಸ್ಕೀಮಾ ಎಲ್ಲವನ್ನೂ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ: ರಚನೆ, ಮೌಲ್ಯೀಕರಣ, ಗೋಚರತೆಯ ನಿಯಮಗಳು, ಪಡೆದ ಲೆಕ್ಕಾಚಾರಗಳು, ಪುಟ ಸಂಚರಣೆ - ಮತ್ತು ಅದನ್ನು ರನ್ಟೈಮ್ನಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಮಾದರಿಗೆ ಹಸ್ತಾಂತರಿಸುತ್ತದೆ. ಅದು ಪೂರ್ಣವಾಗಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:
ರಫ್ತು const surveySchema = { ಶೀರ್ಷಿಕೆ: "ಆರ್ಡರ್ ಫ್ಲೋ", ಶೋಪ್ರೊಗ್ರೆಸ್ಬಾರ್: "ಟಾಪ್", ಪುಟಗಳು: [ {ಹೆಸರು: "ವಿವರಗಳು", ಅಂಶಗಳು: [ { ಪ್ರಕಾರ: "ಪಠ್ಯ", ಹೆಸರು: "firstName", isRequired: true }, {ಟೈಪ್: "ಪಠ್ಯ", ಹೆಸರು: "ಇಮೇಲ್", ಇನ್ಪುಟ್ ಟೈಪ್: "ಇಮೇಲ್ ಪ್ರಕಾರ: "ಇಮೇಲ್", ಪಠ್ಯ: "ಅಮಾನ್ಯ ಇಮೇಲ್" }] } ] }, {ಹೆಸರು: "ಆರ್ಡರ್", ಅಂಶಗಳು: [ { ಪ್ರಕಾರ: "ಪಠ್ಯ", ಹೆಸರು: "ಬೆಲೆ", ಇನ್ಪುಟ್ಟೈಪ್: "ಸಂಖ್ಯೆ", ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯ: 0 }, { ಪ್ರಕಾರ: "ಪಠ್ಯ", ಹೆಸರು: "ಪ್ರಮಾಣ", ಇನ್ಪುಟ್ಟೈಪ್, ಡೀಫಾಲ್ಟ್ವಿ: "ಸಂಖ್ಯೆ: 1 "ಡ್ರಾಪ್ಡೌನ್",ಹೆಸರು: "taxRate", defaultValue: 0.1, ಆಯ್ಕೆಗಳು: [ {ಮೌಲ್ಯ: 0.05, ಪಠ್ಯ: "5%" }, {ಮೌಲ್ಯ: 0.1, ಪಠ್ಯ: "10%" }, {ಮೌಲ್ಯ: 0.15, ಪಠ್ಯ: "15%" } ] }, {ಟೈಪ್: "ಅಭಿವ್ಯಕ್ತಿ", ಹೆಸರು }ಪ್ರಸ್ತಾರಕ್ಕೆ: }, { ಪ್ರಕಾರ: "ಅಭಿವ್ಯಕ್ತಿ", ಹೆಸರು: "ತೆರಿಗೆ", ಅಭಿವ್ಯಕ್ತಿ: "{subtotal} {taxRate}" }, { ಪ್ರಕಾರ: "ಅಭಿವ್ಯಕ್ತಿ", ಹೆಸರು: "ಒಟ್ಟು", ಅಭಿವ್ಯಕ್ತಿ: "{subtotal} + {tax}" } ] }, { ಹೆಸರು: "ಖಾತೆ", ಅಂಶಗಳು: [ { ಪ್ರಕಾರ, "countygroups" Ac: "ಆಯ್ಕೆ" "ಇಲ್ಲ"] }, {ಟೈಪ್: "ಪಠ್ಯ", ಹೆಸರು: "ಬಳಕೆದಾರಹೆಸರು", ಗೋಚರವಾದರೆ: "{hasAccount} = 'ಹೌದು'", ಅಗತ್ಯವಿದೆ: ಸರಿ }, {ಟೈಪ್: "ಪಠ್ಯ", ಹೆಸರು: "ಪಾಸ್ವರ್ಡ್", ಇನ್ಪುಟ್ಟೈಪ್: "ಪಾಸ್ವರ್ಡ್", ಗೋಚರವಾದರೆ: "{hasAccount}} = 'ಅಗತ್ಯವಿದೆ: ಕನಿಷ್ಠ ಉದ್ದ: 6, ಪಠ್ಯ: "ಕನಿಷ್ಟ 6 ಅಕ್ಷರಗಳು" }] }, { ಪ್ರಕಾರ: "ರೇಟಿಂಗ್", ಹೆಸರು: "ತೃಪ್ತಿ", ದರಮಿನ್: 1, ದರಮ್ಯಾಕ್ಸ್: 5 }, {ಟೈಪ್: "ಕಾಮೆಂಟ್", ಹೆಸರು: "ಧನಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆ", ಗೋಚರಿಸಿದರೆ: "{ತೃಪ್ತಿ}, >= 4 ಪ್ರಕಾರದ ಹೆಸರು: " "ಸುಧಾರಣೆ ಪ್ರತಿಕ್ರಿಯೆ", ಗೋಚರವಾದರೆ: "{ತೃಪ್ತಿ} <= 2" } ] }, {ಹೆಸರು: "ವಿಮರ್ಶೆ", ಗೋಚರಿಸಿದರೆ: "{ಒಟ್ಟು} >= 100", ಅಂಶಗಳು: [] } ]};
ಇದನ್ನು ಒಂದು ಕ್ಷಣ RHF ಆವೃತ್ತಿಗೆ ಹೋಲಿಸಿ.
ಷರತ್ತುಬದ್ಧ ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಅಗತ್ಯವಿರುವ ಸೂಪರ್ರಿಫೈನ್ ಬ್ಲಾಕ್ ಕಳೆದುಹೋಗಿದೆ. ಗೋಚರವಾದ ವೇಳೆ: "{hasAccount} = 'ಹೌದು'" ಜೊತೆಗೆ ಅಗತ್ಯವಿದೆ: ನಿಜವು ಎರಡೂ ಕಾಳಜಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ನಿಭಾಯಿಸುತ್ತದೆ, ಕ್ಷೇತ್ರದಲ್ಲಿ ಸ್ವತಃ, ನೀವು ಅವುಗಳನ್ನು ಹುಡುಕಲು ನಿರೀಕ್ಷಿಸಬಹುದು. ಉಪಮೊತ್ತ, ತೆರಿಗೆ ಮತ್ತು ಮೊತ್ತವನ್ನು ಕಂಪ್ಯೂಟ್ ಮಾಡಿದ useWatch + useMemo ಚೈನ್ ಅನ್ನು ಮೂರು ಅಭಿವ್ಯಕ್ತಿ ಕ್ಷೇತ್ರಗಳಿಂದ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ, ಅದು ಪರಸ್ಪರ ಹೆಸರಿನಿಂದ ಉಲ್ಲೇಖಿಸಲ್ಪಡುತ್ತದೆ. ವಿಮರ್ಶಾ ಪುಟದ ಸ್ಥಿತಿ, RHF ಆವೃತ್ತಿಯಲ್ಲಿ ಶೋಸಬ್ಮಿಟ್, ಹಂತ 3 ರೆಂಡರ್ ಶಾಖೆಯ ಮೂಲಕ ಮಾತ್ರ ಮರುನಿರ್ಮಾಣ ಮಾಡಬಹುದಾಗಿದೆ. ಮತ್ತು ಅಂತಿಮವಾಗಿ, ನ್ಯಾವ್ ಬಟನ್ ತರ್ಕವು ಪುಟದ ಆಬ್ಜೆಕ್ಟ್ನಲ್ಲಿ ಆಸ್ತಿಯಾಗಿದ್ದರೆ ಒಂದೇ ಗೋಚರಿಸುತ್ತದೆ.
ಅಲ್ಲಿಯೂ ಅದೇ ತರ್ಕ. ಸ್ಕೀಮಾವು ಘಟಕದಾದ್ಯಂತ ಹರಡುವ ಬದಲು ಪ್ರತ್ಯೇಕವಾಗಿ ಗೋಚರಿಸುವ ಸ್ಥಳದಲ್ಲಿ ವಾಸಿಸಲು ಸ್ಥಳವನ್ನು ನೀಡುತ್ತದೆ. ಅಲ್ಲದೆ, ಸ್ಕೀಮಾ ಪ್ರಕಾರವನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ಉಪಮೊತ್ತ, ತೆರಿಗೆ ಮತ್ತು ಒಟ್ಟುಗಾಗಿ 'ಅಭಿವ್ಯಕ್ತಿ'. ಅಭಿವ್ಯಕ್ತಿ ಓದಲು-ಮಾತ್ರ ಮತ್ತು ಲೆಕ್ಕಹಾಕಿದ ಮೌಲ್ಯಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ಮುಖ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. SurveyJS ಸಹ ಪ್ರಕಾರವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ: ಸ್ಥಿರ ವಿಷಯಕ್ಕಾಗಿ 'html', ಆದರೆ ಲೆಕ್ಕಾಚಾರದ ಮೌಲ್ಯಗಳಿಗೆ, ಅಭಿವ್ಯಕ್ತಿ ಸರಿಯಾದ ಆಯ್ಕೆಯಾಗಿದೆ. ಈಗ ರಿಯಾಕ್ಟ್ ಬದಿಗೆ. ರೆಂಡರಿಂಗ್ ಮತ್ತು ಸಲ್ಲಿಕೆ ತುಂಬಾ ಸರಳ. ನಿಮ್ಮ API ಗೆ ವೈರ್ ಆನ್ ಕಂಪ್ಲೀಟ್ ಅದೇ ರೀತಿಯಲ್ಲಿ - ಬಳಕೆ ರೂಪಾಂತರ ಅಥವಾ ಸರಳ ಪಡೆಯುವಿಕೆಯ ಮೂಲಕ:
"react" ನಿಂದ {useState, useEffect, useRef} ಆಮದು ಮಾಡಿ; "@tanstack/react-query" ನಿಂದ {useMutation} ಆಮದು ಮಾಡಿ; "survey-core" ನಿಂದ {ಮಾದರಿ } ಆಮದು ಮಾಡಿ; "survey-react-ui" ನಿಂದ {ಸಮೀಕ್ಷೆ} ಆಮದು ಮಾಡಿ; "survey-core.
ರಫ್ತು ಕಾರ್ಯ SurveyForm() {const [model] = useState(() => ಹೊಸ ಮಾದರಿ(surveySchema));
const mutation = ಬಳಕೆ ರೂಪಾಂತರ({ mutationFn: async (ಡೇಟಾ) => { const res = ಪಡೆದುಕೊಳ್ಳಲು ನಿರೀಕ್ಷಿಸಿ("/api/orders", { ವಿಧಾನ: "ಪೋಸ್ಟ್", ಹೆಡರ್ಗಳು: { "ಕಂಟೆಂಟ್-ಟೈಪ್": "ಅಪ್ಲಿಕೇಶನ್/ಜೆಸನ್" }, ದೇಹ: JSON.stringify(data), }); ಒಂದು ವೇಳೆ (!res.ok) ಹೊಸ ದೋಷ ("ಸಲ್ಲಿಸಲು ವಿಫಲವಾಗಿದೆ"); ರಿಟರ್ನ್ res.json(); }, });
const mutationRef = useRef(ಮ್ಯುಟೇಶನ್); mutationRef.current = ರೂಪಾಂತರ; useEffect(() => {const handler = (ಕಳುಹಿಸುವವರು) => mutationRef.current.mutate(sender.data); model.onComplete.add(ಹ್ಯಾಂಡ್ಲರ್); ಹಿಂತಿರುಗಿ () => model.onComplete.remove(ಹ್ಯಾಂಡ್ಲರ್);}, [ಮಾದರಿ]); // ರೆಫ್ ಪ್ರತಿ ರೆಂಡರ್ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು ಮರು-ನೋಂದಣಿ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ (ಮ್ಯುಟೇಶನ್ ಆಬ್ಜೆಕ್ಟ್ ಐಡೆಂಟಿಟಿ ಬದಲಾವಣೆಗಳು)
ಹಿಂತಿರುಗಿ ( <> <ಸಮೀಕ್ಷೆ ಮಾದರಿ={model} /> {mutation.isError &&
ಪೆನ್ ಸರ್ವೆಜೆಎಸ್-03-ಸರ್ವೆಜೆಎಸ್ [ಫೋರ್ಕ್ಡ್] ಆರನೇ ಅಳಿವಿನ ಮೂಲಕ ನೋಡಿ.
ಬಳಕೆದಾರರು ಕೊನೆಯ ಗೋಚರ ಪುಟದ ಅಂತ್ಯವನ್ನು ತಲುಪಿದಾಗ onComplete ಫೈರ್ ಆಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಒಟ್ಟು ಎಂದಿಗೂ 100 ದಾಟದಿದ್ದರೆ ಮತ್ತು ವಿಮರ್ಶೆ ಪುಟವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ, ಅದು ಇನ್ನೂ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಏಕೆಂದರೆ SurveyJS "ಕೊನೆಯ ಪುಟ" ಎಂದರೆ ಏನೆಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ಗೋಚರತೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ನಂತರ, sender.data ಎಲ್ಲಾ ಉತ್ತರಗಳನ್ನು ಲೆಕ್ಕಹಾಕಿದ ಮೌಲ್ಯಗಳೊಂದಿಗೆ (ಉಪಮೊತ್ತ, ತೆರಿಗೆ, ಒಟ್ಟು) ಮೊದಲ-ವರ್ಗ ಕ್ಷೇತ್ರಗಳಾಗಿ ಒಳಗೊಂಡಿರುತ್ತದೆ, ಆದ್ದರಿಂದ API ಪೇಲೋಡ್ ಆನ್ಸಬ್ಮಿಟ್ನಲ್ಲಿ ಕೈಯಾರೆ ಜೋಡಿಸಲಾದ RHF ಆವೃತ್ತಿಗೆ ಹೋಲುತ್ತದೆ. ದಿmutationRef ಮಾದರಿಯು ಪ್ರತಿ ರೆಂಡರ್ನಲ್ಲಿ ಬದಲಾಗುವ ಮೌಲ್ಯದ ಮೇಲೆ ನಿಮಗೆ ಸ್ಥಿರವಾದ ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಿಂದಲಾದರೂ ನೀವು ತಲುಪುವ ಒಂದೇ ಮಾದರಿಯಾಗಿದೆ - ಅದರ ಬಗ್ಗೆ ಸಮೀಕ್ಷೆಜೆಎಸ್-ನಿರ್ದಿಷ್ಟ ಏನೂ ಇಲ್ಲ.
ರಿಯಾಕ್ಟ್ ಘಟಕವು ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಯಾವುದೇ ಯೂಸ್ವಾಚ್ ಇಲ್ಲ, ಷರತ್ತುಬದ್ಧ ಜೆಎಸ್ಎಕ್ಸ್ ಇಲ್ಲ, ಸ್ಟೆಪ್ ಕೌಂಟರ್ ಇಲ್ಲ, ಯೂಸ್ಮೆಮೊ ಚೈನ್ ಇಲ್ಲ, ಸೂಪರ್ರಿಫೈನ್ ಇಲ್ಲ. ರಿಯಾಕ್ಟ್ ಇದು ನಿಜವಾಗಿ ಉತ್ತಮವಾದುದನ್ನು ಮಾಡುತ್ತಿದೆ: ಘಟಕವನ್ನು ರೆಂಡರಿಂಗ್ ಮಾಡುವುದು ಮತ್ತು ಅದನ್ನು API ಕರೆಗೆ ವೈರಿಂಗ್ ಮಾಡುವುದು. ಏನು ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಹೊರಬಿತ್ತು?
ಕಾಳಜಿ RHF ಸ್ಟಾಕ್ ಸರ್ವೆಜೆಎಸ್ ಗೋಚರತೆ JSX ಶಾಖೆಗಳು ಗೋಚರಿಸಿದರೆ ಪಡೆದ ಮೌಲ್ಯಗಳು ವಾಚ್ / ಯೂಸ್ಮೆಮೊ ಬಳಸಿ ಅಭಿವ್ಯಕ್ತಿ ಅಡ್ಡ-ಕ್ಷೇತ್ರದ ನಿಯಮಗಳು ಸೂಪರ್ ರಿಫೈನ್ ಸ್ಕೀಮಾ ಪರಿಸ್ಥಿತಿಗಳು ನ್ಯಾವಿಗೇಷನ್ ಹಂತದ ಸ್ಥಿತಿ ಪುಟ ಗೋಚರಿಸಿದರೆ ನಿಯಮದ ಸ್ಥಳ ಫೈಲ್ಗಳಾದ್ಯಂತ ವಿತರಿಸಲಾಗಿದೆ ಸ್ಕೀಮಾದಲ್ಲಿ ಕೇಂದ್ರೀಕೃತವಾಗಿದೆ
ರಿಯಾಕ್ಟ್ನಲ್ಲಿ ಉಳಿಯುವುದು ಲೇಔಟ್, ಸ್ಟೈಲಿಂಗ್, ಸಲ್ಲಿಕೆ ವೈರಿಂಗ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಏಕೀಕರಣ, ಅಂದರೆ ರಿಯಾಕ್ಟ್ ಅನ್ನು ವಾಸ್ತವವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಉಳಿದಂತೆ ಎಲ್ಲವೂ ಸ್ಕೀಮಾಗೆ ಸರಿಸಲಾಗಿದೆ, ಮತ್ತು ಸ್ಕೀಮಾ ಕೇವಲ JSON ಆಬ್ಜೆಕ್ಟ್ ಆಗಿರುವುದರಿಂದ, ಅದನ್ನು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಆವೃತ್ತಿ ಮಾಡಬಹುದು ಅಥವಾ ನಿಯೋಜನೆಯ ಅಗತ್ಯವಿಲ್ಲದೇ ಆಂತರಿಕ ಉಪಕರಣದ ಮೂಲಕ ಸಂಪಾದಿಸಬಹುದು. ವಿಮರ್ಶೆ ಪುಟವನ್ನು ಪ್ರಚೋದಿಸುವ ಮಿತಿಯನ್ನು ಬದಲಾಯಿಸಬೇಕಾದ ಉತ್ಪನ್ನ ನಿರ್ವಾಹಕರು ಘಟಕವನ್ನು ಸ್ಪರ್ಶಿಸದೆಯೇ ಅದನ್ನು ಮಾಡಬಹುದು. ಫಾರ್ಮ್ ನಡವಳಿಕೆಯು ಆಗಾಗ್ಗೆ ವಿಕಸನಗೊಳ್ಳುವ ಮತ್ತು ಯಾವಾಗಲೂ ಎಂಜಿನಿಯರ್ಗಳಿಂದ ನಡೆಸಲ್ಪಡದ ತಂಡಗಳಿಗೆ ಇದು ಅರ್ಥಪೂರ್ಣ ಕಾರ್ಯಾಚರಣೆಯ ವ್ಯತ್ಯಾಸವಾಗಿದೆ. ಪ್ರತಿ ವಿಧಾನವನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು? ನನಗೆ ಕೆಲಸ ಮಾಡುವ ಹೆಬ್ಬೆರಳಿನ ಉತ್ತಮ ನಿಯಮ ಇಲ್ಲಿದೆ: ಫಾರ್ಮ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಳಿಸುವುದನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನೀವು ಏನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ?
ಇದು ಪರದೆಯಾಗಿದ್ದರೆ, ನೀವು ಘಟಕ-ಚಾಲಿತ ರೂಪಗಳನ್ನು ಬಯಸುತ್ತೀರಿ. ಥ್ರೆಶೋಲ್ಡ್ಗಳು, ಶಾಖೆಯ ನಿಯಮಗಳು ಮತ್ತು ನೈಜ ನಿರ್ಧಾರಗಳನ್ನು ಎನ್ಕೋಡ್ ಮಾಡುವ ಷರತ್ತುಬದ್ಧ ಅವಶ್ಯಕತೆಗಳಂತಹ ವ್ಯವಹಾರ ತರ್ಕವಾಗಿದ್ದರೆ, ನಿಮಗೆ ಸ್ಕೀಮಾ ಎಂಜಿನ್ ಬೇಕು.
ಅದೇ ರೀತಿ, ನಿಮ್ಮ ಮಾರ್ಗದಲ್ಲಿ ಬರುವ ಬದಲಾವಣೆಗಳು ಹೆಚ್ಚಾಗಿ ಲೇಬಲ್ಗಳು, ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ಲೇಔಟ್ಗೆ ಸಂಬಂಧಿಸಿದ್ದರೆ, RHF ನಿಮಗೆ ಉತ್ತಮ ಸೇವೆಯನ್ನು ನೀಡುತ್ತದೆ. ಅವರು ಷರತ್ತುಗಳು, ಫಲಿತಾಂಶಗಳು ಮತ್ತು ನಿಯಮಗಳ ಬಗ್ಗೆ ಇದ್ದರೆ, ನಿಮ್ಮ ಆಪ್ಗಳು ಅಥವಾ ಕಾನೂನು ತಂಡವು ಮಂಗಳವಾರ ಮಧ್ಯಾಹ್ನ ಟಿಕೆಟ್ ಅನ್ನು ಸಲ್ಲಿಸದೆಯೇ ಸರಿಹೊಂದಿಸಬೇಕಾಗಬಹುದು, SurveyJS ನೊಂದಿಗೆ ಸ್ಕೀಮಾ ಮಾದರಿಯು ಹೆಚ್ಚು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ. ಈ ಎರಡು ವಿಧಾನಗಳು ನಿಜವಾಗಿಯೂ ಪರಸ್ಪರ ಸ್ಪರ್ಧೆಯಲ್ಲಿಲ್ಲ. ಅವರು ವಿವಿಧ ವರ್ಗದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ, ಮತ್ತು ತಪ್ಪಿಸಬೇಕಾದ ತಪ್ಪು ಎಂದರೆ ತರ್ಕದ ತೂಕಕ್ಕೆ ಅಮೂರ್ತತೆಯನ್ನು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ - ನಿಯಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಒಂದು ಘಟಕದಂತೆ ಪರಿಗಣಿಸುವುದು ಏಕೆಂದರೆ ಅದು ಪರಿಚಿತ ಸಾಧನವಾಗಿದೆ ಅಥವಾ ನೀತಿ ಎಂಜಿನ್ಗೆ ತಲುಪುತ್ತದೆ ಏಕೆಂದರೆ ಒಂದು ರೂಪವು ಮೂರು ಹಂತಗಳಿಗೆ ಬೆಳೆದು ಷರತ್ತುಬದ್ಧ ಕ್ಷೇತ್ರವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ. ನಾವು ಇಲ್ಲಿ ನಿರ್ಮಿಸಿದ ರೂಪವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಗಡಿಯ ಸಮೀಪದಲ್ಲಿದೆ, ವ್ಯತ್ಯಾಸವನ್ನು ಬಹಿರಂಗಪಡಿಸುವಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ ಆದರೆ ಹೋಲಿಕೆಯು ಸಜ್ಜುಗೊಂಡಂತೆ ಭಾಸವಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ ಅಸಮರ್ಥವಾಗಿರುವ ಹೆಚ್ಚಿನ ನೈಜ ರೂಪಗಳು ಬಹುಶಃ ಅದೇ ಗಡಿಯ ಸಮೀಪದಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಶ್ನೆಯು ಯಾರಿಗಾದರೂ ಅವರು ನಿಜವಾಗಿ ಏನೆಂದು ಹೆಸರಿಸಿದ್ದಾರೆಯೇ ಎಂಬುದು. ಯಾವಾಗ ರಿಯಾಕ್ಟ್ ಹುಕ್ ಫಾರ್ಮ್ + Zod ಅನ್ನು ಬಳಸಿ:
ಫಾರ್ಮ್ಗಳು CRUD-ಆಧಾರಿತವಾಗಿವೆ; ತರ್ಕವು ಆಳವಿಲ್ಲದ ಮತ್ತು UI-ಚಾಲಿತವಾಗಿದೆ; ಇಂಜಿನಿಯರ್ಗಳು ಎಲ್ಲಾ ನಡವಳಿಕೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ; ಬ್ಯಾಕೆಂಡ್ ಸತ್ಯದ ಮೂಲವಾಗಿ ಉಳಿದಿದೆ.
ಯಾವಾಗ SurveyJS ಅನ್ನು ಬಳಸಿ:
ಫಾರ್ಮ್ಗಳು ವ್ಯವಹಾರ ನಿರ್ಧಾರಗಳನ್ನು ಎನ್ಕೋಡ್ ಮಾಡುತ್ತವೆ; ನಿಯಮಗಳು UI ಯಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತವೆ; ತರ್ಕವು ಗೋಚರವಾಗಿರಬೇಕು, ಆಡಿಟ್ ಆಗಿರಬೇಕು ಅಥವಾ ಆವೃತ್ತಿಯಾಗಿರಬೇಕು; ಇಂಜಿನಿಯರ್-ಅಲ್ಲದವರು ವರ್ತನೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುತ್ತಾರೆ; ಒಂದೇ ಫಾರ್ಮ್ ಅನೇಕ ಮುಂಭಾಗಗಳಲ್ಲಿ ಚಲಿಸಬೇಕು.
