Shared Constants for Row Limit Options

The allowed row limit values are defined in two places:

• PivotToolbar.svelte (UI options): [5, 10, 25, 50, 100, "all"]
• convertURLToExplorePreset.ts (URL validation): [5, 10, 25, 50, 100]

If these drift out of sync, users could set a limit via the UI that gets rejected when loaded from a URL. Consider extracting these to a shared constant, perhaps in types.ts or a new pivot-constants.ts file.

Extract Limit Calculation Logic

The new limit calculation in pivot-data-store.ts:298-315 is correct, but it's added to an already deeply nested section of createPivotDataStore. This makes the code harder to follow. Consider extracting this into a helper function, along these lines:

function calculateEffectiveRowLimit(
  rowLimit: number | undefined,
  rowOffset: number,
  pageSize: number,
): string {
  if (rowLimit === undefined) {
    return pageSize.toString();
  }
  const remainingRows = rowLimit - rowOffset;
  if (remainingRows <= 0) {
    return "0";
  }
  return Math.min(remainingRows, pageSize).toString();
}

This will make the intent clearer and keep the main function from growing further. More broadly, createPivotDataStore has become difficult to maintain due to its size and nesting depth. We should revisit this in the future to improve readability.

Expanded Row Limit Behavior

In pivot-expansion.ts:284-287:

const expandLimitToApply =
  config.pivot.rowLimit !== undefined
    ? config.pivot.rowLimit.toString()
    : "100";

When "All" is selected, expanded sections still cap at 100 rows. This might surprise users who expect "All" to mean unlimited everywhere. If this is intentional, it would be worth documenting. If not, consider whether expanded rows should also be unlimited when rowLimit is undefined.

Test Coverage Required

Before merging, please add test coverage for:

• URL round-trip: setting a limit produces the correct row_limit param, and loading that URL restores the correct state
• Edge cases in convertURLToExplorePreset.ts: invalid values, out-of-range numbers, non-numeric strings

Developed in collaboration with Claude Code

Is the intention to limit the top level dimension as well? Currently even that is limited (based on the query sent)

Approving, though see below for a few observations on complexity

Feels weird to look at top level dimensions with limit applying to them as well. Do we need "Load more" button there as well? Also lets update the PRD to make sure everyone is on the same page (it still states the limit is only for nested dimensions). cc @nishantmonu51 @mindspank

Also Increase limit to <new limit> on <dimension> feels a bit too verbose. How about just load more or load more for <dimension>?