-
Notifications
You must be signed in to change notification settings - Fork 52
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
[Paywalls V2] Adds support for fallback components #2064
Conversation
?: throw SerializationException("Can only deserialize PaywallComponent from JSON, got: ${decoder::class}") | ||
val json = jsonDecoder.decodeJsonElement().jsonObject | ||
return when (val type = json["type"]?.jsonPrimitive?.content) { | ||
"button" -> jsonDecoder.json.decodeFromString<ButtonComponent>(json.toString()) |
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.
Should we define the strings here in each individual component? We can have the PaywallComponent
interface have a "key" property to be implemented by each component, which would decrease the chances of us forgetting to add new components here (even if not make it impossible). We could also flip this when
and check for each component type "key" matches the one in the json, and if not return. That way we would have greater safety.
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 it! Let me noodle on it for a bit 😄
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 tried to play with a few options, but I don't think there's a good one. A key
property in the PaywallComponent
interface doesn't work, because we don't have an instance of the component here. The key
would have to be static / part of the component's companion object
, which is not enforceable.
There's the SerialDescriptor.serialName
field which we can match against, but that's still experimental.
Do you see another option?
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.
ohhh ok... Yeah I don't see many options either... I think this is ok then, we will just need to remember to update here with any new components.
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.
Yea indeed. We should be adding a deserialization test anyway in that case, which will fail, which will then point us in the direction of the custom serializer that we need to update.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2064 +/- ##
==========================================
- Coverage 81.35% 81.33% -0.03%
==========================================
Files 265 265
Lines 8690 8710 +20
Branches 1235 1241 +6
==========================================
+ Hits 7070 7084 +14
- Misses 1116 1118 +2
- Partials 504 508 +4 ☔ View full report in Codecov by Sentry. |
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 think my comment is not a blocker, in case you want to go ahead and do the change in a separate PR, so
Description
As the title says. Adds a custom serializer that looks for a
fallback
key if thetype
is unknown.This is the Android equivalent of RevenueCat/purchases-ios#4621.