Skip to content
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

Response Type Casting #3294

Closed
popwarfour opened this issue Nov 28, 2023 · 2 comments
Closed

Response Type Casting #3294

popwarfour opened this issue Nov 28, 2023 · 2 comments
Labels
bug Generally incorrect behavior needs investigation

Comments

@popwarfour
Copy link

popwarfour commented Nov 28, 2023

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

@popwarfour popwarfour added bug Generally incorrect behavior needs investigation labels Nov 28, 2023
@AnthonyMDev
Copy link
Contributor

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.

Copy link
Contributor

github-actions bot commented Mar 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Generally incorrect behavior needs investigation
Projects
None yet
Development

No branches or pull requests

2 participants