They are shown when you run the tests. Until then they appear as a hidden requirement.
Build a user search with infinite scroll: the list loads more users when you reach its end, and typing a search starts it again. You practice effects that depend on several values, their cleanup, and pagination state that has to stay coherent.
Loading... status and the messages at the end.fetchUsers({ query, page }) in api.js: it returns a promise with { users, hasMore }, 10 users per page, and pages start at 1. It also accepts a signal from an AbortController. In the preview it answers after a random delay, like a real network.<Sentinel onVisible={fn} /> in Sentinel.jsx: an invisible element that calls fn every time it scrolls into view. It is already at the end of the list, and it stays there while a page loads.api.js nor Sentinel.jsx show in the editor: you only change App.jsx.aria-label="Search users", the texts Loading..., No more users and No users found, and the role="status": the tests use them.1 of the empty search and shows Loading... in the element with role="status" until the answer arrives.hasMore: false, it stops requesting pages and shows No more users, or No users found if the search found nobody.1 of the new search.Loading..., then the first 10 users.Loading... below the list, then 10 more users after them.an → the list empties and shows the first users whose name contains an.Keep in state what you want (the search and the page) and request the data in an effect that depends on both.
Answers can arrive late. What should happen to an answer for a search the user already changed?
If the user scrolls up and down while a page loads, the Sentinel calls onVisible again. Ask for a new page only when the last one you asked for has arrived.
The console is empty
Run your code with Ctrl+S
This console starts empty every time the preview loads. The browser's DevTools console keeps the messages with Preserve log.