New methods signature convention

[jeremybarbet]

To continue the discussion we started here, we are wondering how to refactor methods parameters, and deal with specific platforms props.

1. Flatten shared properties + objects for platform specific

requestSubscription({
  sku: 'com.example.inapp',
  ios: {
    andDangerouslyFinishTransactionAutomatically: false,
  },
  android: {
    purchaseToken: 'something-here'
  },
})

2. Only per-platform parameters

requestSubscription({
  ios: {
    sku: 'com.example.inapp',
    andDangerouslyFinishTransactionAutomatically: false,
  },
  android: {
    sku: 'com.example.inapp',
    purchaseToken: 'something-here'
  },
})

Another "issue" would be to deal with methods that take same argument, but either as a single value, or as an array. For example the following method:

• sku is a string for iOS
• sku is an array of string of Android

either:

requestPurchase({
  skus: ['com.example.inapp'], // will throw error on iOS when passing more than one sku
  ios: {
    andDangerouslyFinishTransactionAutomatically: false,
  },
  android: {
    purchaseToken: 'something-here'
  },
})

or

requestPurchase({
  ios: {
    sku: 'com.example.inapp',
    andDangerouslyFinishTransactionAutomatically: false,
  },
  android: {
    skus: ['com.example.inapp'],
    purchaseToken: 'something-here'
  },
})

@andresesfm also suggested something like this:

getProducts({ ios: IosRequest, android: PlayRequest, amazon: AmazonRequest } | SingleSkuRequest). 

Where SingleSkuRequest = Sku

But that would imho make validation more complicated to handle both type of signature and some overhead to adapt that on all methods.

The second question is how to name those platform specific-objects? The approach we like is to name them by their payment provider appStore, playStore, amazon?

To summarise, and to give my preference, I think the "nicest" approach would be the following:

requestSubscription example:

requestSubscription({
  sku: 'com.example.inapp',
  appStore: {
    andDangerouslyFinishTransactionAutomatically: false,
  },
  playStore: {
    purchaseToken: 'something-here'
  },
})

getProducts example:

getProducts({
  skus: ['com.example.inapp']
})

requestPurchase example:

requestPurchase({
  appStore: {
    sku: 'com.example.inapp',
    andDangerouslyFinishTransactionAutomatically: false,
  },
  playStore: {
    skus: ['com.example.inapp'],
    purchaseToken: 'something-here'
  },
  amazon: {
    sku: 'com.example.inapp',
  },
})

What do you folks think?

cc/ @andresesfm @hyochan

[andresesfm]

I think this the best option

requestSubscription({
  ios: {
    sku: 'com.example.inapp',
    andDangerouslyFinishTransactionAutomatically: false,
  },
  play: {
    skus: ['com.example.inapp'],
    purchaseToken: 'something-here'
  },
amazon:{
sku:"..."
}
})

Nicely separated, there are no common fields really other than sku between ios and amazon.

Here is my reasoning:

1. IOS with Storekit 2 has a radically different API design. Having independent objects will make it nice and clean
2. In this way we can remove the platform-specific suffixes in some parameters as purchaseTokenAndroid -> purchaseToken and andDangerouslyFinishTransactionAutomaticallyIOS -> andDangerouslyFinishTransactionAutomatically
3. We can export methods specific to a platform such as getReceiptIOS so that they can be imported from ios/iap
4. We can create a method similar to Platform.select that will call the proper method. This will greatly clean up the main file.

Let me know of your thoughs

[jeremybarbet]

Yep, looks good to me for splitting the sku/skus 👍

To be consistent I would rename either ios or play, because I don't think having one name by the OS platform and one by the payment provider is right. Imho, either ios, android, amazon or appstore, play, amazon, and in this case, I prefer the first approach

Edit: Thinking about it, would make more sense to have appstore, play and amazon. If for example in the future, we have another payment provider for ios we would need to rename ios to something else to follow the same convention as the one defined on Android

2. Yep, I agree, the goal is to remove all the suffixes in every method, because they are own by the platform object at first.

3/4. Correct! I already did that in here but I'm splitting the PR in smaller ones to make it easier to review