AI Catalog Mount Point and Apollo Cache Merging for Pagination
TL;DR
- AI catalog mounts at the JSAI catalog ID via query selector, with Rails creating the element and injecting backend data through Haml.
- Data is pulled from the element’s dataset, a router is created on the index path, and a view Apollo instance is set up with the default client.
- Agent 3430 recently added a cache config to merge paginated query.projects results used in a dropdown.
- The merge logic checks pagination arguments and combines existing cached nodes with incoming nodes so results aren’t refetched.
- This also allowed dropping a deprecated update query callback in the single select dropdown.
Tracing the mount point and Apollo caching logic
At the mount point, under AI catalog index.js, the application is mounted at the JSAI catalog ID via query selector. Rails creates and mounts the element, injecting backend data into it via Haml; that data is then pulled from the element’s dataset. From there, a router is created on the index path, and a view Apollo instance is created with the default client. In the last few weeks, Agent 3430 implemented a cache config so that the default client merges paginated query.projects results in the cache, which lets the single select dropdown drop a deprecated update query callback. Replacing on first page fetches avoids duplicating refs under cache and network. The merge logic works against the projects field’s search, membership, min access level, search namespaces, and sort arguments: it checks whether there are results after the current page (since we’re paginating) and returns the incoming results in that case; otherwise, it merges the existing cached nodes with the incoming nodes so we don’t refetch data we already have.
ryer.io