Working with a specific static site generator? Customize CloudCannon's documentation to suit your SSG.
Great! We'll show you documentation relevant to . You can change this any time using the dropdown in the navigation bar.
CloudCannon supports embedding rich Snippets in Markdown content when using the CloudCannon Content Editor. Once configured, Snippets in your content will be presented as blocks in rich text views, with the ability to add them as Snippets via the toolbar:
To start configuring Components in your MDX content, a Snippet configuration must be imported using the _snippets_imports key in your CloudCannon global configuration file.
By default, CloudCannon will show the snippet toolbar action in the content editor if snippets are available.
If you have already customized which options are available via _editables in your CloudCannon config, you will need to include snippet: true for Snippets to be available. See the Editables options documentation for more details.
After importing the mdx Snippets configurations, any custom components in your content will be displayed in the Content Editor as an Unknown Component. This allows an editor to move and delete a Component, but prevents editing of its arguments or content:
To enable editing and provide the custom component in the toolbar, your custom component must be configured using the _snippets object in your CloudCannon global config file. CloudCannon Snippets can be built from scratch to support nearly any syntax or SSG, but importing a Snippet configuration provides a set of snippet templates for common use cases in MDX.
To help illustrate configuring custom Snippets, we will first cover a few examples. First, let's look a custom Tint component on our MDX site that takes a string and applies a color to it:
post.md
copied
The first thing we need to do is decide which Snippet template to use. Looking at the list of snippet templates further down this page, we see that MDX has two templates mdx_component and mdx_paired_component. Our component has child content so we should configure this snippet using the mdx_paired_component template. A full example configuration for this Snippet thus might look like the following:
cloudcannon.config.yaml
copied
cloudcannon.config.json
copied
cloudcannon.config.js
copied
Each snippet definition lives under a top level key, mdx_tint in this example. This is the unique name that CloudCannon uses to identify this snippet, but is otherwise unused in the component configuration itself.
We specify the template that this snippet should inherit from, and also specify that it is an inline snippet, since it can live anywhere in the content (such as in the middle of a sentence).
In definitions we need to specify some values that are required for the template we picked. For the mdx_paired_component template, we need to specify:
The component_name — in this case we're configuring our tint component.
The content_key — this controls the key that CloudCannon will use to edit the text in between the start and end tags of the component.
The named_args — for our tint component we need to configure that the tint_color should be captured with the key color
Finally, we can specify any other keys from the CloudCannon configuration cascade here. In this example, we configure the inputs for the keys that this snippet will generate. With that in place, we can now add and edit our tint component anywhere on our site.
Next, let's quickly look at a component with a different syntax:
post.md
copied
This time, we have an unpaired component that takes type and message argument keys. This syntax matches the mdx_component template.
In CloudCannon, we could configure this component using the following global configuration:
cloudcannon.config.yaml
copied
cloudcannon.config.json
copied
cloudcannon.config.js
copied
This should now be familiar, but with a few changes:
We want this snippet to be a block-level element in the editor, so we set inline to false.
Since this component does not have an end tag, we have no content_key
In this example, we want the key in our component to be type, but tell CloudCannon to treat that value as the label key, which we then configure using our inputs configuration.
Whether this component can appear inline (within a sentence). Defaults to false, which will treat this component as a block-level element in the content editor.
The first step to configure your custom component is to identify which component template to use, as each component template requires a set of definitions keys to be configured. The following component templates are available:
Whether this argument is required for the shortcode. If false, shortcodes in your templates missing this argument will not match this snippet definition.
A list of values that this argument must be in order to match this snippet definition. Allows you to match different usages of the same shortcode to separate snippet definitions based on the value of an argument.