Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using non-standard formats #16

Closed
jnv opened this issue Dec 13, 2018 · 6 comments
Closed

Allow using non-standard formats #16

jnv opened this issue Dec 13, 2018 · 6 comments
Labels
enhancement New feature or request

Comments

@jnv
Copy link
Contributor

jnv commented Dec 13, 2018

The format method checks if the passed format is supported by the specification. However, validator can support custom, non-standard formats, for example Ajv has addFormat method. Would it be possible to allow passing non-standard format?

To maintain current behavior, perhaps it could be a different method, for example:

FluentSchema().asString().customFormat('my-custom-format')
  // => {type: 'string', format: 'my-custom-format'}
@aboutlo
Copy link
Collaborator

aboutlo commented Dec 13, 2018

I need to dig into the specification but it doesn't seem a good idea to add a flavor. Maybe I'm too careful. Let me think more about that. @mcollina thoughts?

@mcollina
Copy link
Member

IMHO it’s a bad idea, but a lot of people ask/need this. Providing some sort of escape hatch to add this would be good to accept as a PR.

@jnv
Copy link
Contributor Author

jnv commented Dec 14, 2018

The spec says:

Implementations MAY add custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support this keyword and/or custom format attributes.

In our case this is useful for reducing boilerplate in schemas within a shared domain. It is more readable to specify a semantic format rather than to repeat pattern everywhere.

I will be happy to submit a MR if you specify how the API should look.
Beside an additional method, perhaps one could pass an array of custom supported formats to FluentSchema(), though that could cause a lot of duplication or mistakes during authoring.

@aboutlo
Copy link
Collaborator

aboutlo commented Dec 14, 2018

I don't like to add a customFormat method but following @jnv idea we could pass an array e.g. extraFormats as option something like that:

FluentSchema({extraFormats: ['my-custom-format']}).asString().format('my-custom-format')

In the JSDoc of the format method, we could add the above example

Then in the format implementation, we can merge FORMATS and extraFormats to check that the format is supported.

Name wise I don't like too much extraFormats or customFormats, but I think it's misleading using formats someone could think we are overriding the default FORMATS.

Test wise we have do double check that in a nested schema the extraFormats are propagated to the children. It should I did a refactoring in the 0.3.0 version so it should. 🤞

@aboutlo aboutlo added the enhancement New feature or request label Dec 21, 2018
@aboutlo aboutlo mentioned this issue Dec 7, 2019
@aboutlo
Copy link
Collaborator

aboutlo commented Dec 7, 2019

Moved the discussion here: #55

@aboutlo aboutlo closed this as completed Dec 7, 2019
@jnv
Copy link
Contributor Author

jnv commented Dec 7, 2019

Thanks @aboutlo, support for raw JSON injection is quite a good compromise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants