Uniforms: JSONSchema: `should be string` validation error when using `date-time`

Created on 2 Feb 2018  路  7Comments  路  Source: vazco/uniforms

When the following JSONSchema is used:

createdDate: {
    required: [ ],
    title: "Created Date",
    format: "date-time",
    type: "string"
}

The form will always fail when submitting with a should be string validation error.

I get the feeling that it is being 'stored' as a JavaScript Date, but the validator is expecting a string. _(That seems to be the case)_

Fixing the above will then result in should match format "date-time".


Solution for now:

        const convertDateValueToString = R.map((val) => {
            if (R.type(val) === "Date") {
                return val.toISOString();
            } else if (R.type(val) === "Object") {
                return convertDateValueToString(val);
            }
            return val;
        });

        this.validator(convertDateValueToString(updatedModel));

I convert the date to a string before in the validator.

bug

Most helpful comment

I understand that all this boils down to the specific schema, and UI used (JSON schema, and Material UI in this case). But, I'm quite confident other people will run into this trap since they'd expect it to work out-of-the-box. I know you closed the issue, but I feel that it should somehow be resolved more formally.

All 7 comments

Hi @MrSaints, sorry for the delay. Yes, you've debugged it correctly. You've also found a solution, which I completely agree. I'm a bit concerned if we should do such preprocessing: on one hand yes, because your validator expects such input but on the other, it will slow down, especially for bigger objects, and it might limit your possibilities: maybe my validator perform coercion? Or it expects a date?

I'd like to hear your opinion here. Also, ping @janowsiany.

Yea, it seems like a bug. I missed that, sorry. I'll take a deeper look by the weekend.

As for me i would be against extending JSONSchema with the code provided above. As you accurately pointed it is all about the validator implementation. So what i would do is putting the convertion code into validator as the secod argument of JSONSchema. You can also use is-my-json-valid which performs coercion in the case described in this issue.
Waiting for you point of view @MrSaints

@radekmie @janowsiany I agree with the both of you. Converting it on validate is a rather expensive / wasteful process as it requires traversing the entire form tree every time the form is dirty / re-validated.

That said, I'm using Ajv as the validator, and technically, we should be giving it a string (in date-time format) as that is what the JSON Schema requirements demands of it. So, I don't think the validator should know about Date or convert it to a string. Perhaps it should be input field that stores the result as a string or somehow get it converted to one before validation, if that makes sense. Sorry, I'm not too familiar with uniforms internal to comment in that respect.

@MrSaints I see we all agree. As you've mentioned, it can be done within the field logic, but the fields are completely schema independent. You can create a custom date picker field, which serialises its value to a string and then use it (even with type string in your schema). Also, if you'd like to convert it every time but more automatically, there's a modelTransform prop on the form - it should work for you.

I understand that all this boils down to the specific schema, and UI used (JSON schema, and Material UI in this case). But, I'm quite confident other people will run into this trap since they'd expect it to work out-of-the-box. I know you closed the issue, but I feel that it should somehow be resolved more formally.

It is working out of the box. As @janowsiany mentioned, there are JSON schema validators with type coercion. Furthermore, you are not forced to use Ajv or even any validator at all - you can write your own, without an extra package.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

simplecommerce picture simplecommerce  路  6Comments

simplecommerce picture simplecommerce  路  4Comments

cesarve77 picture cesarve77  路  4Comments

serkandurusoy picture serkandurusoy  路  5Comments

thearabbit picture thearabbit  路  4Comments