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
Comments
Thanks for reporting this. I think the actual problem here is that in some cases In any case, the function onError(error: Error | google.payments.api.PaymentsError) {} This would mean that if you needed access to 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? |
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
@tnguyen42, do you mind looking over #102? |
@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 😅 |
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
This should now be available in v3 |
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)
orconsole.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-objectsHowever, the expected type in this package (
@google-pay/button-react/dist/index.d.ts
, line 33) expects the standardError
from TypeScript, which doesn't have thestatusCode
andstatusMessage
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
andstatusMessage
properties.My suggestion would be to define an interface just above the
Config
interface:And using it instead of
Error
in theConfig
interface:The text was updated successfully, but these errors were encountered: