Add Updating to Cells

[jtoar]

As of Apollo Client v3, the default fetchPolicy is cache-first. cache-first is great, but cache-and-network is better. Accordingly, it's what we default to. It comes with a hiccup though: cache-and-network gives you data if it's there (the "cache" part), then makes a GraphQL request to see if there's anything new ("and-network"). This means that the "result" Cells get (and use to figure out what to render) has data (usually an object/array) and loading = true. And if loading = true, that means Loading gets rendered. Because things go in order:

redwood/packages/web/src/components/createCell.tsx

Lines 128 to 146 in fbccb88

	if (error) {
	if (Failure) {
	return <Failure error={error} {...queryRest} {...props} />
	} else {
	throw error
	}
	} else if (loading) {
	return <Loading {...queryRest} {...props} />
	} else if (data) {
	if (typeof Empty !== 'undefined' && isEmpty(data)) {
	return <Empty {...queryRest} {...props} />
	} else {
	return <Success {...afterQuery(data)} {...queryRest} {...props} />
	}
	} else {
	throw new Error(
	'Cannot render cell: GraphQL success but `data` is null'
	)
	}

This is what it looks like: https://s.tape.sh/jf6jLX7u. I'm throttling the network so that you can really see Loading render. Near the end, you can see that the PostsPage (which has the PostsCell) displays Loading... even though there's data in the cache. (The other pages also display loading even though they have data too!)

Much in the same vein as #1878, this PR fixes this by providing an "Updating" state to Cells: https://s.tape.sh/YHPMztQO. The Loading states are gone. But there's a lot more details to consider:

• How do you opt out of this?
• If we're adding another state, we should really refactor the logic into a reducer; it's getting hard to keep track of how we get to each state. Cells are already state machines, is it time to use Xstate? We also don't need a library for state machines. But it seems like it's time to write one explicitly.
  • For instance, what happens when data's empty (which would render Empty) and loading = true?
• We talked about having Cells export another component, Updating, but will that cause the React tree to commit when it's swapping between Success and Updating and we'll end up with a terrible flash anyway? I.e., should Updating be a child of Success, so it just pops in and out?
• The way things are going, it seems like Cells might eventually look like the useAuth context, which provides an interface (logIn, signOut, etc.) that auth providers adapt themselves to.

Any and all feedback is welcome and appreciated!

[cannikin]

Thanks for this @jtoar! I don't have answers to any of those questions, I just want this merged right away so I can stop issuing refetchQueries all over the place to update queries that are already cached! I need and-network to do that for me!

[cannikin]

Oh damn I just added this to my app with patch-package and it seems to be working! Just added export const Updating = Success to my cells and everything works the way it's supposed to! Little tough to tell locally since everything renders so fast but I'm gonna deploy now to confirm.

[jtoar]

@cannikin Having to export const Updating = Success if there's no difference between the two seems like something we should remove the need for. There was discussion in Redwood Maker's about just and/or also passing a prop to Success (loading = true basically; or something else?). But lemme know how it goes!

[cannikin]

IT'S WORKING

[cannikin]

After this PR merges we should just release it as 1.0, this is all we need. THANKS @jtoar!!!!!!!

[cannikin]

@cannikin Having to export const Updating = Success if there's no difference between the two seems like something we should remove the need for. There was discussion in Redwood Maker's about just and/or also passing a prop to Success (loading = true basically; or something else?). But lemme know how it goes!

I'm so excited this is working I don't mind adding the Updating = Success line in there. haha As far as I remember we don't have anywhere else where we pass "hints" to Redwood for what to do with different components (like adding { loading: true } as an arg).

I'm not too grossed out about just generating cells with export const Updating = Success at the end with a single line comment explaining what it does (and a link to the docs with more in-depth explanation)... /cc @mojombo

[jtoar]

Here's another catch: does Apollo's refetch function (the one that comes from useQuery's return) cause loading to be set back to true?

No, not by default (https://www.apollographql.com/docs/react/data/queries/#inspecting-loading-states):

If you click the refetch button, you'll see that the component doesn't re-render until the new data arrives. What if we want to indicate to the user that we're refetching the photo?

The useQuery hook's result object provides fine-grained information about the status of the query via the networkStatus property. To take advantage of this information, we set the notifyOnNetworkStatusChange option to true so our query component re-renders while a refetch is in flight:

So we'd have to make our defaults:

 beforeQuery = (props) => ({ 
   variables: props, 
   fetchPolicy: 'cache-and-network', 
   nextFetchPolicy: 'cache-first', 
+  notifyOnNetworkStatusChange: true,
 }),

[peterp]

Just some feedback here about the code! This is such an awesome feature! Thanks for working on this @jtoar

[Tobbe]

This is how we do loading state for one of our cells. Sorry it's a long post, but I just wanted to show a loading state that's not just a small loading spinner or a simple overlay. And I hope this is a pattern that we can still support even with the new <Updating> component.

Showing scoring labels for 1 - 4

Then clicking + to configure the labels for scoring 1 - 5 we show this while it's fetching the labels from the DB

And when it's done loading we finally get this

The way I've implemented it is to reuse the <Success> component for my loading state as well, and then internally in <Success> detecting if we're loading or not

export const beforeQuery = (props) => {
  return { variables: props, fetchPolicy: 'cache-first' }
}

export const QUERY = gql`
  query ConfigureScoringLabelsQuery($topScore: Int!, $teamId: Int!) {
    defaultLabels: defaultScoreLabelsForTopScore(
      topScore: $topScore
      teamId: $teamId
    ) {
      id
      score
      label
    }
  }
`

export const Loading = ({ topScore, scoreLabels, setScoreLabels }) => (
  <Success
    topScore={topScore}
    scoreLabels={scoreLabels}
    setScoreLabels={setScoreLabels}
  />
)

export const Success = ({
  topScore,
  scoreLabels,
  setScoreLabels,
  defaultLabels,
}) => {
  const labels = scoreLabels[topScore]
  const isLoading = labels === undefined

  const setLabels = (labels) => {
    scoreLabels[topScore] = labels
    setScoreLabels({ ...scoreLabels })
  }

As you can see I use cache-first, and then, from there, I manage my own "cache" by storing the labels in context (that's what setScoreLabels do). This works out great for me, because the default labels I fetch from the DB never (super rarely) changes, so it's safe to just get them once.

And the inputs are just done like this:

<input
  type="text"
  value={isLoading ? 'Loading...' : labels[topScore - 1 - i].label}
  disabled={isLoading}
  onChange={(event) => {
    labels[topScore - 1 - i].label = event.target.value
    setLabels([...labels])
  }}
  className="w-full"
/>

[peterp]

This looks great, nicely done @jtoar

[jtoar]

@peterp I was about to merge this but I realized I'm not typing the updating prop (which is really just loading renamed); can you give it another look to confirm I did it correctly?

[peterp]

@jtoar That looks good to me, my only recommendation would be to add comments so that updating prop is explained.