{% load brickwork_components brickwork_icons i18n %}
{% comment %}
Data table: STRUCTURE ONLY (BR-BW-TPL-005, never virtualisation/AG-Grid). It
renders columns with server-side sortable headers, rows with STABLE per-row ids
(BR-BW-HTMX-005, so a consumer's hx-target can address a row), an empty state at
exactly zero rows (STA-001), and a loading skeleton (STA-004). Sort/filter/
paginate are server-driven: the view computes the order and passes the current
sort; a header link carries the sort param, no client-side sorting.

Two shapes, selected by ``variant``:

- ``variant="records"`` (default): a columnar table of same-shaped records.
    columns: a list of dicts: {label, sortable(bool), sort_key(str)}. For a
             SORTABLE column supply ``sortable=True`` and ``sort_key`` (the base
             ascending order key, e.g. "name"); the template derives the
             descending key ("-name") and the next-click toggle itself from
             ``sort_key`` + the shared ``current_sort``, so a consumer does NOT
             compute ``sort_key_desc`` / ``next_sort`` (#23). Those two keys may
             still be passed to override the convention, but are optional.
    rows:    a list of dicts: {id, cells: [rendered strings], url(optional),
             selected(optional bool)}
             A row with a ``url`` becomes a clickable row: its first cell is
             an anchor to ``url`` (the whole row is keyboard-reachable via that
             link), so a documented per-row link actually renders (#10).
             A row with truthy ``selected`` carries the
             ``bw-data-table__row--selected`` class (the selected-row styling
             hook, e.g. the row a bulk action or detail pane refers to).
- ``variant="definition"``: a key/value fact table for ONE entity (a detail
    screen's "facts about this thing", the <dl>-shaped case, #18). No column
    headers, no sorting.
    rows: a list of dicts: {label, value} (each row is one fact). ``columns``
          is ignored. The label is a row header (``<th scope="row">``), so the
          table is semantically a definition table, not a fake two-column grid.

Required context:
  table_id: the stable id for the table container (an hx-swap target).
  rows:     as above, by variant.
  columns:  required for ``records``, ignored for ``definition``.
Optional:
  variant ("records" default | "definition"), loading (bool),
  current_sort (str, e.g. "name" or "-name"), empty_heading, empty_body,
  querystring, selectable (bool, records only, see below), scroll_container /
  sticky_header (bool, either name, see below), responsive
  ("scroll" default | "stack", see below).

--- Bulk selection (brickwork#54, records variant only) --------------------

selectable=True adds a leading checkbox column. THE SELECTION CONTRACT (the
load-bearing part, #47: "must live in brickwork or every consumer reinvents
it"): every row checkbox is a plain native
``<input type="checkbox" name="selected" value="{{ row.id }}">``. It carries
NO form of its own (BR-BW-TPL-005: structure only); it relies on sitting
inside a ``<form>`` THE CONSUMER OWNS (e.g. wrapping this include, or wrapping
the whole patterns/list.html list_body block). The no-JS floor is a normal
multi-value POST: a consumer's view reads the selection with
``request.POST.getlist("selected")``, exactly what a plain HTML checkbox
group has always given you, zero JS required. A "select all" checkbox
appears in the header; it carries an accessible name and gets
JS-progressive-enhanced (below) but works as a plain unchecked box with no
JS (it does not natively check every row without Alpine, which is why the
bulk-actions bar - see _bulk_actions_bar.html - documents pairing it with a
"select all" fallback link for the true no-JS case). Every checkbox has a
visually-hidden accessible label ("Select row" / "Select all rows"), never a
bare unlabelled control (WCAG 4.1.2).

Enhanced (optional, opt-in by wrapping the table AND the bulk-actions bar in
one ``x-data="bwTableSelection()"`` root, see
components/_bulk_actions_bar.html's docstring for the full wiring): the
``bwTableSelection`` Alpine component reads the checkboxes as the SOLE source
of truth (it holds no separate selection store that could desync from what
will actually submit), toggles the header checkbox's indeterminate state, and
reveals the bulk-actions bar with a live selected-count.

scroll_container / sticky_header (CSS only, either name works, both wire the
same treatment): sticky_header=True pins the <thead> (position: sticky) while
the wrap scrolls, so long lists keep their column headers in view.

responsive ("scroll" default | "stack"): "scroll" is the existing horizontal
overflow (no change). "stack" additionally stamps each <td> with
data-label="<column label>" (read from ``columns`` by position via the
``list_item`` filter, BR-BW-TPL-005: no data reshaping, just a positional
read) so a narrow-viewport CSS rule can render each row as a labelled card.
{% endcomment %}
<div id="{{ table_id|default:'bw-data-table' }}" class="bw-data-table-wrap{% if scroll_container or sticky_header %} bw-data-table-wrap--sticky{% endif %}{% if responsive == "stack" %} bw-data-table-wrap--stack{% endif %}">
  {% if loading %}
    <div class="bw-data-table__skeleton" aria-hidden="true">
      {% for _ in "xxxxx" %}<div class="bw-skeleton bw-skeleton--row"></div>{% endfor %}
    </div>
  {% elif not rows %}
    {% include "brickwork/components/_empty_state.html" with variant="no_data" heading=empty_heading|default:"" body=empty_body|default:"" %}
  {% elif variant == "definition" %}
    <table class="bw-data-table bw-data-table--definition">
      <tbody>
        {% for row in rows %}
          <tr class="bw-data-table__row">
            <th scope="row" class="bw-data-table__th bw-data-table__th--label">{{ row.label }}</th>
            <td class="bw-data-table__td">{{ row.value }}</td>
          </tr>
        {% endfor %}
      </tbody>
    </table>
  {% else %}
    <table class="bw-data-table{% if responsive == "stack" %} bw-data-table--stack{% endif %}">
      <thead>
        <tr>
          {% if selectable %}
            {% comment %}
            #54: the header "select all" checkbox. Bare native checkbox, no
            name/value of its own (it never submits a value; only the
            per-row boxes it drives do): a no-JS user still gets a working,
            individually-labelled checkbox per row, just not the one-click
            select-all convenience. bwTableSelection (see the component
            docstring above) wires :indeterminate and the click-to-toggle-all
            behaviour once Alpine is present.
            {% endcomment %}
            <th scope="col" class="bw-data-table__th bw-data-table__th--select">
              <label class="bw-visually-hidden" for="{{ table_id|default:'bw-data-table' }}-select-all">{% translate "Select all rows" %}</label>
              <input type="checkbox" class="bw-checkbox"
                     id="{{ table_id|default:'bw-data-table' }}-select-all"
                     data-bw-select-all
                     aria-label="{% translate 'Select all rows' %}">
            </th>
          {% endif %}
          {% for col in columns %}
            {% comment %}
            #23: the consumer supplies only ``sort_key`` and the shared
            ``current_sort``. The descending key and the next-click toggle are
            derived here: desc is ``-<sort_key>`` (Django ordering convention);
            the header link toggles asc->desc when this column is the current
            ascending sort, else lands on ascending. A consumer MAY still pass an
            explicit ``sort_key_desc`` / ``next_sort`` to override the convention
            (back-compatible), but neither is required any more.

            #41: the sort link preserves the other GET params and drops ``page``
            (a re-sort resets to page one). When ``request`` is in context (the
            view/pattern path) the built-in ``{% querystring %}`` tag owns the
            split, so the consumer no longer hand-builds a sort-only
            ``querystring`` distinct from pagination's. Standalone renders with
            no request fall back to the documented ``querystring`` var, so the
            component's request-free render contract is unchanged.
            {% endcomment %}
            <th scope="col" class="bw-data-table__th{% if col.sortable %} bw-data-table__th--sortable{% endif %}"
                {% if col.sortable and current_sort == col.sort_key %}aria-sort="ascending"{% elif col.sortable and current_sort|slice:"1:" == col.sort_key and current_sort|slice:":1" == "-" %}aria-sort="descending"{% endif %}>
              {% if col.sortable %}
                {% if current_sort == col.sort_key %}
                  {# currently ascending on this column -> next click sorts descending #}
                  <a class="bw-data-table__sort" href="{% if request %}{% with desc="-"|add:col.sort_key %}{% querystring sort=desc page=None %}{% endwith %}{% else %}?sort=-{{ col.sort_key }}{% if querystring %}&{{ querystring }}{% endif %}{% endif %}">
                    {{ col.label }}{% bw_icon "arrow-up" size="sm" decorative=True %}
                  </a>
                {% elif current_sort|slice:"1:" == col.sort_key and current_sort|slice:":1" == "-" %}
                  {# currently descending -> next click sorts ascending #}
                  <a class="bw-data-table__sort" href="{% if request %}{% querystring sort=col.sort_key page=None %}{% else %}?sort={{ col.sort_key }}{% if querystring %}&{{ querystring }}{% endif %}{% endif %}">
                    {{ col.label }}{% bw_icon "arrow-down" size="sm" decorative=True %}
                  </a>
                {% else %}
                  {# not the current sort -> first click sorts ascending #}
                  <a class="bw-data-table__sort" href="{% if request %}{% querystring sort=col.next_sort|default:col.sort_key page=None %}{% else %}?sort={{ col.next_sort|default:col.sort_key }}{% if querystring %}&{{ querystring }}{% endif %}{% endif %}">
                    {{ col.label }}{% bw_icon "sort" size="sm" decorative=True css_class="bw-data-table__sort-idle" %}
                  </a>
                {% endif %}
              {% else %}
                {{ col.label }}
              {% endif %}
            </th>
          {% endfor %}
        </tr>
      </thead>
      <tbody>
        {% for row in rows %}
          <tr id="{{ table_id|default:'bw-data-table' }}-row-{{ row.id }}" class="bw-data-table__row{% if row.url %} bw-data-table__row--linked{% endif %}{% if row.selected %} bw-data-table__row--selected{% endif %}">
            {% if selectable %}
              {% comment %}
              #54: the selection contract. name="selected" value="{{ row.id }}"
              is the WHOLE contract; a consumer's view reads
              request.POST.getlist("selected") against whatever <form> wraps
              this table. data-bw-row-select marks it for bwTableSelection's
              count/indeterminate wiring; absent Alpine it is just a checkbox.
              {% endcomment %}
              <td class="bw-data-table__td bw-data-table__td--select">
                <label class="bw-visually-hidden" for="{{ table_id|default:'bw-data-table' }}-row-{{ row.id }}-select">{% blocktranslate with row_id=row.id %}Select row {{ row_id }}{% endblocktranslate %}</label>
                <input type="checkbox" class="bw-checkbox" name="selected" value="{{ row.id }}"
                       id="{{ table_id|default:'bw-data-table' }}-row-{{ row.id }}-select"
                       data-bw-row-select>
              </td>
            {% endif %}
            {% for cell in row.cells %}
              {% with col=columns|list_item:forloop.counter0 %}
              <td class="bw-data-table__td"{% if responsive == "stack" %} data-label="{{ col.label }}"{% endif %}>{% if row.url and forloop.first %}<a class="bw-data-table__row-link" href="{{ row.url }}">{{ cell }}</a>{% else %}{{ cell }}{% endif %}</td>
              {% endwith %}
            {% endfor %}
          </tr>
        {% endfor %}
      </tbody>
    </table>
  {% endif %}
</div>