You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the subgraph schema's solution to adding new types of scheme & proposal types requiring changing the base type (ControllerScheme & Proposal). This is because each derived type is added as a nullable field in the base type like so:
In order to query all Base entities, you'd have to form a query like so:
bases {
idbaseProptypeNamederivedA {
# All derivedA propssomeFieldA
}
derivedB {
# All derivedB propssomeFieldB
}
}
And in order to know what sub type each entity in the collection is (derivedA or derivedB) you have to check the typeName, then access the correct field that corresponds to that entity:
// Generate an array of fragments for each known typeconstfragments=[]for(constderivedofDerivedTypes){fragments.push(derived.Fields)}
queryBases {
bases {
__typenameidbaseProp # Can be generated from a list of known types # and appended to the query string, making this code # open for extension, closed for modification...onDerivedA {
DerivedAProps
}
...onDerivedB {
DerivedBProps
}
}
}
${fragments}
Then we can instantiate the different types from __typename:
newDerivedTypes[res.__typename]()
The text was updated successfully, but these errors were encountered:
Current Behavior
Currently, the subgraph schema's solution to adding new types of scheme & proposal types requiring changing the base type (
ControllerScheme
&Proposal
). This is because each derived type is added as a nullable field in the base type like so:In order to query all
Base
entities, you'd have to form a query like so:And in order to know what sub type each entity in the collection is (
derivedA
orderivedB
) you have to check the typeName, then access the correct field that corresponds to that entity:Opinion
Doing things this way is a "non-standard" way of implementing polymorphism in GraphQL. Here are two ways in which GraphQL supports polymorphic types: https://www.apollographql.com/docs/apollo-server/schema/unions-interfaces/
Unions make sense for when types don't have shared properties. Interfaces make sense for when types have shared "base" properties.
Proposal
Utilize GraphQL interfaces for both Proposal and Scheme types. Here's an example of what this would look like:
Then we can instantiate the different types from
__typename
:The text was updated successfully, but these errors were encountered: