Die "glänzende" Zukunft meines Scheiterns

Ich schreibe jetzt seit anderthalb Jahren meine Datenvalidierungsbibliothek für Quartette . Und es war nicht ohne Fehler. Der Wunsch, sie zu beheben, veranlasste mich, Hauptversionen erneut zu veröffentlichen und die Architektur zu ändern. Und jetzt, seit vier Monaten, hat sich die letzte Hauptversion nicht geändert. Aber es hat auch seine eigenen Fehler, und jetzt werde ich versuchen, Ihnen davon zu erzählen.

Die einzige Quelle der Wahrheit und des DRY-Prinzips

Betrachten wir ein Beispiel:

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,
})

In diesem Beispiel checkPersoneine Funktion, ein benutzerdefinierter TypeGuard vom Typ Person.

Wir können nicht anders, als die Wiederholungen zu bemerken. Die Beschreibung der Validierung wiederholt die Beschreibung des Typs fast vollständig, aber die Bibliothek garantiert in keiner Weise, dass das darin beschriebene Schema wirklich dem Personentyp entspricht.

Dies ist kein unlösbares Problem. Es gibt Bibliotheken mit dieser Eigenschaft, z. B. io-ts

In diesem Problem sehe ich eine Wahl zwischen Garantien und der Bequemlichkeit des Schreibens und Lesens des Validierungsschemas. Letzteres ist meiner Meinung nach vorzuziehen. Aber das hängt von Ihrem Geschmack und den Kosten des Fehlers ab.

Erklären Sie für die Invalidität!

Obwohl es einen Erklärungsmechanismus gibt, kann er sich seiner Fähigkeiten nicht rühmen. Beispiel

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) // []

Nun, das ist eine Art Elend. Was für eine Erklärung ist das?

Mal sehen, ob wir dort ein leeres Objekt übergeben:

checkPerson({})

console.log(checkPerson.explanations)

Die Ausgabe wird sein:

[{ value: undefined, schema: '[Function: number]', id: 'value.id' }]

Das ist besser. Diese Erklärung ist jedoch nicht serialisierbar, da es sich schemaum eine Funktion handelt.

. , .

.

. -? , .

— - . , - , - — .

Es gibt viele Dinge, die ich an meiner Bibliothek mag, über die ich zuvor geschrieben habe: Kürze und Einfachheit , Ähnlichkeit mit Typescript , Leistung .

Aber jetzt fand ich es gut, darüber zu schreiben, was schlecht und nicht gut genug war, um stolz zu sein. Wahrscheinlich gibt es noch einige andere Mängel, ich werde mich über Kritik von Kommentatoren freuen. Und vielleicht werde ich meinen Artikel ergänzen.

Danke fürs Lesen