Lack of options to ignore errors

[elmeister]

We're introducing this beautiful library on FE side and encountered unpleasant aftermath of this decision - increase in the number and severity of site errors. The problem is that even if some, in other case not important, error is there - like some value is undefined, instead of an empty string - where we previously could have just some empty div - now the whole server response fails to be processed. In our case we have plenty of nested .transform(), so there's just no chance to pass and process them anyhow separately - to pass them additionally to some custom wrapper or anything like that - we have to rely on zod. Would be nice to have some option to still enforce .parse() to keep proceeding with .transform(), even without guarantee of the final validity - since we already will have what we're looking for - information, that some data is in unexpected format - instead of ruined UI, which is a very high price to pay.

[scotttrinh]

I would say that the goal of Zod is the ensure that the data you get after calling parse is precisely in the format you expect based on the inferred type. So if some data can be undefined, you're going to have to be honest about that and make it .optional(). That gives you runtime guarantees about what the actual type is when you go to use it. Otherwise, if you don't actually care about the runtime type of the data you get back, I'm not sure why you'd want to use Zod (or even TypeScript 😅 ).

It's possible that you can leverage passthrough more in your usage to get the idea you want, so if you can share some valid input and output data, maybe we can suggest a strategy using Zod? Otherwise, it's pretty easy to transform data in TypeScript/JavaScript directly, no need to use Zod.

[elmeister]

I do agree with you about "that's actually the whole idea", so probably it's just our case is quite specific. We have some legacy blocks in responses, and one of the goals is to get rid of improper casing, namely kebab-case -> snake_case transformation.

At the moment, on FE side toSnakeCaseDeep() is widely used, which allowed us to switch to more unified types, yet introduced the problem that it's hard to align FE and BE efforts, since FE types are defined for state "after" transformation - so we can't really tell what is there before update to snake case. From BE side situation is problematic as well - for nested values it takes enormous effort to find out if something can be safely changed to snake_case format or not.

So decision was made - to introduce zod validation on FE side and share these schemas with BE to be able to completely transfer BE to snake_case - and remove .transform() from schemas. Because of this decision, we now have to move on FE side all kebab -> snake updates to these .transform() modifications and of course we introduced plenty of them.

The problem is that we are quite sure that current data from responses will work fine on the site - since it just works without any issues - whatever there could be with "small" problems, like something can be null or undefined - everything is already covered.

Yet now it's very difficult for us to fix all the possible cases for those "null or undefined" or .optional() issues, and whenever something happens - some big block or the whole page just fails to load.

For now we weren't able to find out how to deal with this situation and will appreciate any advice - how to keep .transform() running even with error, since this error is most likely not a problem.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.