Graphql-flutter: Query Does not update after mutation on a pushed screen

Created on 26 Oct 2018  路  5Comments  路  Source: zino-app/graphql-flutter

bug
Describe the bug
I have a profile page where each item is rendered with Query but the edit button takes to a new Screen Where a mutation is successfully executed to update the value. but once this screen is poped the older screen query does not hit server rather it re renders older values. How can I tell the query to refresh from server.

Expected behavior
I expect the query to be updated after the mutation is ran either through api or cache or the developer has power to invoke , is there any example that I can look ,which solves this problem.
Screenshots
https://gfycat.com/FoolhardyShamelessBubblefish

Smartphone (please complete the following information):

  • Device: [e.g. iPhone6]
  • OS: [e.g. iOS8.1]
  • Version [e.g. 22]

Additional context
The values are updated if I do a hard reload

question

Most helpful comment

I found the issue is in the Query Widget, Should comment The lines 67 and 69 in the Function didUpdateWidget, I think that we must always regenerate the widget.

 void didUpdateWidget(Query oldWidget) {
    super.didUpdateWidget(oldWidget);

    // if (!observableQuery.options.areEqualTo(_options)) {
      _initQuery();
    // }
  }

All 5 comments

@vmwsree When you pop a screen the old screen does not get re-rendered thus the query does not get refetched. We are looking to add a refetch option the the query, but right now you can fix it by polling the query.

Option 2 -- which is a bit more complex - is to put all the data in question into a ScopedModel and use a ScopedModelDescendt in the main list screen and populate the screen from that (obviously use the Query to build the data) .. then in the Edit/Add screen update the data that's in the ScopedModel .. this should cause an update to the List since ScopedModelDescrendent is reactive on changes within it..

In reality you could maybe cheat -- and just have some "trigger" in ScopedModel that is used within the build() of the List .. and have the Edit/Add screen update the trigger .. which should (?) cause the build() below ScopedModelDescendent to run agian.. if your Query is below him .. it should retrigger the query .. of course you'll need to make sure you have a Fetchoption of either NetworkOnly or CacheNetwork for it to actually show ..??

Just some random ideas..

I found the issue is in the Query Widget, Should comment The lines 67 and 69 in the Function didUpdateWidget, I think that we must always regenerate the widget.

 void didUpdateWidget(Query oldWidget) {
    super.didUpdateWidget(oldWidget);

    // if (!observableQuery.options.areEqualTo(_options)) {
      _initQuery();
    // }
  }

I found the issue is in the Query Widget, Should comment The lines 67 and 69 in the Function didUpdateWidget, I think that we must always regenerate the widget.

 void didUpdateWidget(Query oldWidget) {
    super.didUpdateWidget(oldWidget);

    // if (!observableQuery.options.areEqualTo(_options)) {
      _initQuery();
    // }
  }

This is kind resource-wasteful, I think.
It would be better to have the queries subscribe to the cache and have the cache notify queries of changes.
I'm not sure how to do it in Dart, though. (Dart noob here)

199 adds/leverages rebroadcastQueries, which will solve this problem.

This is similar enough to #190 that I'm going to close in favor of that one

Was this page helpful?
0 / 5 - 0 ratings