[Paywalls V2] New overrides structure

[tonidero]

Motivation

Migrating overrides from a structured object to an array of override objects

Description

Previously

Overrides were a very structure object that had all of the different types of states/conditions that allowed base properties of a component to be overridden. However, this was not flexible when it came to multiple being activated as it was missing for cases when multiples types of conditions were being evaluated.

Now

Overrides is an array that has an array of conditions and properties. It will get applied in order from first to last IF all of the conditions are true.

This allows the FE/BE to determine the orders of overrides from lowest to higher priority so all of the SDKs/renderers don't need to duplicate that logic.

Android equivalent of RevenueCat/purchases-ios#4705

[tonidero]

I was a bit confused with this one... The backend right now returns an object with a type property but in iOS, we deserialize that directly to the Condition enum so I followed the same pattern... I'm not sure if we add more properties to that object, if we would be able to expose it with this API though...

[JayShortway]

We could automatically deserialize an object with only a type property if we make Condition sealed, and make its cases (Kotlin) objects instead of an enum. However, we would still need a custom serializer to handle the UNSUPPORTED case, so we wouldn't really gain anything in that respect haha.

As an example, TabControlComponent is a Kotlin object, because it's JSON is:

{ "type": "tab_control" }

Making Condition sealed now would maybe make it slightly easier to "migrate" (big word) if we ever add more properties to it. But we can also cross that bridge when we get there, as this is not public. I'd say whatever you prefer!

[tonidero]

I'm adding a test where a log gets called (when a condition is unknown). It was failing with the junit runner since it doesn't know the Log android class.

[codecov]

Codecov Report

Attention: Patch coverage is 80.64516% with 6 lines in your changes missing coverage. Please review.

Project coverage is 80.62%. Comparing base (424d477) to head (45d7416).
Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
...es/paywalls/components/common/ComponentOverride.kt	86.20%	2 Missing and 2 partials ⚠️
...at/purchases/paywalls/components/ImageComponent.kt	0.00%	1 Missing ⚠️
...cat/purchases/paywalls/components/TextComponent.kt	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2120      +/-   ##
==========================================
+ Coverage   80.60%   80.62%   +0.01%     
==========================================
  Files         273      273              
  Lines        9143     9166      +23     
  Branches     1287     1289       +2     
==========================================
+ Hits         7370     7390      +20     
- Misses       1232     1236       +4     
+ Partials      541      540       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JayShortway]

Very nice job! 💪 Just a comment on ignoring unknown JSON keys in condition, and some suggestions for tests.

[JayShortway]

We could automatically deserialize an object with only a type property if we make Condition sealed, and make its cases (Kotlin) objects instead of an enum. However, we would still need a custom serializer to handle the UNSUPPORTED case, so we wouldn't really gain anything in that respect haha.

As an example, TabControlComponent is a Kotlin object, because it's JSON is:

{ "type": "tab_control" }

Making Condition sealed now would maybe make it slightly easier to "migrate" (big word) if we ever add more properties to it. But we can also cross that bridge when we get there, as this is not public. I'd say whatever you prefer!

[JayShortway]

Good idea haha!