Endless scroll progressively loads more content as a reader reaches the bottom of a page. Instead of navigating to a separate results page, the interface requests the next slice of data and adds it to the current view. section 12.7
In an HTMX search page, the server still does the ordinary work: read search text, build the query, and select results. Pagination then limits each response to one page and supplies whether another page exists plus its page number. section 12.4
The request cycle has three moving parts:
- Query the matching objects, create a Django Paginator, and return only the current page’s objects. section 12.4
- Include a loading placeholder only when another page is available; its URL carries the next page and current search text. section 12.4
- Use hx-trigger="revealed" so the placeholder GETs more content when it scrolls onto the screen, then replace that placeholder with the returned fragment. section 12.4
- Render a partial for HTMX requests and the complete search page for ordinary requests, keeping direct page loads working. section 12.4
Searching musicians without a page button
A musician search first filters first and last names from the search_text query parameter. Each response contains one result page. At the bottom, a “Loading...” element requests page 2 when revealed; later pages repeat the same pattern until has_more is false. Creating many test musicians makes the behavior visible without needing a celebrity-filled database. section 12.4 section 12.7
Keep the search text in the next-page URL so later requests preserve the current filter. A deliberate delay on pages after the first can make loading behavior easier to observe during development, but it is not part of the pattern itself. section 12.4
Endless scroll works well alongside search-as-you-type: a changed keyup event can refresh the first result set, while the revealed marker fetches later result pages. The same arrangement can be practiced for ad content or separate musician and venue tabs. section 12.4 section 12.6
