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
The generated types implement all the fragments that are spread under them, so all the fields from the fragments are suggested and valid for the parent query. I get that this is how graphql works, but it also makes it more difficult to keep track of what fields are defined for which widgets. In relay the fields defined in a fragment are specific to that component, and further nested fragments are for child components. I think they do this through putting the generated fragment types on the prototype for the parent fragment/query, I wonder if there's a way to achieve this with Dart?
Response
This would require us to create similar to a useFragment hook. I think it might be a good idea together with extracting the queries directly from Dart code, but ultimately it's a tradeoff between supporting graphql and graphql_flutter. So it is on my roadmap.
For a widget that needs to use the following query:
queryHomeScreen {
launches (limit: 150) {
id
}
...launchesTab_query
}
The widget using this query should have access to a class containing a launches type that only contains id and $$typename and it should be able to pass itself to a child widget that is looking for the fragment launchesTab_query type. Currently all fields of all nested fragments are shown for the parent types. As stated above, this can lead to a decoupling of widgets to the operation defined in the widget, and lead to harder to debug and refactor coding practices
The text was updated successfully, but these errors were encountered:
From #123
Response
For a widget that needs to use the following query:
The widget using this query should have access to a class containing a
launches
type that only containsid
and$$typename
and it should be able to pass itself to a child widget that is looking for thefragment launchesTab_query
type. Currently all fields of all nested fragments are shown for the parent types. As stated above, this can lead to a decoupling of widgets to the operation defined in the widget, and lead to harder to debug and refactor coding practicesThe text was updated successfully, but these errors were encountered: