Remove freezeResults option, assuming always true.

[benjamn]

This option was first added in Apollo Client 2.6, as a way to help enforce immutability of cache results: #4514

As promised in the Apollo Client 2.6 blog post, all cache results will be frozen/immutable in the next major version (3.0):

In Apollo Client 3.0, we intend to make both freezeResults and assumeImmutableResults true by default, in addition to using the TypeScript Readonly<T> type to discourage destructive modifications. In other words, if you embrace immutability now, you won’t have to do anything when it becomes mandatory.

I have not yet removed the assumeImmutableResults option from the ApolloClient constructor, since cache implementations other than apollo-cache-inmemory might not return immutable results.

[hwillson]

Looks great @benjamn - exciting! 🎉

[jbaxleyiii]

I'm really glad we are doing this, but I do wonder if we can prune more of the freezing behavior to be part of the dev only build? There are a couple call sites to maybeDeepFreeze that get turned into a noop in production but wouldn't it be better to just prune that all together in prod?

[benjamn]

@jbaxleyiii There's one spot that I see in apollo-cache-inmemory/src/readFromStore.ts:

if (process.env.NODE_ENV !== 'production') {
  assertSelectionSetForIdValue(contextValue.store, field, readStoreResult.result);
  maybeDeepFreeze(readStoreResult);
}

As you can see, it's wrapped with a process.env.NODE_ENV check, so the call to maybeDeepFreeze will get stripped in production if folks are properly dead-code-eliminating those blocks, as React requires them to do.

However, that guard does not remove the import { maybeDeepFreeze } from 'apollo-utilities', which is a general problem with top-level import declarations. The good news is that apollo-cache-inmemory/lib/bundle.cjs.min.js does not end up containing maybeDeepFreeze, so it is possible to remove it completely from that bundle, though some version of it might still end up remaining in the apollo-utilities bundle, depending on how folks set up their production builds.

I think this situation will improve once we move the relevant apollo-utilities code into the new @apollo/client package, so Rollup has more insight into exactly which functions are used. In the meantime, I think I'm comfortable with leaving this one call to maybeDeepFreeze in place, since it's used to freeze scalar values, which might be objects or arrays.

[benjamn]

@jbaxleyiii Thanks to your comment I realized this clone is necessary to avoid accidentally freezing user-provided scalar values in development, as I'm now testing in af94014.

[benjamn]

Merging this preemptively so that @hwillson can begin work on restructuring the repo starting from the release-3.0 branch.