fix(reader): load all pasals SSR for structured (BAB-based) laws

[daffaromero]

Problem

Structured laws like UU Cipta Kerja (186 pasals, multiple BABs) showed empty sections after the first ~30 pasals. The page uses BAB-first rendering — each chapter filters allPasals by parent_id. When only 30 pasals were loaded SSR, all BABs beyond the first few had no matching pasals and rendered empty.

Root cause: usePagination was set whenever totalPasalCount >= 100, regardless of whether the law had a BAB structure. When usePagination = true, only the initial 30 pasals are fetched SSR and the rest are loaded client-side via infinite scroll — but client-side infinite scroll appends pasals to a flat list, it never fills in the per-BAB allPasals.filter(p => p.parent_id === bab.id) logic.

Fix

Two commits:

1. b9c067f — Skip client pagination when the law has structural nodes (BABs, aturan, lampiran); always fetch the full pasal set SSR. Flat laws (no BABs) with 100+ pasals still use infinite scroll.

2. 0939875 — Broaden the check from hasBABs (only tested bab/aturan/lampiran) to hasStructure = structure.length > 0, which covers all node types that trigger the tree-rendering path (including bagian and paragraf). Aligns the pagination guard directly with the babNodes.length > 0 rendering condition.

How it works

// Before (broken):
const usePagination = (totalPasalCount || 0) >= 100;

// After (fixed):
const hasStructure = (structure || []).length > 0;
const usePagination = (totalPasalCount || 0) >= 100 && !hasStructure;

structure is already fetched in the initial parallel query — zero additional DB round-trips for the check itself. For structured laws, the existing SSR "fetch remaining" branch now runs unconditionally, fetching all pasals in a single work_id-scoped indexed query.

Impact

• Structured laws (UU Cipta Kerja, etc.): All pasals now render under their correct BABs
• Flat laws with 100+ pasals: Behavior unchanged — still use infinite scroll
• Flat laws with <100 pasals: Behavior unchanged — still fully fetched SSR

Co-authored-by: Claude noreply@anthropic.com

[daffaromero]

Root Cause Analysis

There were two related issues, both in LawReaderSection in apps/web/src/app/[locale]/peraturan/[type]/[slug]/page.tsx.

---

Root Cause 1: Pagination mode ignores document structure

The page has two rendering strategies:

1. Paginated (infinite scroll): Fetch only the first 30 pasals SSR; a client component (PasalList) loads the rest on demand and appends them to a flat list.
2. Full SSR: Fetch all pasals server-side before rendering.

The strategy was chosen by a single flag:

const usePagination = (totalPasalCount || 0) >= 100;

This kicked in for any law with 100+ pasals — including structured ones like UU Cipta Kerja (186 pasals, many BABs).

The problem is that structured laws don't use a flat list renderer. They use a BAB-first tree renderer: the code maps over babNodes (chapters), and for each BAB filters the full allPasals array by parent_id:

babNodes.map((bab) => {
  const directPasals = allPasals.filter((p) => p.parent_id === bab.id);
  const nestedPasals = allPasals.filter((p) => subSectionIds.has(p.parent_id ?? -1));
  // renders directPasals + nestedPasals under this BAB...
})

When pagination mode is on, allPasals only contains the first 30 pasals at render time. For UU Cipta Kerja, those 30 pasals might all fall under BAB I or BAB II. BABs III through XVII get allBabPasals = [] and render as empty sections. The client-side infinite scroll does eventually load the rest, but it appends to the PasalList component — it never backfills the per-BAB filter above, because that filter runs once SSR and the result is static HTML.

In short: the paginator and the BAB renderer operate on the same data array but at different points in the lifecycle. Pagination assumed a flat list; the BAB renderer assumed the full set. The assumption was never reconciled.

---

Root Cause 2: The initial fix used an incomplete structural check

The first commit fixed this by introducing hasBABs:

const hasBABs = (structure || []).some(
  (n) => n.node_type === "bab" || n.node_type === "aturan" || n.node_type === "lampiran",
);
const usePagination = (totalPasalCount || 0) >= 100 && !hasBABs;

This works for UU Cipta Kerja and most Indonesian laws. However, the BAB rendering path actually fires on any structural node (babNodes.length > 0), and the structure query fetches five node types: bab, aturan, bagian, paragraf, lampiran. The check only covers three of them.

A law structured with only bagian (section) or paragraf nodes and 100+ pasals would still hit the original bug — hasBABs would be false, pagination would be enabled, but babNodes.length > 0 would still route to the tree renderer with an incomplete allPasals.

The second commit tightens this to:

const hasStructure = (structure || []).length > 0;
const usePagination = (totalPasalCount || 0) >= 100 && !hasStructure;

This aligns the pagination guard exactly with the rendering condition, so they can never disagree regardless of which node types are present.

---

Why it wasn't caught earlier

The bug is invisible for most laws:

• Laws with <100 pasals always fetched everything SSR, regardless of structure — no bug.
• Flat laws (no BABs) with 100+ pasals used infinite scroll correctly — the flat renderer just appends, no structural mismatch.
• Only large structured laws hit the intersection where both conditions were true simultaneously.

UU Cipta Kerja is one of the few laws that is both large enough (186 pasals) and has a deep BAB/Bagian structure, making it the natural test case to expose this.

[daffaromero]

Here is the fix in action @ilhamfp: