React-native-iap: 警告来自purchaseErrorListener的可能的未处理的承诺拒绝

创建于 2019-09-04  ·  4评论  ·  资料来源: dooboolab/react-native-iap

版本的react-native-iap

3.0.3

本机版本

0.59.10

您遇到错误的平台(IOS或Android还是两者兼有?)

安卓

预期行为

没有未处理的承诺警告

实际行为

09-03 16:42:41.214 20367 21085 I ReactNativeJS: 'purchaseErrorListener', { debugMessage: '', responseCode: 1 }
09-03 16:42:43.254 20367 21085 W ReactNativeJS: Possible Unhandled Promise Rejection (id: 0):
09-03 16:42:43.254 20367 21085 W ReactNativeJS: Error: Payment is Cancelled.
09-03 16:42:43.254 20367 21085 W ReactNativeJS: createErrorFromErrorData<strong i="14">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2108:26
09-03 16:42:43.254 20367 21085 W ReactNativeJS: http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2060:51
09-03 16:42:43.254 20367 21085 W ReactNativeJS: __invokeCallback<strong i="15">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2627:23
09-03 16:42:43.254 20367 21085 W ReactNativeJS: http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2358:34
09-03 16:42:43.254 20367 21085 W ReactNativeJS: __guard<strong i="16">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2531:15
09-03 16:42:43.254 20367 21085 W ReactNativeJS: invokeCallbackAndReturnFlushedQueue<strong i="17">@http</strong>://localhost:8081/index.delta?platform=android&dev=true&minify=false:2357:21
09-03 16:42:43.254 20367 21085 W ReactNativeJS: invokeCallbackAndReturnFlushedQueue@[native code]

经过测试的环境(仿真器?真实设备?)

真实设备

重现行为的步骤

在3.0.x分支上构建示例应用程序。 在设备上运行,触摸Get Products ,然后触摸Purchase android.test.canceled

🙏 help wanted 🚶🏻 stale 🤖 android

最有用的评论

据我了解,它是由于以下这一行而发生的: https :

我不明白为什么在触发错误事件后会调用此函数。 似乎这里使用了两种方法的组合。

新的诺言将在每次初始化时创建,然后根据操作结果以及通过DeviceEventManagerModule发送事件来解决或拒绝。

但是据我从文档中了解到,与库进行通信的唯一方法是通过事件,现在不赞成使用promises。

也许我没有得到正确的信息,但是从我的角度来看,该库在发送错误事件时不应拒绝承诺。

@hyochan还有其他想法吗? 我准备贡献自己的力量,只是想了解我正在朝着正确的方向前进。

所有4条评论

据我了解,它是由于以下这一行而发生的: https :

我不明白为什么在触发错误事件后会调用此函数。 似乎这里使用了两种方法的组合。

新的诺言将在每次初始化时创建,然后根据操作结果以及通过DeviceEventManagerModule发送事件来解决或拒绝。

但是据我从文档中了解到,与库进行通信的唯一方法是通过事件,现在不赞成使用promises。

也许我没有得到正确的信息,但是从我的角度来看,该库在发送错误事件时不应拒绝承诺。

@hyochan还有其他想法吗? 我准备贡献自己的力量,只是想了解我正在朝着正确的方向前进。

@gaykov你是对的。 似乎这对支持eventpromises都是一种副作用。 希望您的PR 🔨有所改善

嘿,看来这个问题最近没有任何活动。 问题是否已解决,还是仍然需要社区的关注? 如果没有其他活动发生,则可能会关闭此问题。 您也可以将此问题标记为“供讨论”或“良好的第一期”,我将其保留为开放状态。 感谢你的贡献。

长时间不活动后结束此问题。 如果此问题在最新版本中仍然存在,请随时创建具有最新信息的新问题。

此页面是否有帮助?
0 / 5 - 0 等级