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

Feature Request: Fields of nested fragments hidden in parent type #128

Open
baconcheese113 opened this issue Jul 19, 2022 · 1 comment
Open

Comments

@baconcheese113
Copy link
Contributor

From #123

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:

query HomeScreen {
  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
image

@FirdousNath
Copy link

So as of now is there any other way around ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants