add type safe parsedInput on MiddlewareFn

[tianhuil]

Hi @TheEdoRan: thanks for a great library!

I would like to be able to do the following:

const zodSchema = z.object(...)

actionClient
  .use(generalMiddleware)
  .schema(zodSchema)
  .use(specificMiddleware)
  .action( ... )

I can understand that generalMiddleware might only have the unparsed clientInput: unknown but specificMiddleware should know the schema and have access to parsedInput, typed according to zodSchema.

One use case would be pulling permissions checks outside of the action in a reusable middleware component. These usually require knowing the client input and the type system should check whether the middleware's required clientInput is satisfied by zodSchema.

[TheEdoRan]

Hi @tianhuil, the problem is that there's no specific or generic middleware in next-safe-action, they're all middleware functions. clientInput and parsedInput are typed unknown because if you do something like this:

actionClient
  .schema(schema1)
  .use(middleware1)
  .schema(schema2)
  .use(middleware2)

Using inference, middleware1 would have types from schema1, but this is wrong, since the input schema gets then overridden with schema2. Basically, middleware1 would have wrong types, since there's no way to guarantee type safety with this design.

[TheEdoRan]

Yeah, I understand the pain. However, I think that overriding the schema can be useful in certain cases. For example, imagine you have a base action builder with a schema that's shared (and potentially extended) by all the actions you create with that client. Later on, while building your app, you might find that you need to define an action with a different schema, while still keeping the same functionality of the base builder (middleware functions, client initialization options). In that case, you'd just call .schema() again, without extending the parent schema, to override it.

While this is an edge case, it's still possible you'll need it. Additionally, changing the behavior of schema() to extend the previous schema by default would be a breaking change, especially considering that it currently supports shapes other than objects, a feature many production apps rely on.

I'll think about it and, if I can come up with a good solution, I'll update this discussion. For now, the recommended approach is to manually type your clientInput and parsedInput inside the middleware function.

[tianhuil]

Hi @TheEdoRan: thanks for considering it!

I would just say that handling permission rules in a type-safe manner is a much more common use case (probably all apps?) than wanting to override the schema.

For example, many apps (e.g. Notion / Slack) have a the general rule "users can read anything in their workspace" which would require a workspaceId: string in parsedInput in many of their actions (and hence their permission rules). However, there are probably actions like updateUserData which are not tied to a given workspace. The types of the individual actions would know whether they have a workspaceId and could help you write typesafe rules. Having middleware that specifically handles permissions helps make the code more modular / promotes code re-use.

[vidrepar]

@tianhuil Thanks for writing this. I've experienced the exact same problem this week.

This is what I wanted to do:

.use(can(({ ctx }) => policies.User.update(ctx.userId)))

However, the parsedInput was nowhere to be found.

The alternative approach was to validate the same schema in a separate middleware and create a validatedInput that's basically the same as the parsedInput but accessible throughout the middleware chain. I don't like it though, because it's parsing the same thing twice and doesn't "throw" the same shape of the validation error as the invalid .schema(....

.schema(userUpdateSchema) // Accessible as parsedInput in the action
.use(validate(userUpdateSchema)) // Accessible as validatedInput in the middleware chain and in the action
.use(can(({ ctx }) => policies.User.update(ctx.userId))) // We'd have to write validation logic inside the policy (permissions) methods in this case or write considerably more code. Doesn't seem right. 
.action(...

@TheEdoRan This is a gorgeous library. I love it ❤️ Should actually be a built-in of the App Router. Keep up this amazing work.

[vidrepar]

@TheEdoRan Why not treating .schema(userUpdateSchema) the same as .use(validate(userUpdateSchema))? Why not treating .schema(... just as a special kind of middleware?

In my case .use(validate(userUpdateSchema)) did the job but was afraid to remove the .schema(userUpdateSchema) because I didn't understand the consequences, eg. would the client/server error handling still work out-of-the-box?

[vidrepar]

In the case of multiple schemas, the parsedInput could look like this:

{
  parsedInput: {
    schema1: {
      id: number;
    },
    schema2: {
      name: string;
    }
  }
}

Additional considerations:

1. If there's only 1 schema that's used, keep the current shape (default that's backwards compatible). If more then use the proposed solution.
2. We could use aliases for the schemas inside the new proposed parsedInput shape to keep things more concise.