docs: add view groups documentation

[paveltiunov]

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

Description of Changes Made

Adds documentation for the view_group feature introduced in v1.6.43 (#10768). View groups let data model authors organize views into named collections by domain or purpose (e.g., sales, finance, people), making it easier for downstream consumers — AI agents, embedded analytics, and visualization tools — to discover the right dataset.

Changes

New reference page (reference/data-modeling/view-group.mdx)

• Documents all view group parameters: name, title, description, views
• Explains the two complementary ways to assign views to groups (group-level views list vs. view-level view_group/view_groups properties)
• Includes a full end-to-end example using the ecommerce data model with the resulting /v1/meta response

View reference page (reference/data-modeling/view.mdx)

• Adds view_group (singular) and view_groups (plural) parameter sections with YAML and JavaScript examples

Conceptual views page (docs/data-modeling/views.mdx)

• New "Grouping views with view groups" section before "Next steps"
• Updated "Next steps" list to link to view groups

Syntax page (docs/data-modeling/concepts/syntax.mdx)

• Updated folder structure example to show view_groups.yml

Navigation (docs.json)

• Added reference/data-modeling/view-group to Reference > Data Modeling, right after the view page

  

[mintlify]

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

Project	Status	Preview	Updated (UTC)
cubed3	🟢 Ready	View Preview	May 4, 2026, 4:05 PM

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

[claude]

Claude finished @paveltiunov's task in 3m 14s —— View job

---

Review: View Groups Documentation

• Gather context and read changed files
• Review docs.json navigation changes
• Review syntax.mdx changes
• Review views.mdx changes
• Review new view-group.mdx reference page
• Review view.mdx changes
• Post comprehensive review

---

This is a well-structured documentation PR. The new content is clear, well-organized, and follows the existing doc conventions. A few observations:

What looks good

• Navigation placement (docs.json): The view-group entry is correctly positioned right after view in the Reference > Data Modeling group — logical and discoverable.
• Folder structure update (syntax.mdx): The tree example now shows view_groups.yml alongside views, with the mention that view groups can be "defined alongside views or in their own files." The └── to ├── fix for revenue.yml is correct.
• Conceptual section (views.mdx): The new "Grouping views with view groups" section is well-placed before "Next steps" and clearly explains both the group-side and view-side assignment approaches with matching YAML/JS examples. The "Next steps" list update is a nice touch.
• Reference page (view-group.mdx): Thorough and well-organized. The parameters section covers name, title, description, and views with clean examples. The end-to-end example with the /v1/meta JSON response is particularly helpful — it shows the full picture from data model to API output.
• Cross-references: All internal links between the new pages and existing docs are consistent and correct.
• YAML/JS parity: Every example includes both YAML and JavaScript variants with proper syntax conventions (snake_case for YAML, camelCase for JS — view_group vs viewGroup).

Nits (non-blocking)

1. JS-specific phrasing in view.mdx — The view_group and view_groups parameter descriptions say the group "must be defined with view_group() elsewhere." This is JavaScript-specific syntax; YAML users would use a view_groups: block. Consider the more neutral "must be defined elsewhere in the data model." (See inline comments on line 234 and line 267)

2. Missing trailing newline in view.mdx — The file ends without a newline character. (See inline comment)

3. "Required" vs "should have" — view-group.mdx line 16 says "A view group should have the following parameter: name." If name is actually required, consider "A view group must have…" to match the stronger language used on the view reference page ("Any view should have the following parameters: name and cubes").

Summary

Clean, comprehensive docs addition that covers the feature from both conceptual and reference angles. The examples are practical and the cross-linking is solid. The nits above are all minor wording/style suggestions — nothing blocking.

[claude]

Nit: The phrasing "must be defined with view_group()" is JavaScript-specific. YAML users would define it with the view_groups: block, not a function call. Consider something syntax-neutral like:

Suggested change

	### `view_group`
	Assigns this view to a single [view group][ref-ref-view-group]. The referenced
	view group must be defined elsewhere in the data model.

[claude]

Nit: file should end with a newline.

Suggested change

	[ref-ref-view-group]: /reference/data-modeling/view-group
	[ref-ref-view-group]: /reference/data-modeling/view-group

[claude]

Nit: The phrasing "must be defined with view_group()" is JavaScript-specific. YAML users would define it with the view_groups: block, not a function call. Consider something syntax-neutral like "must be defined elsewhere in the data model."

[claude]

Same note as the view_group section — "defined with view_group()" is JS-specific syntax. Consider "must be defined elsewhere in the data model" for syntax neutrality.

[claude]

Nit: File should end with a trailing newline.