Skip to main content
Sometimes changing the programming language or framework changes more than the code. The headings, explanations, and procedure may all follow a different path. The <View> component lets readers make that choice once and see the version of the page that applies to them. Use views for page-level variation. If only one section or code sample changes, a smaller component will be easier to follow.

​
How views work

Each <View> block has a title that appears in a dropdown on the page. When a reader chooses a title, the page shows the matching view and updates the table of contents. Use one view per option on a page.
Example of views
Try the selector on this page. Switching between JavaScript and Python changes the example below.

​
JavaScript example

​
Choose the smallest component that fits

Views, tabs, and code groups all show variations, but at different scales:
  • Use <CodeGroup> when the explanation stays the same and only the code changes.
  • Use <Tabs> when one section changes based on the reader’s platform, role, or another known context.
  • Use <View> when the selection changes headings, explanations, or several examples across the page.
For example, an SDK guide may use views when its JavaScript version explains promises while its Python version explains synchronous and asynchronous clients. Those differences affect the page’s structure, not just a code block.

​
Keep shared information visible

Put introductions, prerequisites, and warnings that apply to every reader outside the view blocks. Duplicating them creates extra maintenance, while placing them in only one view hides them from everyone else. Views are also a poor fit when readers need to compare the options before choosing. The selector shows one version at a time, so use a table or visible sections for a comparison. Don’t use views simply to shorten a page. The hidden content should be an alternative version, not required information that every reader needs.

​
Show different content to different audiences

Views let readers choose. The <Visibility> component chooses for them, based on who’s reading. People and AI agents. Content wrapped in <Visibility for="humans"> appears on your site but not in the Markdown version that agents read. Content in <Visibility for="agents"> does the opposite. Use it when the best instructions differ: a person clicks a button, while an agent calls an API.
Example of agent-only content
Signed-in readers and user groups. If your site uses authentication, <Visibility> can also show content only to signed-in or signed-out readers, or to specific user groups. For example, show a “Sign in to see your API keys” prompt to signed-out readers and the keys page link to everyone else. Like views, visibility works best for alternatives. Keep information everyone needs outside the component. Next up: Tables for structured comparisons—when a grid communicates relationships better than prose or cards.