3 ms·
In validation, it's never about speed. Is how you relate the schema tree to the error reporting tree. If you didn't already, you will figure that out eventually
by alganet 2y ago
In validation, it's never about speed. Is how you relate the schema tree to the error reporting tree. If you didn't already, you will figure that out eventually.
If you mess that (either by being too flat, too customizeable or too limited), library users will start coming up with their own wrappers around it, which will make your stuff slower and your role as a maintainer hell.
(source: 15 years intermittently maintaining a similar project).
There is an obvious need for a validation library nowadays that bridges oop, functional and natural languages. Its value, if adopted as a standard, would be immense. The floor is still lava though, can't make it work in today's software culture.
- e1g 2y agoEspecially when unions are involved. We have a flexible schema for many parameters (e.g., X accepts an object or an array of them, and one object has some properties that could be an enum or a detailed shape), and both Zod and Valibot produce incomprehensible and useless error messages that don’t explain what’s wrong. We had to roll our own.
- alganet 2y agoHave you tried applying boolean algebra conversions on the schema? Some ORs can be written as NOT AND expressions. I don't know about these JS versions, but in my lib the choice of boolean expression had influence on th3 error output.
- retropragma 2y agoI find your last paragraph to be lacking. Would help if you elaborated more on the purported need for this "bridge" concept.
- alganet 2y agoMaybe one day I will elaborate on it! The need is obvious. As natural language becomes more proeminent in programming, there will be a need for a bridge to the older traditional paradigms. I can't give more details, it's the kind of thing you can't put in prose yet.