Add dynamic param suport for `.prefix`

[dinwwwh]

Describe the feature

Current limitations for generating specs and accessing dynamic parameters:

1. For generating specs: Instead of requiring dynamic parameters to exist in the .input schema, we can assume they expect a string type when we cannot infer it from the .input schema.

2. For accessing parameters: We can inject them into the context and access them through a unique symbol:

const router = os.prefix('/{organizationId}').use(({ next, context }) => {
    const organizationId: string | undefined = getDynamicParams(context).organizationId
    return next()
}).router({
    // ...
})

Warning

This draft is still missing some important things:

• How RPC stubs works (because RPC has no definitions for params) from client to server
• How client works? where to define there params when invoke?
• Because .prefix only effect procedure with defined paths inside .route, how does it work in this case?
• ... Personally, I think this shouldn't be implemented in oRPC. If you require parameters for the entire router, why not put them in the headers? If you still need this kind of feature, you can combine it with a third-party router like Hono for the dynamic params part.

Additional information

• Would you be willing to help implement this feature?

[etc-tiago]

Currently, I use Hono that allows to use it this way. Basically, I need a dynamic parameter to filter requests in the Analytics/audit process.

I've been looking for a more practical and native way to use.

Is your intention to get the object in .use(({ next, params, context })?

Here are some cases I've been thinking about:

• os.prefix('/{organizationHash}', {organizationId: 'uuid'}).use(({ next, params, context }) to get params.organizationHash as uuid.
• os.prefix('/{organizationId}', {organizationId: 'number'}).use(({ next, params, context }) to get params.organizationId as number.
• os.prefix('/{organizationId}/{organizationHash}', {organizationId: 'number', organizationHash: 'string'}).use(({ next, params, context }) to get params.organizationId as number and params.organizationHash as string.

Let me know if we're aligned so I can submit a pull request about it.

[dinwwwh]

Let me know if we're aligned so I can submit a pull request about it.

Thank you, it's still missing too many things. I can't figure out how to deal with it in an ideal way. Please check the latest issue update.

[etc-tiago]

My contribution wasn't successful; it was based on a fork with code modified for my use, ignoring some tests and best practices. I'll review the code again and try a new approach... perhaps it would be better to include it as an input parameter, since the client wouldn't need to modify the context and just include it in the mutation, if required.

Today, in my code with Hono, I need to modify the base path in the Link configuration on the client, which gives me a headache because I don't have access to this information on the first load of the code. This forces me to use cookies, but it's also not a good practice.

• An edge case is when there are multiple organizations that use a selector to change them, leading the user to have a different base path.

Please keep an open mind about this issue/feature so I can come up with an implementation that works for me and for you.

[dinwwwh]

• An edge case is when there are multiple organizations that use a selector to change them, leading the user to have a different base path.

I'm not sure, but the url option in the link can accept an asynchronous callback, just like headers. The URL can change dynamically with every call. Since this is more related to authentication/sessions, putting it in the headers would be fine.

Please keep an open mind about this issue/feature so I can come up with an implementation that works for me and for you.

It's important not to cause a mess, be very careful when introducing any APIs that are only related to OpenAPI, as oRPC is more than that.

[etc-tiago]

Yeah, I don't think it's necessary to add a new layer of code to oRPC, as this creates more problems than it solves.

The best way is to use an existing framework (like Hono) to have dynamic components and validate them with hono/validator and zod, for example, to pass them to the context.

// @see https://orpc.unnoq.com/docs/adapters/hono
import { Hono } from 'hono'
import { RPCHandler } from '@orpc/server/fetch'

const app = new Hono()

const handler = new RPCHandler(router)

app.use('/{dinamicParam}/*', async (c, next) => {
  const dinamicParam = c.req.param('dinamicParam')
  // some validations
  const { matched, response } = await handler.handle(c.req.raw, {
    prefix: `/${dinamicParam}`,
    context: {
        dinamicParam
    }
  })

  if (matched) {
    return c.newResponse(response.body, response)
  }

  await next()
})

export default app

[dinwwwh]

This issue will be resolved in v2 through PR #1593.