July 2020 Summaries

Building robust React applications requires understanding client-side architecture basics. The Apollo Client plays a crucial role in managing state, networking, and data fetching concerns. A better client-side architecture starting point involves using CQS (Command Query Separation) and SoC (Separation of Concerns). Presentation components should render UI and create user events, while container components connect user events to the interaction layer. The interaction layer handles model behavior and shared component state. Apollo Client is a state management library that handles storage, updates, and reactivity, including remote and client-only local state. By understanding these principles and types of state, developers can design robust and maintainable React applications.

The Apollo Client Best Practices Series is a curated set of advice on how to use the Apollo Client library to build testable, flexible, and maintainable production applications. The series aims to help developers navigate state management and data fetching in client-apps, while also covering other important aspects such as architecture, testing, pagination, server-side rendering, and security. To get started, it is recommended to walk through the getting started guide, learn about queries and mutations, and then try out the full-stack tutorial before diving into the best practices guides, which include topics such as client-side architecture basics, local state management with reactive variables, cache normalization, refetch queries, and data access patterns.

The Apollo Client normalization algorithm works by splitting the response data into individual objects, assigning a unique identifier to each object, and storing them in a flattened JavaScript object. The cache can automatically update single existing entities in the cache after mutations if the mutation returns the new value in the response. However, for operations that do not return the entire set of changed items or updates to local state variables, we need to write an update function to tell the cache exactly how to update. Similarly, for additions and deletions, we also need to update the cache manually by filtering out or removing items from the existing query. The cache does not make assumptions about how you would like your collections/arrays of items to change after a mutation, so in these cases, we need to decide what the appropriate thing to do is and implement it in the update function of a mutation.

In Apollo Client 3, local state management enables view-layer components to subscribe to pieces of it, get notified when it changes, and re-render. This is achieved using cache policies and reactive variables. Cache policies are a way to customize reads and writes to the cache, allowing for the modeling of types and fields that might not exist as part of your data graph but do exist on the client-side. Reactive variables are containers for variables that we would like to enable cache reactivity for, providing a simple API to set or get values. By defining local state management, developers can build their entire app with local state, query it the same way they query remote data, and change it by importing it anywhere while maintaining a consistent fetching approach. Local state management is an important consideration in building client-side web apps, enabling better separation of concerns and improving code organization.

The Apollo Client 3.0 release is the culmination of 55 betas, 14 release candidates, and hundreds of resolved issues and merged pull requests over the past eleven months. This release introduces a single, consolidated `@apollo/client` package with entry points like `@apollo/client/utilities`, improved local state management, expanded and refined UI reactivity, and extensive internal refactoring. The cache-focused design philosophy behind Apollo Client informs just about everything that's included in this release, including new features such as reactive variables, field policies, pagination helpers, and more.