يُعتبر TypeScript مُعززًا لأمان كود التطبيق. ومع ذلك، فهو لا يتحقق من صحة المدخلات غير الموثوقة في وقت التشغيل.
قد يبدو ذلك بديهيًا، ولكن لا تزال الفرق تجمع بين هذين الفكرة. يقومون بنمذجة حزمة الطلب كواجهة، ويقومون بتحويل البيانات الواردة، ويشعرون بالدهشة عندما تقبل النظام إدخالات غير صحيحة.
السبب بسيط: الواجهات تختفي في وقت التشغيل.
أين تبدأ المشكلة فعلاً
هذه هي حدود الثقة:
- أجسام الطلب
- معلمات الاستعلام
- متغيرات البيئة
- حزم الويب هوك
- البيانات المخزنة محليًا وبيانات النماذج
- استجابات واجهة برمجة التطبيقات الخارجية
على الجانب الآخر من تلك الحدود، تكون البيانات مجرد unknown. إذا تخطيت التحقق هناك، فلن يُحمي TypeScript أي شيء ذو معنى.
لماذا يعمل Zod بشكل جيد
Zod مفيد لأن المخطط موجود ككود قابل للتنفيذ:
import { z } from "zod";
export const CreateUserSchema = z.object({
email: z.string().email(),
age: z.number().int().positive(),
name: z.string().min(1),
});
يمكنك التحقق من البيانات الواردة مباشرة:
const result = CreateUserSchema.safeParse(req.body);
if (!result.success) {
return res.status(400).json({
error: "حمولة غير صالحة",
details: result.error.flatten(),
});
}
await db.user.create({ data: result.data });
الآن، أصبحت منطق التحقق حقيقيًا، وليس مجرد مفترض.
الجزء الأفضل في مشاريع TypeScript
لا يزال بإمكانك الحصول على أنواع قوية من نفس المخطط:
type CreateUserInput = z.infer<typeof CreateUserSchema>;
لهذا السبب يشعر Zod بأنه طبيعي جدًا في تطبيقات TypeScript الكاملة. لا تحتاج إلى الاختيار بين التحقق من الصحة في وقت التشغيل و راحة الاستخدام في وقت التجميع.
المقايضة
المقايضة هي الوضوح. أنت تكتب المخططات عن قصد، وتحافظ عليها، وتقرر مكان التحقق. هذا عمل. إنه فقط عمل أفضل بكثير من تصحيح الأخطاء الناتجة عن حزم غير صحيحة بعد أن تدخل النظام بعمق.
تأثير SEO والمنتجات
التحقق ليس مجرد قضية خلفية. يؤدي التحقق الأنظف إلى تحسين إدارة الأخطاء، وزيادة استقرار النماذج، وتقليل تدفقات المستخدم المكسورة، وسلوك التطبيقات القابلة للزحف بشكل أفضل عندما تبقى استجابات الخادم ضمن توقع معين. وهذا يساعد كلا من الموثوقية وثقة المستخدم.
قراءة إضافية