3 ms·

Two random thoughts: - why is there `safeParse`? Why is parsing not safe by default? Have an `unsafeParse` as an escape hatch, not the other way around. - the

Two random thoughts: - why is there `safeParse`? Why is parsing not safe by default? Have an `unsafeParse` as an escape hatch, not the other way around. - the imperative check for `success` seems unfortunate. Then again, I am familiar with pydantic from Python, which seems awfully similar to Zod, and there you'd get an Exception on failure which you'd have to catch. Some would call that uglier (I don't). Point being, I don't know of a better alternative, but sure hope native liquid/dependent types wouldn't suffer from this anymore

mullsork 3y ago
JS doesn't have any useful built-in way to deal with success/failure, other than exceptions. We use Boxed[1] for this: Result .fromExecution(() => schema.parse(input)) .mapOk(parsed_input => /* */) .mapError(parse_errors => /* */) which is an alright way to deal with things IMO. I would hazard a guess that `parse` is a function introduced long ago, and `safeParse` came afterwards. (Safe as in "do not throw an exception") [1]: https://github.com/swan-io/boxed https://github.com/swan-io/boxed
Cannabat 3y ago
`schema.parse()` is equivalent to pydantic `MyModel.parse_obj()` and throws if invalid. `const result = schema.safeParse(val)` does not throw, and if `!result.success`, `result.error` contains a `ZodError` object with all the details. It's common to further transform this error object, perhaps to make it more human-readable or suitable for an API response. Typically I find myself using `safeParse` far more than `parse`.
shepherdjerred 3y ago
You can use `parse` which will throw an exception if the data does not match the schema, or `safeParse` if you want to manually check. > the imperative check for `success` seems unfortunate. Yes! But the cool thing is that `success` being `true` narrows the type and ensures that the `data` field is present. You cannot access `data` without checking for success Here's another example showing those concepts: https://stackblitz.com/edit/typescript-wbuikz?file=index.ts https://stackblitz.com/edit/typescript-wbuikz?file=index.ts

mullsork 3y ago

JS doesn't have any useful built-in way to deal with success/failure, other than exceptions. We use Boxed[1] for this: Result .fromExecution(() => schema.parse(input)) .mapOk(parsed_input => /* */) .mapError(parse_errors => /* */) which is an alright way to deal with things IMO. I would hazard a guess that `parse` is a function introduced long ago, and `safeParse` came afterwards. (Safe as in "do not throw an exception") [1]: https://github.com/swan-io/boxed https://github.com/swan-io/boxed

Cannabat 3y ago

`schema.parse()` is equivalent to pydantic `MyModel.parse_obj()` and throws if invalid. `const result = schema.safeParse(val)` does not throw, and if `!result.success`, `result.error` contains a `ZodError` object with all the details. It's common to further transform this error object, perhaps to make it more human-readable or suitable for an API response. Typically I find myself using `safeParse` far more than `parse`.

shepherdjerred 3y ago

You can use `parse` which will throw an exception if the data does not match the schema, or `safeParse` if you want to manually check. > the imperative check for `success` seems unfortunate. Yes! But the cool thing is that `success` being `true` narrows the type and ensures that the `data` field is present. You cannot access `data` without checking for success Here's another example showing those concepts: https://stackblitz.com/edit/typescript-wbuikz?file=index.ts https://stackblitz.com/edit/typescript-wbuikz?file=index.ts