Comments (8)
You just need to write code to process this data structure.
Of course I have to write code that processes data-structures, that's basically the job description of a software programmer, however in most cases there is an API and a documentation and most importantly, the data-structure is well thought out and actually helps solving the problem instead of making the programmer's life harder. At least in the case of good data-structures that are well designed.
Not sure what you mean. Errors are just array of objects with the documented structure, so they can be processed as any other data structure - what's there to be proven?
See, the problem is that after I wrote a bunch of schemas that describe the structure of the data I work with and I want to validate, and I run my data through your validator with my schema, and your validator (which is great btw.) gives back the errors, for some unknown and completely mind boggling reason, instead of getting the response back in the structure I have specified as relevant to my software, I get a damned array. AN ARRAY. If my schema would be "just an array of objects", I wouldn't need to validate my schema much, would I? The whole point of using schema is to keep the structure around. Now, with your list of errors, I would love to see the processing code that puts together the list into the original schema structure that was validated, because honestly, I am not sure if it's possible or if it is, it's worth the effort, as I would probably lose any kind of performance benefits I gained in the beginning.
from ajv-errors.
Actually I've just found a workaround for my use case, by using the following schema:
{
'type': 'object',
'properties': {
'someRequiredProperty': {
'type': 'string',
'format': 'email',
'errorMessage': 'Must be a valid email (or any kind of validation)'
}
},
'required': ['someRequiredProperty'],
'errorMessage': {
'properties': {
'someRequiredProperty': 'This is required'
}
}
}
My use case still requires errorDataPath
to be set to property
, though. I am working on client-side form validation and I need the missing property names, so that I can display errors next to their corresponding inputs. From what I understand in #255, using errorDataPath: 'property'
the only way to get the property names. Maybe there's a better way?
Thanks!
from ajv-errors.
"You can process errors" - this is left to be demonstrated, until then it's only theory.
from ajv-errors.
Is this an intended consequence of setting errorDataPath to property?
@nathanchrs yes, I was actually going to deprecate this option in Ajv, it was added for backward compatibility only long time ago. It won't be supported here, probably worth adding some warning if it's set.
from ajv-errors.
I am working on client-side form validation and I need the missing property names, so that I can display errors next to their corresponding inputs
You can process errors and give "required" keyword errors a special treatment to associate them with a form field.
from ajv-errors.
"You can process errors" - this is left to be demonstrated, until then it's only theory.
Not sure what you mean. Errors are just array of objects with the documented structure, so they can be processed as any other data structure - what's there to be proven? You just need to write code to process this data structure.
from ajv-errors.
A related discussion is here: json-schema-org/json-schema-spec#396 (comment)
The problem with achieving what you want is that, by design, the JSON schema is 1) not declaring the structure of the data and 2) can have very different structure from the data.
So returning the array of errors makes the most sense, in general case.
The analogy here is the stack trace of the exception - even though it represents the tree of functions, itβs is logged as a simple list.
In some specific cases, like the one you most likely have, it is possible to return errors in a format that is close to the structure of the data, and such structure can be created from the array of errors. But it is not possible in the general case, because it is not always possible to attribute an error to a specific location in the data.
from ajv-errors.
I've read those comments weeks ago. I realize that JSONSchema doesn't describe a fixed tree structure that could be simply dereferenced into a unit. But this doesn't mean, that there is no relevant structure at the time of validation that could be exported and shared. There is always a path of data pointers and schema pointers that we've followed and that we have to use for validation, and a lot of the time it would be useful to optionally have either of them instead of having fed a premade choice based on assumptions by the library author and not the library user.
Exactly like stack trace, however you are not giving me a stack, you are giving me an error log with meta-data that also have meta-data :). If you were giving me the stack, I would be probably content with that however there is more than this.
I realize that errors as data from the perspective of the writer of the validation library is a good decision, solves a bunch of problems, it's easy and fast. However if it is hard for you to give back structural information while you have ALL THE INFO, imagine how hard it is to parse the errors for someone who has less than that. I am jumping through hoops to somehow find how to pair my DOM Nodes that should show a text with your errors and basically it seems that the best way is to create a huge map of some kind, a 3rd data structure.
That's not a scalable approach for a general solution
What you miss I think is that I do not want you to match my errors to some pre-defined schema, that's not going to work for everyone, I know, because how flexible JSONSchema is, and actually that's one of the main reasons I am using it.
What I miss is that why can't we have more than just one data structure for the errors? Why does it have to be a list of complicated error objects, why not something that's easier to parse and that contains more information?
This isn't about just required and such keywords, but also references and errors from if/then/else and custom keywords too. If I want a general solution for recognizing the source of the errors, I can not build on your software, because I feel that I would have to re-do most of the work you already did just for this tiny little detail of how the errors are reported.
I believe that this is all about lost contextual information. You perhaps feel that you have not hidden anything, but in fact the current path and pointers data that seems sometimes duplicated (btw, duplication is way better than bad abstractions, I hate when people avoid a couple of bytes of additional data because of some false sense of aesthetics https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction , because you also seem to believe that having the same bits in more than one place is somehow wrong ajv-validator/ajv#255 (comment))
For example, I would be happy with a solution where instead of having to read a list of arcane objects, I could give one or more (but not too many) callbacks to be called on error detection, I would get all the contextual information and I could build my own error data structure that would fit my needs not yours. I could do all kinds of processing around the error without anyone else being affected.
from ajv-errors.
Related Issues (20)
- Reference Error with relative JSON pointer HOT 1
- Custom error for minLength on array property is not working HOT 1
- Be able to set custom keyword for error messages HOT 1
- Receiving error that a dependency is missing after installing ajv-errors.
- Create different error for each validation per attribute HOT 3
- `JSONSchemaType` + `anyOf` corresponding to union over objects cannot correctly determine missing fields HOT 2
- Getting instancePath when using with ajv-keywords and uniqueItemProperties HOT 1
- errorMessage not being set on array of objects? HOT 1
- Keyword error replacement in nested objects it's not working
- Required Keyword Error Message - Error is raised at incorrect level HOT 3
- Question: use enum values in custom error message
- Not getting custom error message for "pattern" keyword
- Is it possible to define a "dictionary" of common error messages?
- errorMessage is not a standard keyword in the JSON Schema specification, hence linting fails HOT 1
- Is this project still being maintained?
- Not working in browser
- Issue when compiling standalone validator with ajv-errors and errorMessage:{ properties:{ HOT 1
- When using ajv-errors package I get this error "Cannot read property 'allErrors' of undefined" HOT 1
- is it possible to add identifier in error, to classify errors
- Generates invalid functions? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ajv-errors.