Response Type Casting

[popwarfour]

Summary

Not sure if this is a bug or an awkward implementation. The scenario is you have two instances of the same top-level type (BlockA and BlockB are both Collection). These Collection types differ based on an inner dataSource field which are (DataSourceA on DataA and DataSourceB on DataB). These are two separate incompatible types in the schema yet when I inspect the query response it seemly has trouble parsing them.

Example scenario,

# ----- Experienece Query  -----

query MyQuery {
  ... BlockA
  ... BlockB
}


# ---- Block A -----

fragment BlockA on Collection {
    dataSource {
        ... DataSourceA
    }
}

fragment DataSourceA on DataA {
    fieldA
}

# ---- Block B -----

fragment BlockB on CoreListingCollection {
    dataSource {
        ... DataSourceB
    }
}

fragment DataSourceB on DataB {
    fieldB
} 

Now if we try to parse them as seen below we will see it always falls in the first if even for BlockB. Again, the schemas are completely different and incompatible yet somehow BlockB was given to me as data.asCollection?.fragments.blockA. If I check the data.asCollection?.fragments.blockA.dataSource field its at least properly nil. But again, I'm not sure if this is a bug or if the API is just extremely loose with its approach to "casting" but in any event it puts, in my opinion, an unnecessary burden of checking types squarely on your shoulders.

if let blockA = data.asCollection?.fragments.blockA {
    // Do A specific things - We always fall in here!
} else if let blockB = data.asCollection?.fragments.blockB != nil {
    // Do B specific things
}

The work around is for us to perform an extra check on the inner dataSource ourselves like so,

if let blockA = data.asCollection?.fragments.blockA, blockA.dataSource?.asDataSourceA != nil {
    // Do A specific things
}

Version

1.7.0

Steps to reproduce the behavior

See summary

Logs

N/A

Anything else?

No response

[AnthonyMDev]

The work around is for us to perform an extra check on the inner dataSource ourselves like so,

if let blockA = data.asCollection?.fragments.blockA, blockA.dataSource?.asDataSourceA != nil {
   // Do A specific things
}

This is the right way to handle this. It's not a workaround. The blockA fragment is not optional, it will always exist. The asDataSourceA field is where the question of "does dataSourceA exist" is answered.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.