Wait until data got changed and refresh widgets before returning to previous screens

[adzialocha]

This PR makes sure that users directly see newly created or updated data when they return to the previous screen.

The trick is to wait for the pushed screen to return (after a "pop" event) and look up a global dirty flag (RefreshProvider) if the user has created or updated something. If they did, we force a re-load and re-render of the widget which might need to display this update.

On top we're waiting until the document got actually materialized on the node before we return back to the "All Sightings" screen.

Context

The underlying issue was actually not that we didn't wait enough before data got materialized on the node, but that when calling "pop" on the navigator stack it'll return back to a "cached" state of the widgets. That makes sense for performance reason obviously but we need to force-trigger a refresh to make sure the changes are visible.

There's a way to hook into a "pop" callback from the perspective of the screen which pushed the next view on the stack. We can then trigger a re-render there, how this is done depends a bit on the widget but I've made it work.

On top I've made it more "lazy", aka, not trigger a re-render every time we return from somewhere (also bad UX, you don't want to unnecessarily jump in scroll position after returning). To understand if something has changed I've introduced a global state provider where we can keep track of "dirty" flags.

Todo

• Refresh All Sightings List after creating a new Sighting
• Refresh All Sightings List after updating a Sighting
• Refresh All Species List after changing a Species
• Refresh All Uses + All Local Name Widgets after changing a sighting
• Only refresh when data actually has been changed

Closes: #19

[adzialocha]

Looking at this bug here right now, am I'm doing something wrong? Any ideas @sandreae?

{
  status: all_bee_sighting_0020df662f01bd4eed879ebb2128edd3e0b55902f179eeaf8978e58011f96b488717(
    meta: {
      viewId: "00206a52968297bafbd2824218ebe8da3174a432c57083ed81b073f3621d1165f7e5"
    }
  ) {
    totalCount
  }
}

And I receive

{
  "data": null,
  "errors": [
    {
      "message": "internal: not an object",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ]
    }
  ]
}

The error occurs as soon as I add the "meta" field in the arguments.

[sandreae]

Think you need:

{
  status: all_bee_sighting_0020df662f01bd4eed879ebb2128edd3e0b55902f179eeaf8978e58011f96b488717(
    meta: {
      viewId: { eq: "00206a52968297bafbd2824218ebe8da3174a432c57083ed81b073f3621d1165f7e5" }
    }
  ) {
    totalCount
  }
}

[adzialocha]

Think you need:

{
  status: all_bee_sighting_0020df662f01bd4eed879ebb2128edd3e0b55902f179eeaf8978e58011f96b488717(
    meta: {
      viewId: { eq: "00206a52968297bafbd2824218ebe8da3174a432c57083ed81b073f3621d1165f7e5" }
    }
  ) {
    totalCount
  }
}

Aaaaaaah! Haha, should have read our documentation 🥴 Thank you!

[sandreae]

This looks and works great to me. Nice pattern and much better UX to have new sightings showing up straight away.

[sandreae]

Very nice pattern 😄

[adzialocha]

I hope thats irony 😝

[sandreae]

I mean, kind of, we needed a fix for it and this isn't a bad one 👍