Expandable Objects about stripe-kit HOT 8 CLOSED

@Buratti I love the idea of using property wrappers. And you're in the same vein of how I was thinking of implementing it with a StripeExpandable protocol etc. We can dive a bit more into it when you get a chance.

from stripe-kit.

@anthonycastelli @ksmandersen thoughts on this approach?

from stripe-kit.

I’m all for it. Right now Stripe and Vapor still aren’t at a full official release so a breaking change isn’t a big deal right now. I like the idea of incorporating property wrappers this way too. My only question is what is the benefit of doing this?

from stripe-kit.

I like this approach.

My main concern with expandable objects is the difference in types. E.g if you don’t expand the latestInvoice on Subscription it is String? if you do expand it becomes a Invoice?. The key in the json is the same.

from stripe-kit.

@ksmandersen Actually this is a tough one. I'm working on a way to get around this now.

from stripe-kit.

@ksmandersen that's one of the reason beyond property wrappers. If you decide to not expand latestInvoice you are still able to access its id property as a string using the projected value ($latestInvoice.id).

There might be a smarter solution though. A couple of days ago Andrew and I were discussing on Discord about the "multi type" problem. The default source of a user can be a Card object but it might also be another type of payment method. The current approach would not be able to handle this situation.

A different solution might be to have

@Expandable
var defaultSource: String?

If we always keep String as the wrapped value we can project some other object. The projected object will be responsible to decode the expanded object as the user request.
For example:

customer.defaultSource // "card_1234" <- not source breaking, the wrapped value will always be the object id or nil if no defaultSource exists.
customer.$defaultSource.decoded(as: StripeCard.self)?.last4 // "4242" if the expanded object was a Card, nil if it was a different form of Payment Method.

This solution is a bit uglier from a syntax point of view but with Swift 5.2 we can improve from

customer.$defaultSource.decoded(as: StripeCard.self)?.last4

to

customer.$defaultSource(as: StripeCard.self)?.last4

which is not so bad.

from stripe-kit.

Regarding the same key problem, you can find a custom implementation of init(from decoder: Decoder) throws here
If the object is not expanded, the key for latestInvoice will map to a single value container which will contain a string. If the object is expanded, the key will map to a keyed container keyed by StripeCard.CodingKeys.self.
Therefor, if the object is expanded String.init(from: decoder) will fail and if the object is not expanded StripeCard.init(from: decoder) will fail.

from stripe-kit.

This was implemented in #72

from stripe-kit.