Add support for multi-level Expand feature #1140
Conversation
All options class now have the ability to pass a list of properties to expand. Until then, we had to add the ExpandXXXX property to the service and it only supported one level. One downside is that this could cause crashes if you're on a version of the library that does not expand a specific property to be expandable.
|
Nice! I'm happy to add this to the library, however I wonder if we should make this the "official" way of expanding attributes as it makes the developer responsible for passing proper expandable values. That said, we do the same thing in stripe-go, and I'm really not sure what the interface would look like if we wanted to add support for multi-level expansions in a type-safe manner. cc @brandur-stripe @fred-stripe @anelder-stripe in case you have any thoughts on this topic. |
|
@ob-stripe part of the reason I added was that I discovered that our library had multiple bugs already. In the other PR you can see that some services had the I could not come up with a viable way to support multi-level expansion without this unless we explicitly added things like |
Oh, definitely. I was thinking it would be neat to have something like That would likely be significantly more complex to implement though, so probably not worth the effort. In the meantime, this PR solves a common pain point for stripe-dotnet users, so I'm going to pull this in. |
All options classes now have the ability to pass a list of properties to expand. Until then, we had to add the
ExpandXXXXproperty to the service and it only supported one level.One downside is that this could cause crashes if you're on a version of the library that does not support/expect a specific property to be expandable.
The way I added this means that it is not a breaking change and both versions are supported. It would likely be best to remove the old way afterwards (or in this PR) to avoid conflicts though.
r? @ob-stripe
cc @stripe/api-libraries