Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Refactor
presentedOfferingIdentifier
intopresentedOfferingContext
object #1612Refactor
presentedOfferingIdentifier
intopresentedOfferingContext
object #1612Changes from 1 commit
953a39d
4f00efe
b5a2653
9eaf8a4
ed49688
a38dff4
6855a71
9b6e897
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I made the
presentedOfferingContext
have a nullableofferingIdentifier
instead of making thepresentedOfferingContext
nullable in StoreProduct/SubscriptionOption in case we could have non-offering related context, which is probably not the case right now... But this forces us to default to something here as a fallback. It should never be null right now though in thePackage
.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.
I like this! I think this makes sense 👍
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.
hmm I think it makes sense for
StoreProduct/SubscriptionOption
, but with this there's no way to indicate that a package will always have an offering and a package is always going to have an offering. Do we need to replaceoffering
inPackage
withpresentedOfferingContext
? I think we can leave this as isoffering: String
and only replacepresentedOfferingIdentifier
inStoreProduct
andSubscriptionOption
? We access thepresentedOfferingContext
through the products, and not the packages.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.
Hmm it's a good point... the only difference is going to be that the offering is not nullable in the Package... However, It feels nicer to me if we have the same format in all 3 places... If we don't have this data at the
Package
level we will need to access it through the StoreProduct when purchasing, which seems slightly less clean...What do you think about leaving the offering property undeprecated here in the Package? It would be duplicated with the one in
presentedOfferingContext
but that way we can keep the non-nullability hereThere 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.
I guess my question is if we need a
presentedOfferingContext
at all inPackage
. Is it ever going to be different than theoffering
value? I guess we can add a different way of getting Packages in the future, which would indeed make offering not nullable and create the need of apresentedOfferingContext
, but maybe we can add that property whenever we need. I just think adding it right now makes the API confusing and doesn't add value. Maybe I am missing contextThere 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.
Actually... What if we make it a sealed class that only has an implementation right now? That way we can keep the original nullabilities. Can you remind me what other type of data we are adding to the
PresentedOfferingContext
?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.
@joshdholtz I was chatting live with @vegaro about this one... In the end, we believe it would be better to make the
offeringIdentifier
not nullable inside thePresentedOfferingContext
so we can make thePresentedOfferingContext
not nullable inPackage
but nullable inStoreProduct
/SubscriptionOption
. Do you think we will (now or in the future) have data like this without having an offering id?My original reason to make it nullable was to provide more flexibility in the future in case we have some of this data without an offering id, but I don't think that would happen for now at least, so it makes sense to better reflect the current model.
Let us know what you think!
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.
Addressed in 9eaf8a4