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

Error type not matching the documentation #101

Closed
tnguyen42 opened this issue Sep 28, 2021 · 4 comments · Fixed by #102
Closed

Error type not matching the documentation #101

tnguyen42 opened this issue Sep 28, 2021 · 4 comments · Fixed by #102
Assignees
Labels
bug Something isn't working

Comments

@tnguyen42
Copy link

tnguyen42 commented Sep 28, 2021

I noticed that when printing the error using the onError property on the component, the error was stringified for some reason. Therefore, it was only printing Error.

Furthermore, to access the "actual error", I had to console.log(error.statusCode) or console.log(error.statusMessage), as the documentation indicates that this is the actual shape of the Google Pay error: https://developers.google.com/pay/api/web/reference/error-objects

However, the expected type in this package (@google-pay/button-react/dist/index.d.ts, line 33) expects the standard Error from TypeScript, which doesn't have the statusCode and statusMessage properties, causing the error handling difficult without overwriting the type at least locally.

Unless I mistunderstood something, I think it should instead use a custom error with statusCode and statusMessage properties.

My suggestion would be to define an interface just above the Config interface:

interface GooglePayError extends Error {
    statusCode?: string;
    statusMessage?: string;
}

And using it instead of Error in the Config interface:

interface Config {
    environment: google.payments.api.Environment;
    existingPaymentMethodRequired?: boolean;
    paymentRequest: google.payments.api.PaymentDataRequest;
    onPaymentDataChanged?: google.payments.api.PaymentDataChangedHandler;
    onPaymentAuthorized?: google.payments.api.PaymentAuthorizedHandler;
    onLoadPaymentData?: (paymentData: google.payments.api.PaymentData) => void;
    onCancel?: (reason: google.payments.api.PaymentsError) => void;
-   onError?: (error: Error) => void;
+   onError?: (error: GooglePayError) => void;
    onReadyToPayChange?: (result: ReadyToPayChangeResponse) => void;
    onClick?: (event: Event) => void;
    buttonColor?: google.payments.api.ButtonColor;
    buttonType?: google.payments.api.ButtonType;
    buttonSizeMode?: google.payments.api.ButtonSizeMode;
    buttonLocale?: string;
}
@tnguyen42 tnguyen42 added the bug Something isn't working label Sep 28, 2021
@socsieng
Copy link
Collaborator

Thanks for reporting this. I think the actual problem here is that in some cases onError will receive Error while in other cases, onError receives google.payments.api.PaymentsError.

In any case, the onError method signature is currently incorrect. The correct method signature would look something like this:

function onError(error: Error | google.payments.api.PaymentsError) {}

This would mean that if you needed access to statusCode or statusMessage, you would need to do something like this:

function onError(error: Error | google.payments.api.PaymentsError) {
  if (error instanceof Error) {
    console.log('Error', error, error.message, error.stack);
  } else {
    console.log('Error', error.statusCode, error.statusMessage);
  }
}

Does this make it easier or harder for you?

@socsieng socsieng self-assigned this Sep 28, 2021
socsieng pushed a commit that referenced this issue Sep 28, 2021
The `onError` method signature is currently incorrect. This change will make it consistent with what is actually happening at runtime.

Note that this is a semver breaking change.

Fixes #101
@socsieng
Copy link
Collaborator

@tnguyen42, do you mind looking over #102?

@tnguyen42
Copy link
Author

@socsieng Sorry I didn't see your notification earlier, I actually looked at your PR from day 1 and I was waiting for it to be merged 😅
It looks good to me!

socsieng pushed a commit that referenced this issue Oct 1, 2021
The `onError` method signature is currently incorrect. This change will make it consistent with what is actually happening at runtime.

Note that this is a semver breaking change.

Fixes #101
@socsieng
Copy link
Collaborator

socsieng commented Oct 1, 2021

This should now be available in v3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants