Response fragments

A search result, a page of a list, a counter: a part of a page that the browser wants to refresh on its own. {fragment 'name'}...{/fragment} names such a part. A normal request renders the whole page, the fragment in its place:

<h4>Orders</h4>

{fragment 'order-list'}
  <ul>
    {sequence '101..103', name='number'}<li>Order {$number}</li>{/sequence}
  </ul>
{/fragment}

<p>The page goes on here.</p>

A request that adds &padFragment=order-list to the URL gets that fragment and nothing else - the same template serves the full page and the update:

{curl 'SELF://manual/?fragments/response_fragments_1&padInclude&padFragment=order-list'}

How it works

• The page renders up to the end of the fragment, and the fragment's rendering - closing pipe included - is the whole response. What comes after it is not rendered at all.
• The response is bare, like a padInclude request: no wrapper, no tidy.
• The first fragment of that name to finish rendering is the one sent. Keep a fragment unconditional and put conditions inside it: a request for a fragment that never rendered is an error under the strict check, and an empty 404 otherwise.
• The page's PHP may decide too: $padFragmentOnly = 'order-list'; - for instance when the request carries an HX-Request header.

With ajax and HTMX

• {ajax 'orders', fragment='order-list'} fetches only that fragment of the page into its div.
• HTMX: <div hx-get="?orders&padFragment=order-list" hx-trigger="every 5s"> swaps in the fresh list.
• An HTMX request needs no padFragment when it swaps an element named like the fragment: hx-target="#order-list" sends HX-Target: order-list, and a page with a fragment of that name answers it alone. A page without one renders whole, as it would otherwise. See Htmx.