-
Notifications
You must be signed in to change notification settings - Fork 572
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix deserialization logic for polymorphic types #1396
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some minor feedback but that looks great to me.
7333a74
to
d8c06a2
Compare
d8c06a2
to
4640ae6
Compare
Hey Brandur, mind taking a look at this one? I know you haven't been too involved in stripe-dotnet recently, but I'd like to get as many eyes as possible on this PR. Let me know if you have any questions or need more context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay @ob-stripe! This looks like a huge improvement to me.
I'd be temped to just add a couple basic tests for the new Util
class and method, especially for the logic in GetConcreteType
at the bottom, but other than that this looks great to me!
4640ae6
to
04da400
Compare
04da400
to
a9a1aec
Compare
a9a1aec
to
83879f5
Compare
I've renamed Pulling this in! |
r? @remi-stripe @talljoe-stripe
cc @stripe/api-libraries
Fixes the deserialization logic to properly handle polymorphic types, i.e. properties that are declared with an interface as their type rather than a concrete class.
Summary of changes:
Stripe.Infrastructure.Util
class that contains:object
values to concrete types, e.g."charge" => typeof(Stripe.Charge)
GetConcreteType()
method that accepts a "potential type" and anobject
value:object
value to find the matching concrete type, and return it (if it's compatible with the interface)AbstractStripeObjectConverter
,BalanceTransactionSourceConverter
,ExternalAccountConverter
,PaymentSourceConverter
andStripeObjectConverter
are all goneStripeObjectConverter
deserializer (same name, but completely different logic) that usesUtil.GetConcreteType()
to figure out which concrete type to instantiate and populateEventData.Object
), which ensures that the class can be deserialized withJsonConvert.DeserializeObject()
ItemConverterType
forStripeList.Data
so thatStripeList
can be used with interfaces (e.g.StripeList<IPaymentSource>
onCustomer
)StringOrObject
class used for expandable fields also usesUtil.GetConcreteType()
to decide which type to pass toJObject.ToObject()
for deserializationStripe.Mapper
now exposesSerializerSettings
property that can be customized by users. Default settings are:StripeObjectConverter
deserializer everywhere (which ensures that interfaces can always be deserialized)Test changes:
JsonConvert.DeserializeObject<>
instead ofMapper<>.MapFromJson
wherever possible (i.e. when the type is not an interface)IHasObject
have an entry in theUtil.ObjectsToTypes
dictionary