Show HN: Obey JavaScript Data Validation and Modeling
1–6 of 6 posts
Re: Show HN: Obey JavaScript Data Validation and Modeling
#2Looks cool. Does it generate human-readable documentation about the schema? How does it relate to JSON Schema (if at all)? We had to create an ad hoc schema definition DSL for validation and doc gen, and I wish there had been more tools like this at the time.
Re: Show HN: Obey JavaScript Data Validation and Modeling
#3Looks cool. Does it generate human-readable documentation about the schema? How does it relate to JSON Schema (if at all)? We had to create an ad hoc schema definition DSL for validation and doc gen, and I wish there had been more tools like this at the time.
Since the models are "Just JSON" you can do a lot with them. We wrote a doc generator internally; I never thought about adding it to the lib but I will now :)
Re: Show HN: Obey JavaScript Data Validation and Modeling
#4I don't understand why it returns a promise. Are some of the validators asynchronous (ex: call an outside resource and validate against the response)? All of the example appear to define validations that could be run synchronously.
Re: Show HN: Obey JavaScript Data Validation and Modeling
#5I don't understand why it returns a promise. Are some of the validators asynchronous (ex: call an outside resource and validate against the response)? All of the example appear to define validations that could be run synchronously.
Two reasons:
1. It allows for asynchronous validation, see: http://technologyadvice.github.io/better-email-validation-wi...
2. It more cleanly supports the nature and flow of data i/o - in our use of Obey we are (almost) always following validation up with another async operation, i.e. obey.validate({}).then(...something else with the data...)
Re: Show HN: Obey JavaScript Data Validation and Modeling
#6I don't understand why it returns a promise. Are some of the validators asynchronous (ex: call an outside resource and validate against the response)? All of the example appear to define validations that could be run synchronously.
Two reasons: 1. It allows for asynchronous validation, see: http://technologyadvice.github.io/better-email-validation-wi... 2. It more cleanly supports the nature and flow of data i/o - in our use of Obey we are (almost) always following validation up with another async operation, i.e. obey.validate({}).then(...something else with the data...)
So the answer to the question "are some of the validators async?" is "Yes."
That makes perfect sense then, thanks! Looks like a great lib where async validators are needed.