Platform Portals

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 guideName.

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

Configuration is read (in order) from [namespace]/index.mdx and [namespace]/config.yml. This means that a platform's index can be fully rendered via a common page.

Valid configuration attributes are:

title

The display name for a platform.

supportLevel

The level of support. production (default) or community

caseStyle

The casing style for code samples. canonical (default), camelCase, snake_case, or PascalCase

categories

A list of categories for future support. Known values are browser, mobile, desktop, and server.

fallbackPlatform

The key to use for defaults. Can use full key syntax of platformName or platformName.guideName.

sdk

The name of the SDK, if available. Used to embed SDK information on pages.

aliases

A list of aliases for this platform. For example, "Cocoa" might apply to Apple, or "C#" might apply to .NET.

Shared Content

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 src/platforms/[platformName]/common/.

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.

Page Visibility

Sometimes a page may not make sense within the context of a given platform. To control this, you can use the supported and notSupported frontmatter on all common pages in platforms.

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 supported/notSupported annotations to the subpages as well.

Platform-Specific Components

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.

Delineation

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

Example

JavaScript is a top-level SDK because the frameworks that it supports share much of the same content.

On the other hand, Android and Java have very little overlap. As a result, they are both top level platforms.