Make .parse an assertion function

[kentcdodds]

const Post = z.object({slug: z.string()})

const thing = JSON.parse('{"slug": "hi"}')
// thing is any
Post.parse(thing)
// thing is {slug: string}

I realize that I could do const thing = Post.parse(JSON.parse(...)) or make a second variable, but I don't really want to do that. My use case is in Remix.

Here's what I have to do now:

const data = LoaderData.parse(useLoaderData())

But some people are freaked out when they see me passing a hook call in an arguments list. So I'd prefer to be able to do this:

const data = useLoaderData()
LoaderData.parse(data)

But currently that leaves data as any.

[kentcdodds]

To be clear, I'd also be satisfied with a function that is an assertion function on its own. LoaderData.check(data) or something would be perfect too.

[kentcdodds]

Thanks @JacobWeisenburger, but that's not what I was looking for. What I want is an assertion function. That means that after the function is called TypeScript knows that type of the value, for example:

function isString(s: unknown): asserts s is string {
  if (typeof s !== 'string') throw new Error('not a string')
}

const someValue: unknown = 'string'

// @ts-expect-error someValue is unknown
someValue.toLowerCase()

isString(someValue)

// TypeScript knows now that someValue is a string
someValue.toLowerCase()

[scotttrinh]

@kentcdodds Glad to see your interest in Zod. You've been a huge part of my career and I always look to your blog and videos for high quality content and thoughtful guidance. 🙏

parse doesn't assert anything about the input data because it's possible to transform the data, so the only thing we can really be certain about is the input type. It's possible that we could assert the input type, but there are two complications:

1. preprocess means we'd be wrong in some cases since that works on the data before the input schema.
2. This is more of a documentation/social issue, but I think the fact that it asserts the input type would be a source of confusion.

Having said that, I could imagine a method that asserts the input type like assertInput, with a caveat about preprocess. I imagine that since you'd have to go back and forth depending on if you need transformations or not, it might be better to write a custom hook, maybe? That's the approach we've taken on my team.

[kentcdodds]

Hey @scotttrinh,

Thanks for the kind words! I'm glad I've been helpful to you :)

If this were just for my own apps then a custom hook would be fine, but I'm thinking about using this in official Remix docs and we want to have something that feels nicer than telling people to make their own hook. Something you can add without much work.

I think an assertInput method would be perfect. I've never heard of preprocess, but I think I would prefer that preprocess is ignored for the assertInput if possible.

[kentcdodds]

Basically, I'm looking for https://docs.superstructjs.org/api-reference/core#assert but I slightly prefer zod's APIs so I'd prefer to not switch 😅

[scotttrinh]

Ahh, I keep forgetting that we never updated the documentation when we added preprocess. For reference, it is a function that is run with (unknown) => Input for doing things like string to date, number coercion, etc.

For the moment, I would probably steer toward using parse in any documentation, since I would want to hear from @colinhacks on his feeling toward something like assertInput, and any additional thoughts he might have on the topic. I know you know your audience best, but since parse does work, stylistic qualms notwithstanding, I would definitely consider that the most robust and least footgun-y approach to using Zod in this way.

[scotttrinh]

Basically, I'm looking for https://docs.superstructjs.org/api-reference/core#assert but I slightly prefer zod's APIs so I'd prefer to not switch 😅

Ahh. I am a big fan of superstruct and I consider them one of the best for the composable-style (rather than Zod's fluent-style). I'll also see what they are doing since they also offer some transformation options.

[scotttrinh]

Wow, I did not mean to fall down this rabbit hole today. Looks like having assert as a method just doesn't really work. We can have it as a function, but I'm not sure if that negates your aesthetic requirement here @kentcdodds .

FWIW, having it as a function is a pretty trivial implementation, but there is no way to not run the preprocess in that case without exposing some kind of special version of parse that doesn't do the preprocessing, which feels a little dirty. Might have to wait until the upstream TypeScript limitation is addressed (microsoft/TypeScript#34596)

[kentcdodds]

Having a separate function that applies the preprocess is fine for my use case 👍

[richardscarrott]

I'm keen to replace all my node:assert call sites with a single validation library that can handle the simple case (no parse + primitive values) just as well as the complex case (parsing + object values).

I was using my own library but it's parsing offering isn't great and I've since found zod!

I think three features which would be necessary to become a replacement for more everyday assert use cases would be:

1. Accept custom error objects so call sites can include more context

2. Bypass preprocess so it's genuinely asserting the input

3. Support ability to narrow types (e.g. given type x | y assert it's not y and therefore is x)

   // https://nodejs.org/api/assert.html#assertvalue-message
   import { assert } from 'node:assert';
   const user: User | null = getUser('usr_123');
   assert(user, 'User not found');
   // user // => User

   // https://github.com/richardscarrott/ok-computer/blob/bb40b2fb7e09b3cd3b626bfca8164194604102ab/src/ok-computer.ts#L754
   import { assert, exists } from 'ok-computer';
   const user: User | null = getUser('usr_123');
   assert(user, exists, 'User not found');
   // user // => User

I've started to use the following which handles 1. but not 2. or 3.

function zAssert<Val, Type extends ZodType>(
  value: Val,
  type: Type,
  err?: Error | ((zodErr: z.ZodError) => Error | string) | string
): asserts value is Type['_output'] {
  const result = type.safeParse(value);
  if (result.success) {
    return;
  }
  const error =
    typeof err === 'function'
      ? err(result.error)
      : typeof err !== 'undefined'
      ? err
      : result.error;
  throw typeof error === 'string' ? new Error(error) : error;
}

const createUser = async (name: string, age?: number) => {
  const user = userType.parse({
    _id: 'usr_123',
    name,
    age,
  });
  const result: any = await db.insertOne(user);
  zAssert(
    result,
    z.object({ acknowledged: z.literal(1), insertedCount: z.literal(1) }),
    new VError({ info: { result, userId: user._id } }, 'Failed to insert into db')
  );
  // result.acknowledged // => 1
  return { success: true, user };
};

For further examples; this is the kind of assert calls I'd like to replace with zod https://github.com/richardscarrott/ok-computer/blob/master/examples/vanilla/src/index.ts

Would be interested to hear if there's appetite to support the ability to optionally bypass preprocessing?

[kkirby]

Damn. I wanted to switch from io-ts, but not having something akin to .is() is a dealbreaker for me. Having a preprocess step really hinders things, and to me seems a bit of scope creep.