You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, I would like to emphasize how simple and useful this library is.
Consider the following use case:
The empty function is used to create an empty object in a form. After the form is filled out, the data is sent to the backend and saved in a database.
Before version 1.3.1, when a property was of type z.string().nullable(), the empty function would return null, which seems like the appropriate behavior. This is because if the field is nullable, it's important to keep the result as null when the field is not filled out. In the case where the resulting object is saved in the database, it's beneficial for it to be saved as null if the field accepts null values.
However, version 1.3.1 modified this behavior, and now an empty string is saved when the field is of type z.string().nullable(). This seems inappropriate, since it's important to maintain the value as null if the schema marked it as nullable - otherwise, the schema could have simply defined z.string().
I made a PR yesterday, but after analyzing my use case more thoroughly, I would like to better understand the repository maintainer's opinion on this issue. Depending on the response, I will make modifications to the PR.
The text was updated successfully, but these errors were encountered:
DenisBessa
changed the title
Subject: version 1.3.1 broke database use case.
Version 1.3.1 broke database use case.
Jan 9, 2025
DenisBessa
changed the title
Version 1.3.1 broke database use case.
Version 1.3.1 broke database use case
Jan 9, 2025
I thought I was the only user of this library, so I made some modifications to suit my specific use case.
From now on, I'll be more careful about making changes.
The PR #23 from @DenisBessa is merged and resolved the issue.
First of all, I would like to emphasize how simple and useful this library is.
Consider the following use case:
The
empty
function is used to create an empty object in a form. After the form is filled out, the data is sent to the backend and saved in a database.Before version 1.3.1, when a property was of type
z.string().nullable()
, theempty
function would returnnull
, which seems like the appropriate behavior. This is because if the field is nullable, it's important to keep the result asnull
when the field is not filled out. In the case where the resulting object is saved in the database, it's beneficial for it to be saved asnull
if the field accepts null values.However, version 1.3.1 modified this behavior, and now an empty string is saved when the field is of type
z.string().nullable()
. This seems inappropriate, since it's important to maintain the value asnull
if the schema marked it as nullable - otherwise, the schema could have simply definedz.string()
.I made a PR yesterday, but after analyzing my use case more thoroughly, I would like to better understand the repository maintainer's opinion on this issue. Depending on the response, I will make modifications to the PR.
The text was updated successfully, but these errors were encountered: