It looks strange but I hand to unwind AndroidVisualNotificationPayloadBase here to make AndroidVisualNotification work. For some reason without unwinding flow would complain that AndroidVisualNotification doesn't have fields that it clearly has.

Soon we will modify this to enforce either senderDeviceID or keyserverID. Not just keyserverID.

For some reason if I used keyserver directly flow would think that it is void | string even with the invariant above.

I don't think this structure makes sense anymore. If you're just adding a single +id?: string, to all of them, why not inline it?

Perhaps if you inline +id?: string,, can you re-integrate AndroidVisualNotificationPayloadBase?

And finally, does adding $ReadOnly wrappers fix the "unwinding" issue? Remember that read-only status is wiped when spreading a type, so it has to be re-applied at the new type, eg.:

type SpreadType = { +something: string };
type OtherType = $ReadOnly<{
  ...SpreadType,
  +blah: string,
}>

If you don't include $ReadOnly there, then something will not be read-only.

We discussed this in our 1:1 and I was not able to reproduce the issues @marcin had which forced him to the take the "unwinding" approach here. We can return this to using a type spread of AndroidVisualNotificationPayloadBase: https://gist.github.com/Ashoat/bcb8778735d721eecea0f0ffbdfd2447

This is explained in diff summary. senderDeviceID will not suffice because of older clients that expect keyservervID. Introducing union in type is faster than implementing migrations and checks against code versions. It is an object only as a type. Later in the code it will be spread so that notification have a single string as a key in their payload.

Without the second if flow complains as follows:

Cannot return object literal because in type argument  `R` [1]: Either property `badgeOnly` is missing in  object type [2] but exists in  object literal [3] in property `data`. Or property `badge` is missing in  object type [2] but exists in  object literal [3] in property `data`. Or property `rescind` is missing in  object type [4] but exists in  object literal [3] in property `data`. Or property `badge` is missing in  object type [4] but exists in  object literal [3] in property `data`.Flow(incompatible-return)

Looks like it cannot determine if I am returning correct type or some mixture of fields from both types of the union.