Your First Page

Vite apps (dispatch, responder, caller): Next.js apps (docs, beacon): The page owns the request, so it is the query root: the only component on the screen that calls useQuery. It selects id on each incident, which Apollo needs to key the list and find the entity again, and spreads the fragment of the component it renders. The query doesn't list title, status or priority. Those fields belong to the list item, which you write in the next step. IncidentListItem declares the fields it renders in a fragment named Component_prop, in a fragments.graphql next to it. Run pnpm codegen after you save the file. The component takes a FragmentType prop, not the incident object, and opens it with useFragment. useFragment reads from the cache and makes no request. Always pass fragmentName: it keeps working when someone later adds a ...Child spread to the fragment. With data masking on, the page can't read incident.title: it is a type error, and undefined at runtime. If the list item later needs another field, you add it to the fragment and nothing else changes. See GraphQL Fragments for the rules. To test IncidentListItem on its own, see Testing a Fragment-Owning Component on Its Own. The details page is its own route, so it is its own query root and selects the fields it shows directly. Both queries sit in the pages folder's queries.graphql. If the details page grows child components, each one gets its own fragment, exactly as IncidentListItem did. For interactivity, use Client Components: The page keeps the query and the mutation. IncidentListItem still takes its data as a FragmentType and reads it with useFragment. The onUpdate callback is a plain prop that you add to the component's props next to incident. Use Box props or co-located SCSS: Wrap pages in error boundaries: For more detailed technical guidance, see these reference files: