"inferMiddlewareBuilderOptions" - A helper type to infer middleware options

[MlNl-PEKKA]

I came across a piece of code with piping middlewares, which could be improved by abstracting away some code into helper functions. One, it helped clean up the code. Two, it helped me with dropping non blocking tasks in a Promise.all.

Example:

export const auth = session.unstable_pipe(async ({ next, ctx }) => {
  let session;
  let user;
  /*
------------------------------------------------------------------ 
    PREVIOUS:
    session = async code to extract session, throw on error
    user = async code to fetch user, throw on error
-------------------------------------------------------------------
    NEW:
    [session, user] = await Promise.all([getSession, getUser])
    throw on either error
------------------------------------------------------------------
  */
  return await next({
    ctx: {
      ...ctx,
      session,
      user,
    },
  });
});

A solution that I came up with was a "inferMiddlewareBuilderOptions" type which is a middleware counterpart to the "inferProcedureBuilderResolverOptions" helper type for procedures.

import {
  MiddlewareBuilder,
  MiddlewareFunction,
} from "@trpc/server/unstable-core-do-not-import";


type inferMiddlewareBuilderOptions<T, $ContextOverridesOut = undefined> =
  T extends MiddlewareBuilder<
    infer TContext,
    infer TMeta,
    infer TContextOverrides,
    infer TInputOut
  >
    ? Parameters<
        MiddlewareFunction<
          TContext,
          TMeta,
          TContextOverrides,
          $ContextOverridesOut,
          TInputOut
        >
      >[0]
    : never;

Could this be a useful addition to the library? And also, there are some internal types being used here, so is there any better solution to this?

[KATT]

https://trpc.io/docs/server/procedures#inferProcedureBuilderResolverOptions

[MlNl-PEKKA]

Hey Alex 👋 . Thank you, for your reply. It seems that there's some confusion about the above requirement. inferProcedureBuilderResolverOptions works fine for procedures. I'm talking about a helper type to infer the middleware options. As stated in the requirement, it'd helpful in inferring input types while piping middlewares, especially for breaking up logic into separate functions.

I'm trying to achieve something like this:

export const adminProcedure = t.procedure.use(adminMiddleware);

const adminMiddleware = authMiddleware.unstable_pipe(async (opts) => {
  const [user, session] = await Promise.all[(getUser(opts), getSession(opts))];
  if (user.role !== "admin")
    throw new TRPCError({ code: "FORBIDDEN", message: "Unauthorized" });
  return await opts.next({ ctx: { ...opts.ctx, user, session } });
});

const getUser/getSession = async ({
  next,
  ctx,
  cookies,
  headers,
  db,
}: inferMiddlewareBuilderOptions<typeof authMiddleware>) => {
  // fetch the user/session
  return user/session;
};

I tried using the inferProcedureBuilderResolverOptions for inferring middleware options, as you pointed out in the above reply. However it doesn't seem to yield the expected result.

Please, correct me if I'm doing this in a way that you didn't intend.

[MlNl-PEKKA]

It seems like the inferProcedureBuilderResolverOptions will work fine with extending procedures. This also seems to be the way the docs recommends. However, I never extended a single procedure/router and went ahead with only extending middlewares. And then creating multiple procedures.

I get that, that the procedures themselves can be extended to achieve the same goal. But is my approach an anti-pattern? If so, when exactly is the unstable_pipe/extending middleware pattern applicable?

[KATT]

Can you book a call with me next week?

I'm curious to your usage of unstable_pipe as I've considered if we should deprecate that altogether

I think you can achieve everything you want with base procedures and unstable_concat instead - it should be easier and more extensible

[MlNl-PEKKA]

Thanks again! I look forward to the meeting.

[limegorilla]

What was the outcome of this?

I have the exact same use case