Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional fields in hosted_page.checkout_new#subscription #12

Open
L2jLiga opened this issue Dec 7, 2020 · 3 comments
Open

Additional fields in hosted_page.checkout_new#subscription #12

L2jLiga opened this issue Dec 7, 2020 · 3 comments
Assignees

Comments

@L2jLiga
Copy link

L2jLiga commented Dec 7, 2020

In chargebee we used additional fields inside subscription like cf_filename which is impossible with this library and we have to cast subscription object as any

@ced-mos
Copy link

ced-mos commented Apr 28, 2023

Here my solution on how I solved this issue while preserving type safety and removing my linting errors.

First of all I extended the existing interface as follows:

interface customSubscriptionListParams extends _subscription.subscription_list_params {
  filename?: filter._string;
}

afterwards I just made a cast to this interface like:

this._chargebeeClient.subscription
        .list(<customSubscriptionListParams>{
          limit: 1,
          cf_filename: { is: filename },
        })

Hence, the type checks exists for the default variables but also for the additional custom field.

The only draw back I see is that this needs to be adapted per request instead of that there would be a central location which is exactly what @jaska120 asked for in #28.

Hence, Chargebee, if you have a solution to that, please let us know.

@dreadjr
Copy link

dreadjr commented Jul 17, 2023

Could do something like this too, alternative, has it's draw backs

declare module 'chargebee-typescript' {
  namespace _subscription {
    interface subscription_list_params {
      cf_filename?: filter._string;
    }
  }
}

@cb-sriramthiagarajan
Copy link
Collaborator

cb-sriramthiagarajan commented May 10, 2024

Hi @L2jLiga, I'm sorry for the dealyed response.

Thank you @ced-mos for the solution. I'd also suggest extending the predefined interface to include your custom field. @L2jLiga — were you able to try this and did it help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants