#mike_best-practices

1 messages · Page 1 of 1 (latest)

civic vesselBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1506950612397457458

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

brazen quartz
last vine
#

I am talking about our implementation meaning we use "your" types in "our" wrapper methods and functions calling later the stripe client.

retrieveWithCheck(payload: Stripe.Charge) { // the problem is here
  // our business logic and finally:
  const result = await stripe.something.retrieve(payload);
}
#

Thanks. I understand the types were intentionally removed and I am not asking to change that.

What is the recommended pattern from Stripe’s point of view for larger TypeScript backends where Stripe result types need to be referenced outside the exact place where the Stripe client method is executed?

For example, in CQRS we need the command/query to declare its result type, while the actual Stripe SDK call happens later in a handler:

export class CreateStripePaymentSessionCommand extends Command<
    Awaited<ReturnType<Stripe['checkout']['sessions']['create']>>
> {
    constructor(
        public readonly payload: IStripeCheckoutSessionCreateInPaymentMode,
    ) {
        super();
    }
}

Is this derived ReturnType approach the intended best practice for these cases, or does Stripe recommend another pattern for naming and reusing response types across application layers?

civic vesselBOT
brazen quartz
#

Not sure honestly how you can export the (removed) types from Stripe package and use it in your own packages...

#

Your suggest seems reasonable though

last vine
#

With standard type utility ReturnType and Awaited in case of promise. The only issue here is the lastReponse property that you add via Reponse type which makes return types from Webhook Events non compatible. We'll fix it by own generic type utility but this could be available out-of-the-box IMHO

lavish void
last vine
#

ok, thanks