blog/next-chapter-2

[giscus[bot]]

blog/next-chapter-2

This post explores how ZenStack V3 will become a more extensible ORM.

https://zenstack.dev/blog/next-chapter-2

[DawidWraga]

I absolutely love the query builder and computer fields examples in these docs.

However, I feel a little unsure about the procedures.

Would the generated APIs include IO schema validation?

Also, the return value of crud.$procs.signUp() seems to be useMutation return, but it's not a hook. We we need to obide by the rule of hooks when calling procedures? eg could we call crud.$procs.signUp() inside a function?

[ymc9]

Yes, since the procedure inputs are strongly typed, there'll be input validation.crud.$procs.signUp() will be a TanStack query's useMutation. It itself is a hook, but calling it will give you functions like mutate and mutateAsync that you can call as regular functions.

[DawidWraga]

Yes, since the procedure inputs are strongly typed, there'll be input validation.crud.$procs.signUp() will be a TanStack query's useMutation. It itself is a hook, but calling it will give you functions like mutate and mutateAsync that you can call as regular functions.

Ok great to hear there will be input validation. If crud.$procs.signUp() is a hook then would it make sense to prefix it with 'use' to make it more explicit and prevent accidentally breaking react rules

[ymc9]

Yes, maybe. The detailed API signature is not finalized yet.

[sanny-io]

This is seriously great stuff. I'm already using v3 and loving it. Will it be possible to define procedures at both the model level and client level? That's something Prisma supports right now. It could look something like

const db = new ZenStackClient(schema, {
  ...
  procs: {
    $client: {
        ...
    }

    Post: {
      ...
    },
  },
});

client.post.$procs.something()

client.$procs.something()

I think putting everything in the client itself would become hard to organize over time.