Adapting DocLister Display Count to Viewport Changes

A catalog may look balanced on one screen width and awkward on another. A classic example is a DocLister grid rendered with a fixed &display value such as 16. On some widths the final row looks incomplete and the catalog feels visually broken.

The core limitation

&display is calculated on the server before the browser knows the final client width. That means one hardcoded number cannot perfectly match every viewport.

Good ways to handle it

• use a CSS grid or flex layout that gracefully wraps uneven rows
• change the requested page size through AJAX when the viewport changes
• choose a display count that matches your most important breakpoints

When AJAX makes sense

If the listing is already loaded through AJAX, the front end can detect the viewport and request a different &display value for desktop, tablet, and mobile states.

const width = window.innerWidth;
const display = width >= 1200 ? 16 : width >= 768 ? 12 : 8;

When CSS is the better answer

If you only care about the final row looking neat, modern grid styles are often simpler than changing the server-side page size. A responsive grid can make the same set of items feel natural without requerying the server.

In other words, if the problem is visual balance, start with CSS. If the problem is performance or paging logic, then it may be worth changing the DocLister request itself.