Skip to content

Refactor Apollo cache updates to be immutable in Design Management

Natalia Tepluhina requested to merge 196857-refactor-apollo-cache-updates-to-be-immutable-in-design-management-application into master

Summary

In Apollo 2.6 a few new options were provided (namely, assumeImmutableResults, freezeResults, and returnPartialData) for rendering components faster and more smoothly.

While Apollo Client cannot mandate immutable data processing for all application code that consumes cache results, it can reward us for writing our code in an immutable style. In Apollo Client 2.6, if we’re confident that the application code does not modify cache result objects, we can unlock substantial performance improvements by communicating this assumption to the ApolloClient constructor via passing assumeImmutableResults: true. So far we don't have a lot of mutations in GitLab's codebase but our usage of GraphQL is growing and it's better to leverage the immutability now, rather than rewrite updates later.

More to say, in Apollo Client 3.0, authors intend to make both freezeResults and assumeImmutableResults true by default (meaning we would need to make this work to upgrade anyway).

Improvements

We can gain slight performance improvements right now (considering the fact we have just a few mutations) and we can stick to this 'more performant' strategy while our GraphQL codebase grows.

Risks

There are no significant risks as the updates logic won't change: the result is going to be the same

myArray.push(1)
// the code below will provide the same result
myArray = [...myArray, 1]

However, we need to be careful when enabling assumeImmutableResults and freezeResults and check with console errors that we really have an immutable update. Otherwise the UI won't update.

Involved components

ee/app/assets/javascripts/design_management/utils/cache_update.js

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Source issue: #196857 (closed)

Edited by 🤖 GitLab Bot 🤖

Merge request reports