Fixes issue with network-only and cache-and-network fetchPolicy being changed about apollo-link-state

[jbaxleyiii]

➤ meteor-bot commented:

@mhuggins: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[jbaxleyiii]

➤ James Baxley commented:

@mhuggins the desired behavior for SSR is to fetch the first time, then to read from the cache during the second loop when creating the components. Since react-apollo uses a two round render on the server, it is important to not send queries (force-fetch) the second time around

[jbaxleyiii]

➤ Matt Huggins commented:

@jbaxleyiii By using cache on the server, every subsequent request has stale data since the underlying DB may be updating regularly while the apollo cache maintains an older version. How do you make the cache bust between requests?

[jbaxleyiii]

➤ milanvdmria commented:

@jbaxleyiii It mainly doesn't make sense when you are also using Apollo to validate some user input. The user enters a certain product, the front end logic changes based on the fact if that product already exists yes or no.
If the caching strategy is forced, the check will always be performed on the very first product the user wants to add and all the consequent products are never correctly checked.

As mentioned in the PR, this forced caching strategy is causing unexpected behavior and issues for quite some people without adding extra value. What could possibly be the advantage of taking away some configuration options from the user?

[jbaxleyiii]

➤ Mateusz Bagiński commented:

@mhuggins @milanvdmria ping

[jbaxleyiii]

➤ Matt Huggins commented:

Not sure why I'm being pinged.

[jbaxleyiii]

➤ Mateusz Bagiński commented:

Any changes?

[jbaxleyiii]

➤ Matt Huggins commented:

My recommended change is in this PR.

[jbaxleyiii]

➤ Kay Sackey commented:

@jbaxleyiii Typically the client/server implementations will diverge quite a bit during the setup-phase of the app by necessity.

Even, React itself doesn't have an identical API for rendering on the server, versus attaching to the DOM.

Accordingly, I think the best practice would be creating a server-side apollo client without caching, and a client-side apollo client with caching. Having the option being forced without warning was a bit surprising, especially since the vanilla client doesn't do this.