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

Add brand to ZodBranded def at runtime #2860

Closed
wants to merge 1 commit into from

Conversation

nahvego
Copy link

@nahvego nahvego commented Oct 11, 2023

Make brand available at runtime when used as a parameter for .brand()

With this brand() can be used to enable external code to operate on types based on definition.

Typing is left as-is to be backwards-compatible so instead of overriding the BRAND symbol this just puts the brand parameter of the constructor in _def.

Let me know what you think! 🙂

@netlify
Copy link

netlify bot commented Oct 11, 2023

Deploy Preview for guileless-rolypoly-866f8a ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 0bd2d6c
🔍 Latest deploy log https://app.netlify.com/sites/guileless-rolypoly-866f8a/deploys/6527187499768f0008cef16b
😎 Deploy Preview https://deploy-preview-2860--guileless-rolypoly-866f8a.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@RobinTail
Copy link
Contributor

@colinhacks , please make branded types programmatically distinguishable.
That would be a huge help!

RobinTail added a commit to RobinTail/express-zod-api that referenced this pull request Jan 10, 2024
I was dreaming about it.
Unfortunately `zod` does not provide any way to make a custom or branded
or third-party schema that can be identified as one programmatically.
Developer of `zod` also does not want to make any method to store
metadata in schemas, instead, recommends to wrap schemas in some other
structures, which is not suitable for the purposes of `express-zod-api`.
There are many small inconvenient things in making custom schema
classes, that I'd like to replace into native methods, and use
`withMeta` wrapper for storing proprietary identifier, so the generators
and walkers could still handle it.

Related issues:

```
colinhacks/zod#1718
colinhacks/zod#2413
colinhacks/zod#273
colinhacks/zod#71
colinhacks/zod#37
```

PR I've been waiting for months to merged (programmatically
distinguishable branding):

```
colinhacks/zod#2860
```
@colinhacks
Copy link
Owner

colinhacks commented May 3, 2024

The fact that the type-only .brand<T>() API already exists mean that there's no guarantee that and given ZodBrand instance will contain ._def.brand, so no third-party code generation libraries can rely on it. Plus, branding is inherently a static-only construct, so this just feels a bit icky in general.

If you need this for your own purposes, Zod 4's plugin system will let you hack this a bit by adding another overload to .brand() (I think...). But I'm afraid I'm not a fan of putting this into Zod core.

@artalar
Copy link

artalar commented May 8, 2024

@colinhacks What do you think about allowing to put "unique symbol" from a user space code?

RobinTail added a commit to RobinTail/express-zod-api that referenced this pull request May 9, 2024
Due to #1721,
colinhacks/zod#2860 (comment), and
#1719 I'm exploring the possibility to alter the behaviour of `.brand()`
for storing the `brand` property as a way to distinguish the proprietary
schemas in runtime.

This can replace the `proprietary()` function with a call of `.brand()`.

However, so far it turned out to be breaking because `ZodBranded` does
not expose the methods of the wrapped schema, such as `.extend()`, which
is used in `accept-raw.ts` endpoint for possible route params.

——

After a series of serious considerations I realized that exposing brand
to consumers of `express-zod-api` could be a beneficial feature.
Runtime brand can be accessed via
`._def[Symbol.for("express-zod-api")].brand`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants