Skip to content

docs: small multiples can split by two dimensions - #11523

Open
igorlukanin wants to merge 1 commit into
masterfrom
igor/cub-3620-docs-small-multiples-second-axis
Open

docs: small multiples can split by two dimensions#11523
igorlukanin wants to merge 1 commit into
masterfrom
igor/cub-3620-docs-small-multiples-second-axis

Conversation

@igorlukanin

Copy link
Copy Markdown
Member

Small multiples can now split a chart by two dimensions — one across the columns and one down the rows — so the page's "One split dimension" limitation no longer holds.

  • Documents the second picker and the round trip back to a single split axis.
  • The Grid control's two numbers are described as what they now mean on both shapes: the most tiles each axis may draw. With one split dimension they shape the grid and their product bounds it; with two, each caps its own axis, so a five-value and a forty-value dimension still draw twenty-five panels rather than two hundred.
  • Notes that each axis drops its own overflow in that axis's sort order.

This also carries the 5 × 5 grid maximum correction from #11498, so the two agree wherever they overlap. Depends on the UI change shipping first.

@igorlukanin
igorlukanin requested a review from keydunov as a code owner August 11, 2026 09:57
@mintlify

mintlify Bot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
cubed3 🟢 Ready View Preview Aug 11, 2026, 9:57 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

@claude

claude Bot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Claude finished @igorlukanin's task in 1m 12s —— View job


Docs review — 0 high, 2 medium, 2 low

Docs-only change; the second-axis story reads well and the 5 × 5 correction is applied consistently. Two internal contradictions worth fixing before merge (both posted inline), plus two nits below.

Full review
  • Read PR diff against origin/master
  • Read the full page for internal consistency
  • Check sibling pages for stale cross-references
  • Post findings

Medium

1. small-multiples.mdx:18 — "single row of panels" contradicts the page (inline)
Line 16 says one split dimension gives one panel per value, and the Grid row says a four-value dimension opens as a 2 × 2 grid — so a single dimension wraps across both axes. Clearing the second picker therefore returns you to that behaviour, not to a one-row layout.

2. small-multiples.mdx:28 — Grid cell fights itself, and "the split dimension" is now ambiguous (inline)
The lead-in ("the most tiles each axis may draw") states the two-dimension reading, then the following sentence carves out a different single-dimension reading. A neutral gloss ("Columns × rows, up to 5 × 5") lets the distinction land. Separately, with two pickers filled it's unclear which dimension drives the 2 × 2 preselection.

Low

3. small-multiples.mdx:24 and :30 — singular "dimension" left un-updated.
"These options appear once a Split by dimension is chosen" and "Orders the panels by the dimension's own values" both predate the second axis. The Sort panels by row in particular raises a real question the page doesn't answer: with two split dimensions, does one sort setting apply to both axes? Line 49 ("Each axis drops its own overflow in that order") implies yes — a clause in the table row would save the reader the inference.

4. Legacy duplicate not touched — correct, but worth confirming intent.
docs/explore-analyze/charts/configuration/small-multiples.mdx (the deprecated Nextra site) still carries the old text. Per CLAUDE.md that site is deprecated and shouldn't be edited, so leaving it is right; noting it only so the divergence isn't a surprise later.

Verified fine

  • 5 × 5 / twenty-five is consistent at lines 28, 43, and 45 — no leftover 5 × 4 or "twenty panels" anywhere in docs-mintlify.
  • The 5 × 40 → 25-panels example is arithmetically right under per-axis caps.
  • The Limitations bullet rewrite is consistent with the new body text, and the remaining bullets are untouched and still accurate.
  • No docs.json change needed (no new page), and no sibling page's description of small multiples is invalidated — configuration/index.mdx:13 and series-mapping.mdx:18 both describe the split generically.
  • N/A for this PR: security, performance, tests.

One process note from the PR body: since this also carries the 5 × 5 correction from #11498, whichever lands second will conflict on lines 28 and 43.

· branch [`igor/cub-3620-docs-small-multiples-second-axis`](https://github.com/cube-js/cube/tree/igor/cub-3620-docs-small-multiples-second-axis)

Comment thread docs-mintlify/docs/explore-analyze/charts/configuration/small-multiples.mdx Outdated
Comment thread docs-mintlify/docs/explore-analyze/charts/configuration/small-multiples.mdx Outdated
@igorlukanin
igorlukanin force-pushed the igor/cub-3620-docs-small-multiples-second-axis branch from 6cd3890 to 7536a92 Compare August 12, 2026 10:55
@claude

claude Bot commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Claude finished @igorlukanin's task in 58s —— View job


Docs review (updated) — 0 high, 0 medium, 3 low

Both of my earlier threads are now resolved — the "single row of panels" wording and the Grid cell were both fixed as suggested, and the author went further by clarifying Sort panels by for two dimensions. The page now reads consistently on the main story. Three low nits remain, two posted inline.

Full review
  • Re-read PR diff against origin/master
  • Re-read the full page for internal consistency
  • Check prior review threads (both resolved/outdated — suggestions applied)
  • Post findings

Low

1. small-multiples.mdx:31 — Sort order row doesn't inherit the two-dimension caveat. (inline)
Line 30 now says the row order is "always … ascending", so with two split dimensions Sort order governs the columns only. The adjacent row still reads as a global control.

2. small-multiples.mdx:47 — "more values than the grid has tiles" is still the one-dimension framing.
With two split dimensions the overflow test is per axis (column dimension vs. the columns number), not value-count vs. total tiles — which is exactly the point lines 45 and 49 make. A short "each axis against its own number" clause would keep the three paragraphs telling one story.

3. Frontmatter description (line 3) and the intro (line 6) still say "one per value of a dimension".
Accurate for the single-dimension case and fine as a summary; flagging only because the description is the SEO/nav preview and the grid-of-two is now the headline capability. Optional.

Verified fine

  • Lines 18, 28, 30, 45, 49, and 61 all agree: first dimension → columns, second → rows, each number caps its own axis, columns follow Sort panels by, rows ascending by value.
  • 5 × 5 / twenty-five consistent at 28, 43, 45. No stale 5 × 4 or "twenty panels" left in docs-mintlify.
  • The 5 × 40 → 25-panel example is right under per-axis caps.
  • Limitations bullet 1 rewrite matches the body; the other bullets are untouched and still accurate.
  • No docs.json change needed (no new page). Sibling pages (configuration/index.mdx:13, series-mapping.mdx:18) describe the split generically and aren't invalidated.
  • Legacy docs/explore-analyze/charts/configuration/small-multiples.mdx correctly left alone per CLAUDE.md.
  • N/A for this PR: security, performance, tests.

Unverifiable from the repo

  • The and by picker label and the "a dimension already used on one axis is not offered on the other" behaviour are UI claims with no source in this repo — worth a spot-check against the shipped UI, since the PR body notes it depends on that change landing first.

Still true from the earlier review: this carries the 5 × 5 correction from #11498, so whichever lands second will conflict on lines 28 and 43.

· branch [`igor/cub-3620-docs-small-multiples-second-axis`](https://github.com/cube-js/cube/tree/igor/cub-3620-docs-small-multiples-second-axis)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant