Provide more control on when queries are executed

[ZRunner]

I recently had an issue in my Flutter app where I realized that, in some situations, a GraphQL query could be executed dozens of times per second. It appeared to me that these executions were triggered by the reconstruction of the widget containing them, itself triggered by the appearance or disappearance of the keyboard (this is a well-known behavior with iOS, see also here).

While the dozens of rebuilds triggered by a keyboard change on iOS has been considered as a bug, and some work is being done to reduce the amount of rebuilds, the fact that a widget can be rebuilt up to 60 times per second (and 120 for some devices) is normal and expected. Many sources insist that the build method must be idempotent, i.e. it must not change anything in the state of the widget or make expensive calls or calculations. For example, retrieving data from an external API, or performing expensive calculations, can be done at widget initialization.

However, it seems to me (from my 2 months of learning Flutter and React Native) that this principle is not respected by this GraphQL library. If the cache strategy is set as "cache and network" or even "network only", the requests will be executed at each rebuild, up to 60 times per second.

So I would like a better way to control the execution of my GraphQL queries. For example with a specific cache method that will not make any network call if the cache version is less than X seconds/minutes old, or by allowing queries outside the build method.

If such a solution already exists, it would be interesting to highlight it in the library documentation.
But if it is technically impossible, I am very curious to try to understand why (since Flutter is the main subject of my current internship) and I would welcome any workaround to avoid having 200 requests in a few seconds.

[vincenzopalazzo]

Ok, let's make the point, that the bug is inside the flutter and not inside the library. If you rebuild the widget you have the behavior that the widget has for this use case.

We have different policies for that and you can check the docs https://github.com/zino-hofmann/graphql-flutter/tree/main/packages/graphql#direct-cache-access-api

If you are facing an error with the Flutter widget you can use the plain graphql client and implement your fetch logic as you want, and of the curse, any PR that improves the docs is considered asap and merged faster than other feature implementations.

BTW the issue that opened 27 days ago is not a well-known bug!

[ZRunner]

Thanks a lot for your explanations!
I managed to retrieve the client via the context.findAncestorStateOfType function (I don't know if this is the most efficient way?) in my widget's didChangeDependencies method, and handle my queries more finely (reading from the cache directly or making a query, whichever is more suitable). And from what I see, it works almost without problem.

To clarify your last remark, the fact that Flutter reloads the whole app a dozen times when the keyboard opens is indeed a bug, but the fact that on iOS the opening of the keyboard triggers the refresh of the MediaQuery (and thus of the app) is a normal and intended behavior, hence the "This is working as intended" in the linked comment!

Thanks again for answering me so quickly and clearly!

[vincenzopalazzo]

To clarify your last remark, the fact that Flutter reloads the whole app a dozen times when the keyboard opens is indeed a bug, but the fact that on iOS the opening of the keyboard triggers the refresh of the MediaQuery (and thus of the app) is a normal and intended behavior, hence the "This is working as intended" in the linked comment!

As my first sentences says, it is a bug, but your can not define a "well known" bug a issue that it is open 27 days a go! Bug fixing takes time! a well know bug is a bug for a issue open from one or two years, and it require other software to work with it.

My last sentences means, that I (and I think we) don't want patch this in the library (or the moment) because required a terrible hack in the code.

[vincenzopalazzo]

More important, I'm not who take the decision, so if you came up with a PR that implement the feature that you want, we are more that happy to review it and merge when it is ready to land.