لقد كنت أكتب مكتبة التحقق من صحة البيانات الرباعية الخاصة بي لمدة عام ونصف الآن. ولم يكن بدون فشل. أجبرتني الرغبة في إصلاحها على إعادة إصدار الإصدارات الرئيسية وتغيير البنية. والآن ، منذ أربعة أشهر ، لم يتغير الإصدار الرئيسي الأخير. لكن لها أيضًا إخفاقاتها الخاصة ، وسأحاول الآن إخبارك عنها.
المصدر الوحيد للحقيقة ومبدأ الجفاف
لنفكر في مثال:
import { v } from 'quartet' // V ... ...Validation
interface Person {
id: number
name: string
age: number
}
const checkPerson = v<Person>({
id: v.number,
name: v.string,
age: v.number,
})
في هذا المثال checkPerson
، دالة ، TypeGuard مخصصة من النوع الشخص.
لا يسعنا إلا أن نلاحظ التكرار. يكرر وصف التحقق من الصحة وصف النوع بشكل كامل تقريبًا ، لكن المكتبة لا تضمن بأي شكل من الأشكال أن المخطط الموصوف بالداخل يتوافق بالفعل مع نوع الشخص.
هذه ليست مشكلة غير قابلة للحل ، فهناك مكتبات لها هذه الخاصية ، على سبيل المثال io-ts
في هذه المشكلة ، أرى خيارًا بين الضمانات وسهولة الكتابة وقراءة مخطط التحقق من الصحة. في رأيي ، هذا الأخير هو الأفضل. لكن هذا يعتمد على ذوقك وتكلفة الخطأ.
اشرح للبطلان!
على الرغم من وجود آلية تفسير ، إلا أنها لا تستطيع التباهي بقدراتها. مثال
import { e as v } from 'quartet' // E ... ...Explanatory
const checkPerson = v<Person>({
id: v.number,
name: v.string,
age: v.number,
})
checkPerson(null) // => false
console.log(checkPerson.explanations) // []
حسنًا ، هذا نوع من القذارة. أي نوع من التفسير هذا ؟؟
دعونا نرى ما إذا كنا نمرر كائنًا فارغًا هناك:
checkPerson({})
console.log(checkPerson.explanations)
سيكون الإخراج:
[{ value: undefined, schema: '[Function: number]', id: 'value.id' }]
هذا أفضل. لكن هذا التفسير غير قابل للتسلسل لأنه schema
دالة.
. , .
.
. -? , .
— - . , - , - — .
هناك العديد من الأشياء التي أحبها في مكتبتي والتي كتبت عنها سابقًا: الإيجاز والبساطة ، والتشابه مع التنضيد ، والأداء .
لكن الآن ، اعتقدت أنه من الجيد أن أكتب عما ساء ولم يكن جيدًا بما يكفي ليفخر به. ربما توجد بعض العيوب الأخرى ، سأكون سعيدًا لسماع انتقادات من المعلقين. وربما سأكمل مقالي.
شكرا للقراءة