 is a TypeScript-first schema declaration and validation library. It ensures that your data is valid before it is submitted to the server, which means less invalid data and fewer errors on your end. Additionally, Zod allows you to create custom input types to tailor the user experience to your specific needs. Overall, using Zod can help streamline your development process by making sure that your forms, inputs, and API requests are error-free from the start. If you're looking for a reliable way to create typesafe forms and inputs, Zod is worth checking out!

How can Zod help with type safety in forms and input from users?

Zod can help ensure that your forms and input are type-safe, so you won't accidentally allow incorrect data types to be entered into your system. This can help prevent errors from happening in the first place and means that you don't have to write custom validation code for your forms and input fields.

Zod can also help enforce rules around what data can be entered into your forms and input fields, ensuring that only valid data is accepted. By using Zod, you can avoid having to write any extra code or manually check user input against these rules - it will all be handled automatically by Zod. This makes your forms and inputs more reliable and robust against errors.

Overall, using Zod can help improve the quality of your forms and input, making them easier to use, more accurate, and less prone to error.

Why should developers consider using Zod?

Zod offers type-checking for JavaScript, which can be helpful for developers who want to ensure their code is error-free. Zod's validation methods can also be used to enforce input from users, ensuring that only valid data is submitted. Using Zod can help make your development process more efficient and reduce the risk of introducing bugs into your codebase.

First, you need to make sure you have strict mode enabled in your Typescript project.

yarn

pnpm

Now you can create a schema to handle your needs, lets's say we want all inputs to be a string we can do that:

Now in some cases, we don't want to throw an error we want Zod to tell us we have had an invalid input so we can handle it somewhere else in the stack

Object schemas allow you to handle complex inputs and validate them and give you an inferred type. 

One part no one wants to write is the regex to validate strings, I wrote a regex package a few years ago because who wants to remember how to validate the user input of an email? Zod provides a handful of validators, lets's improve our User object:

Now a user has to input an email in our email field, which will be validated, and our username must be at least five characters. 

Zod allows you to provide a custom error to present to the user so they understand why they need to change input. 

This is just the beginning of Zod, if you are interested, you can check out their 

Zod Typesafe User Input

When Next.js announced Next 13, they announced the release via a very shiny Apple-style keynote. So naturally, the audience "oohed" and 'aahed' at the new features and QoL fixes we have all been waiting for. 

After the event, I flew home and started seeing tweets from Next.js team members with things like "Upgrade to 13 it is stable" and "Next.js 13 is stable, just the app directory is in beta". This went on for a while after the release, and it still feels like people are unsure about it. 



Lumping the app directory as part of the Next.js 13 release was the right decision; the wrong decision was making the keynote "Next 13" and talking entirely about the app directory for 10 minutes. 


Suppose the Vercel team had done this separately after talking about Next 13 as the final thing. Then, I think people may have understood that the app directory is new, relaxed, and not ready for prime time, but upgrading to Next 13 isn't going to explode your application. 

I still feel this is still a huge pain point for users of Next 13, and I see it daily trying to explain that we at Clerk support Next.js 13 and also Next.js beta app directory. 

Did the Next.js team fumble Next.js 13 release?

Next Link is one of my favorite features of Next.js, when it launched I was impressed with the team over Vercel when they handled internal versus external links.

 along so where does the target="_blank" go? Here is an example of Next Link:

The solution is to keep the actions on the 

 so it plays nicely with CSR (Client side routing) for example:

How to open a link in a new tab

The Problem

The Solution