Hacker News Reader

Comment by diarrhea | Hacker News Reader

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

View on HN

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

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

`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`.

Reply on news.ycombinator.com