Fixed invalid `CheckoutOpenBaseOptions['customData']` type

[divanc]

Hi! I've made this before I've read your contribution guidelines, so pardon my audacity.

Your CheckoutOpenBaseOptions['customData'] type is somewhat considerable, but it does not display the real interface of this hashmap. Since you decided to be specific about your custom data interface, it should either be expanded to match the reality or should be washed out like object.

After a bit of testing upon your sandbox server, I'm pretty sure, that your API accepts any encodable data, while the fundamental type is JSON-object. That means not only string or number like before, but also encodable objects, encodable arrays and nulls.

Consider this custom data:

Paddle.Checkout.open({
  items: [{ quantity: 1, priceId: "PRICE_ID" }],
  customData: {
    array: [1, 2, 3, [4, 5, 6]],
    bool: true,
    date: new Date(), // does not decode back, default JSON.parse behavior, thus excluded from type
    null: null,
    number: 500,
    object: { foo: "bar", baz: { null: null } },
    string: "Hello, GitHub!",
  },
});

Everything here is forwarded to "checkout.completed" event successfully, except date (which is expected)

Would you consider updating your type?

[vijayasingam-paddle]

Hi @divanc, Thank you for raising this pull request. Even though our contribution guide says that we do not accept contributions, we are more than happy to discuss changes to the library in the form of a pull request.

I agree that the type of customData is not correct and your suggestion makes very good sense.

We were looking into this and feel that the combinations in Encodable type is almost equal to calling it a any and IntelliSense in VS code and IntelliJ proves this by showing customData is of type Record<string, any> as it can accept any type value.

We feel that changing the type of customData from Record<string, string | number | boolean> to object will be the best solution here as both the solutions will offer similar results but an object will be easy to read when compared to all the types inferred from Encodable and users will anyways have to cast customData to a shape based on their usage with either solution.

We are going to close this PR and change the type of customData to object in a short while.

Again, thank you for the contribution. Please feel free to reach out to us with any feedback or questions.