[wip] shift to optimistic updates

[avimoondra]

No description provided.

[avimoondra]

subscribe this way, then can use optimistic response instead of local states.

related to: apollographql/apollo-client#5267

[avimoondra]

some interesting behavior here - some flashes on refresh, and two web sockets get opened.

starting to think sub might be overkill for this whole thing, we could prob do with 1 sec polling.

[namoscato]

Yeah, I ran into this same thing recently and landed on the same GitHub issue / solution; it worked well.

You're resubscribing a bunch in the current state and missing an updateQuery which might help:

Suggested change

	React.useEffect(() => {
	return subscribeToMore({
	variables: {
	joinCode: props.joinCode,
	},
	document: CurrentGameSubDocument,
	})
	}, [data?.games[0]])
	React.useEffect(() => {
	return subscribeToMore({
	variables: {
	joinCode: props.joinCode,
	},
	document: CurrentGameSubDocument,
	updateQuery: (data, { subscriptionData }) => {
	return subscriptionData.data || data
	},
	})
	}, [props.joinCode])

The subscription and query are the same in this context, so updateQuery is dead simple, but it gives you the flexibility to deviate from the query (i.e. only make some things realtime, subscribe to a handful of smaller subscriptions, etc).

[avimoondra]

Yea - I was meaning to check if updateQuery defaults to exactly that if not passed in - but will add it explicitly to see the effect.

I also thought direction of flexibility was 👍 e.g... we are subscribing for everything once game is started. But practically... the most settings, players and cards cannot change after the game has started, so based on the game state we could actually run different subscriptions (so long as we close out the previous gracefully).

[namoscato]

I was meaning to check if updateQuery defaults to exactly that if not passed in

It seems like it doesn't on glance, but I'm not sure how it would have been working without it now if that's the case 🤔

based on the game state we could actually run different subscriptions

Yeah, love that.

[avimoondra]

stop using local state

[namoscato]

Yeah, I ran into this same thing recently and landed on the same GitHub issue / solution; it worked well.

You're resubscribing a bunch in the current state and missing an updateQuery which might help:

Suggested change

	React.useEffect(() => {
	return subscribeToMore({
	variables: {
	joinCode: props.joinCode,
	},
	document: CurrentGameSubDocument,
	})
	}, [data?.games[0]])
	React.useEffect(() => {
	return subscribeToMore({
	variables: {
	joinCode: props.joinCode,
	},
	document: CurrentGameSubDocument,
	updateQuery: (data, { subscriptionData }) => {
	return subscriptionData.data || data
	},
	})
	}, [props.joinCode])

The subscription and query are the same in this context, so updateQuery is dead simple, but it gives you the flexibility to deviate from the query (i.e. only make some things realtime, subscribe to a handful of smaller subscriptions, etc).

[namoscato]

I wonder if two fragments would help / minimize the scope of these setting cache updates, i.e.

1. fragment GameSettings on games with the (base) UpdateGameSettings properties

2. a full fragment that "extends" from that one:

   fragment Game on games {
       ...GameSettings
       state
       (etc)

   with the rest of the CurrentGame properties

[avimoondra]

Most definitely 👍 - there's no use of fragments across this whole codebase yet! Bout damn time.