Expected a ZodObject, received: [object Object]

[denyncrawford]

Is there any limitations on the routers or the procedures for using the library? using 0.2.1.

this is the error it throws:

I have a lot of procedures on my router by this moment so i can't tell which one is failing while generating the docs, but this is my router structure:

and this is an example of my authRouter:

I'm pretty sure i'm using zod schemas on every input.

How can i debug it?

[denyncrawford]

I identified the problem and it's here:

Seems like it is not supporting strings as input, is this intentional?? so the library actually restricts the kind of inputs my procedures use?

Why not to add support to al types of inputs? I guess that trcp gives you the versatility to use any kind of input on your procedures, what if i want to use a boolean as body?

[dtinth]

Thanks for raising this issue.

I never created any procedure that has an input type of anything other than object. For your getUserById, I would turn its input into an object:

.input(z.object({ id: z.string() }))

This also provides the flexibility when we want to add extra parameters in a backwards-compatible way:

.input(z.object({ id: z.string(), minimal: z.boolean().optional() }))

So when I built this, I have two reasons for supporting only object inputs:

• I want to discourage the usage of non-object inputs. Many procedures that received non-object inputs end up having to be refactored to receive an object input when I want to add an extra parameter. The refactor was not fun. Also, if the backend and frontend are deployed separately, then there is a window of time where the backend changed in a backwards-incompatible way. So to avoid all this headache, it became my rule of thumb to always use objects as input. And it so happened to be codified in this library too.

• From a library maintainer perspective, supporting more types of input means more maintenance cost (e.g. to create and maintain more tests, more code means more ways things can go wrong, etc). So I try to keep this library as minimalist as possible.

By the way, I am not using tRPC as much anymore and don't have much resources to maintain it. If you’d like to maintain a fork with support for more input types and other features, I would be happy to point users there.

[denyncrawford]

Sure, it is already solved, maybe i'm doing a pr later.

I think it is ok to think as you do but that is a user world problem to solve, otherwise you are building an opinionated way to build your procedures, and probably i don't want that. If the library for document my code breaks it i probably won't use it.

On the other hand i think this is a very good project and i learned some things about zod schema transformations and it is basically you can transform them to any kind of data structure you want, for instance, ts-types. So i'll be taking this project as inspiration for an idea a have about trpc, thank you for your feedback, here it working: