Table

Applied to a table container via <div data-ln-table id="..."> or <table>, ln-table operates in two distinct modes. In SSR mode, it indexes server-rendered <tbody> rows, intercepting ln-search, ln-filter, and ln-sort CustomEvents to toggle .hidden on <tr> elements or reorder rows in the DOM. In data-driven mode (data-ln-table-source="store"), it listens for ln-data-store:data events, clones <template data-ln-table-row>, populates cells via fill(), and mounts rendered rows into <tbody> with sliding-window virtual scrolling.

In web application design, data grids can often be pre-rendered completely on the server. In these scenarios, introducing a heavy client-side JSON-to-HTML template rendering pipeline is unnecessary overhead. The DOM already contains the correct HTML rows on initial load.

Instead of generating rows dynamically, ln-table parses existing DOM rows directly on paint. It layers ultra-fast, in-memory client-side sorting, column filtering, text searches, and virtual scroll on top of standard pre-rendered HTML, providing a fluid desktop-grid experience with zero database fetching overhead.

Three Orthogonal Layers of HTML Table Enhancements

1. The Pre-Rendered Markup (HTML DOM): Rows arrive completely rendered from the server. Cells can contain rich markup (links, pills, or custom badges) natively on initial paint.
2. The Visual Class Hooks (CSS State): Visual indicators (such as sort states or popover filters) are managed by standard CSS classes. The button markup contains static icons; CSS manages what is shown.
3. The Parsing Shell (ln-table): The script acts as an enhancement node. It scans cells, parses raw values (using optional data-ln-value attributes), manages in-memory sort orders, and hides rows dynamically using filter criteria.

How the Local Search and Sort Coherence Works

1. On load, the script parses every row, mapping text strings or custom data-ln-value targets into highly-optimized search and sort indexes in memory.
2. When a user types in a connected search bar (data-ln-search-for) or clicks a sort header (data-ln-sort), the component executes in-memory, local array filters instantly.
3. The component updates table rows in-place (toggling visibility or re-ordering nodes in the DOM). If the visible row count exceeds 200, it automatically activates virtual scrolling.

For the full guide see the ln-table README and the architecture reference.

When display text differs from the sort key:

<!-- Without: sorts by "1.250" (string) -->
<td>1.250</td>
 
<!-- With: sorts by 1250 (number) -->
<td data-ln-value="1250">1.250</td>
 
<!-- Date: sorts by Unix timestamp -->
<td data-ln-value="1700000000">15.11.2023</td>

Activates when filtered rows exceed 200. Renders only visible rows + 15 buffer rows above/below. Deactivates automatically when rows drop below threshold. Column widths are locked on first parse to prevent layout shifts.

If <tbody> is empty at init, a MutationObserver waits for rows to appear and parses them automatically.

// Manual init
window.lnTable(document.body);

// Instance
var el = document.querySelector('[data-ln-table]');
el.lnTable.destroy();   // remove listeners, virtual scroll, column locks