Platform content lives in
src/platforms and follows some specific rules to generate content. The content is rendered using the same features as all other pages, but has some additional functionality exposed to clone content and encapsulate platforms as portals.
Directory structure has meaning within the platforms directory, and looks something akin to:
[platformName]/ child.mdx childTwo/ index.mdx common/ aSharedPage.mdx guides/ [guideName]/ uniqueChild.mdx childTwo/ index.mdx
Platforms will generate a list of "guides", and inherit all content within common. Given the above example, we end up with a variety of semi-duplicated URLs:
/platforms/platformName/ /platforms/platformName/config.yml /platforms/platformName/child/ /platforms/platformName/childTwo/ /platforms/platformName/aSharedPage/ /platforms/platformName/guides/guideName/ /platforms/platformName/guides/guideName/config.yml /platforms/platformName/guides/guideName/child/ /platforms/platformName/guides/guideName/uniqueChild/ /platforms/platformName/guides/guideName/childTwo/ /platforms/platformName/guides/guideName/aSharedPage/
This is generated by inheriting all content with the
common/ directory, then adding (or overriding with) content from the siblings (or children as we'd call them). In the above example, you'll see
aSharedPage is loaded at two different URLs, and
childTwo is overwritten by
The sidebar on platform pages (handled by
<PlatformSidebar>) will generate with the Guide, or the Base Platform being the primary section, in addition to a list of other guides available in a section below it. This means that all content is focused on the current guide (usually a framework) they're in, ensuring ease of navigation.
Configuration is read (in order) from
[namespace]/config.yml. This means that a platform's index can be fully rendered via a common page.
Valid configuration attributes are:
- The display name for a platform.
- The level of support.
- The casing style for code samples.
- A list of categories for future support. Known values are
- The key to use for defaults. Can use full key syntax of
- The name of the SDK, if available. Used to embed SDK information on pages.
- A list of aliases for this platform. For example, "Cocoa" might apply to Apple, or "C#" might apply to .NET.
There are two forms of shared (duplicated) content available:
- platform-specific content
- globally shared content
Both of these are contained using the
common/ folder paradigm. The global content is within
src/platforms/common/ and for platform specific content it should be created within
All of this content will be automatically duplicated within every guide, as well as every platform (when it's at the global level). This leverages components like
PlatformContent which can automatically substitute content out.
Sometimes a page may not make sense within the context of a given platform. To control this, you can use the
notSupported frontmatter on all common pages in platforms.
Page visiblity works similar to the supported/notSupported attributes in other platform components (such as
For example, to make attachments only available on native platforms, you'd open up the document file (e.g.
attachments/index.mdx) and add the following to frontmatter:
--- supported: - native ---
If you wanted to make hide the content for a platform by default, but enable it for a guide, you can do that as well:
--- supported: - native.wasm notSupported: - native ---
If the page you're conditionally hiding has subpages, you'll need to add the
notSupported annotations to the subpages as well.
There are a number of components that aid the development of platform specific pages, as well as behave differently when a platform is active. For more information, see components.
We separate platform portals by the main way or mechanism that developers interact with the platform and with Sentry.
In general, use this decision tree:
- Is it a new programming language? -> new platform
- Does it require a separate SDK or way of sending data to Sentry? -> new platform
- Does it count as a "platform" -> new platform
- Otherwise -> add it as a Guide to an existing platform
On the other hand, Android and Java have very little overlap. As a result, they are both top level platforms.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").