Wishlist for 2.0
See original GitHub issueJust started using this library and noticed a few shortcomings that I would love to get fixed before 2.0 is out as stable:
- Remove
RNVersion
as parameter fromvalidateReceipt*
(just read this fromreact-native
or simply drop support for old versions) - Proper error handling
-
Add
code
property to all errors -
Let
prepare
throw an error when payments are disabled on iOSCurrently, this method is documented as 1) being a noop and 2) returning
Promise<void>
. The reality is that it returns the string “false” on iOS when payments aren’t enabled.I think it should return
Promise<void>
on iOS, but reject with an error (e.g.PAYMENTS_NOT_ENABLED
) when payments aren’t enabled. -
Let(better to have it just work on both platforms)validateReceiptIos
reject on Android (e.g.WRONG_PLATFORM
) -
Let
validateReceiptIos
reject instead of returning false and printing to console
-
- Fix
validateReceiptAndroid
(it always returnsfalse
for React Native >= 0.54) - Update documentation for
getProduct
andgetSubscription
to remove note about not making a difference with product/subscriptions (this have been fixed with a.filter()
in the code) - Possibly rename
prepare
andendConnection
to better match each other- e.g.
initConnection
/endConnection
orprepare
/teardown
or something else entirely
- e.g.
- Abstract away the different types on iOS/Android (e.g.
inapp
vsiap
), just make sure thattype
is the same on both platforms. - Abstract away the differences between
price
/localizedPrice
on iOS/Android- Currently
price
is localized on Android, but not on iOS - Would like to change so that
price
is anumber
, andlocalizedPrice
isstring
- Currently
Most of these changes are breaking changes which is why I would love to get them in before final 2.0.
I would be happy to submit pull requests for all of the items above 🌻 😎
Issue Analytics
- State:
- Created 5 years ago
- Reactions:5
- Comments:13 (10 by maintainers)
@marcosmartinez7 I would recommend opening a separate issue for that. The idea with this issue was to track what breaking changes we wanted to get in. I’m guessing that adding that would be backwards compatible ☺️
@dooboolab do you want to merge #235 and #238, and tag a new alpha? Would love to get those changes in ☺️
Or do you want to accumulate all the changes in one big release? I personally prefer keeping incremental, but I’m fine either way 👍