` component in any SvelteKit route `+page.svelte`.
A few things of note about this component:
* You will need to import and configure any number of [Shiki themes](https://shiki.style/themes).
* You will need to import and configure any number of [supported languages](https://shiki.style/languages).
* The component has been implemented using Skeleton's [component style guidelines](http://localhost:4321/docs/resources/contribute/components).
* This provides a number of style props for easy customization via Skeleton's standard conventions.
* The component exposes `code`, `lang`, and `theme` properties to configure on-the-fly.
* The Code Block `` tag is auto-generated by Shiki; target utility classes with: `[&>pre]:myClassHere`.
## Programmatic Usage
In some cases you may not have direct access to the source code, such as content from a blog posts or CMS pages. In fact the code may even come pre-baked with surrounding `` or `` elements. For this, you'll need to follow the general steps below. Specific implementation may differ based on your app and meta-framework.
1. Query all `` or `` blocks using Javascript tools like `document.querySelectorAll()`. Be as specific as possible.
2. Ensure you have a clean instance of the source code itself, with no extra markup injected within.
3. Use Shiki's [codeToHtml](https://shiki.style/guide/install#shorthands) feature to parse the code as styled HTML markup.
4. Then append each instance of the code blocks in your DOM.
For more instructions, please refer to this guide by [Joy of Code](https://joyofcode.xyz/) explaining how to [implement Shiki via MDX](https://joyofcode.xyz/sveltekit-markdown-blog#using-components-inside-markdown).
## Custom Themes
Shiki provides support for generating a custom highlighter theme:
* [Loading Custom Themes](https://shiki.style/guide/load-theme)
* [List of Bundled Themes](https://shiki.style/themes)
Shiki theme values can be defined using Skeleton custom theme properties, such as `rgba(--color-primary-500)`.
## Accessibility
See [Salma Alam-Naylor's](https://whitep4nth3r.com/about/) guidelines for [creating accessible code blocks](https://whitep4nth3r.com/blog/how-to-make-your-code-blocks-accessible-on-your-website/) that meet WGAC standards.
# Iconography
Learn how to integrate Lucide for iconography in Skeleton.
## Lucide
If you're looking for an opinionated solution, Skeleton recommends [Lucide](https://lucide.dev/). This provides a huge selection of icons that are available to all popular frameworks and feature a clean and modern style. All code examples in this documentation site implement Lucide, but feel free to replace with any alternative.
### Installation
Follow the official instructions to install [Lucide for Svelte](https://lucide.dev/guide/packages/lucide-svelte).
## Usage
For optimal performance we recommend importing each icon using the full path.
```svelte
```
## Alternatives
* [Iconify](https://iconify.design/) - provides a vast array of icon sets supported by popular icon libraries.
* [Font Awesome](https://fontawesome.com/) - provides a huge variety of icons in their free tier.
* [SimpleIcons](https://simpleicons.org/) - provides an excellent selection of brand icons.
# Contribute
Learn how to contribute to Skeleton.
{/* --- */}
# LLMs
Documentation for LLMs. Beep Boop.
{/* --- */}
The Skeleton `LLMs.txt` files provide concise, up-to-date documentation optimized for large language models. The have been implemented to follow the **LLM.txt Standard**.
## Paths
\| Path | Description |
\| ------------------------------------ | --------------------------- |
\| [/llms.txt](/llms.txt) | List of LLMs txt directory. |
\| [/llms-react.txt](/llms-react.txt) | React guidelines. |
\| [/llms-svelte.txt](/llms-svelte.txt) | Svelte guidelines. |
# Get Started
Read this before you submit your first contribution.
## How to Contribute
Take care to read all contributions guidelines before you begin!
1. Learn how to [contribute to open source](https://opensource.guide/how-to-contribute/).
2. Follow a [step-by-step guide](https://github.com/firstcontributions/first-contributions) to practice your first contribution.
3. Locate an [open issue on GitHub](https://github.com/skeletonlabs/skeleton/issues). Post a comment letting us know you wish to volunteer.
4. Optionally, you may coordinate efforts on the `#contributors` channel within [Discord](https://discord.gg/EXqV7W8MtY).
5. A member of the Skeleton team will assign the issue to you and help outline requirements.
6. Complete the work and submit a pull request per the requirements on this page.
> NOTE: non-trivial PRs submitted without our prior consent will be denied. Repeat offenders will be blocked.
## Using PNPM
Skeleton makes use of [PNPM](https://pnpm.io/) and [PNPM workspaces](https://pnpm.io/workspaces) to maintain all projects within the Skeleton monorepo.
1. [Install PNPM](https://pnpm.io/installation) on your local computer.
2. [Fork the Skeleton monorepo](https://github.com/skeletonlabs/skeleton) via the option on GitHub.
3. Use Git to clone the forked project to your local machine.
4. Run `pnpm i` from the root to install the required dependencies.
5. Point your terminal at one of the `/sites`, `/packages` or `/playgrounds` projects detailed below.
6. Run `pnpm dev` to start a local dev server for each project.
> NOTE: Make sure you're running PNPM version `9.5.0` or higher to ensure support for [PNPM catalogs](https://pnpm.io/catalogs). You can check your version with `pnpm --version`.
### Adding Dependencies
As a courtesy, please consult with Skeleton maintainers before adding dependencies. Third-party dependencies come with some level of risk, and we may be able to offer alternatives that limit the scope of changes.
Dependencies may be installed using the standard `pnpm i` command. However, in some cases it may be beneficial to maintain a uniform version shared across multiple projects or within each `package.json`. For this we can make use of [PNPM Catalogs](https://pnpm.io/catalogs).
The main version is maintained in the monorepo root in `pnpm-workspace.yaml`:
```yaml
catalog:
# ...
:
```
Use the following convention to link each project's dependency to the shared Catalog version:
```shell
pnpm add @catalog:
```
## Monorepo Structure
### Sites
Public facing websites that are deployed and hosted for users to browse.
\| Path | Description |
\| ---------------------------- | ------------------------------------- |
\| `/sites/skeleton.dev` | The production documentation website. |
\| `/sites/themes.skeleton.dev` | The Skeleton themes generator website |
### Packages
Modular Skeleton packages distributed via NPM.
\| Path | Description |
\| --------------------------- | -------------------------------------------------------------------------- |
\| `/packages/skeleton` | The Skeleton core package, contains Skeleton's Tailwind-specific features. |
\| `/packages/skeleton-react` | The Skeleton React package, contains Skeleton React components. |
\| `/packages/skeleton-svelte` | The Skeleton Svelte package, contains Skeleton Svelte components. |
\| `/packages/skeleton-common` | The Skeleton common package, contains shared internal only utilities. |
\| `/packages/cli` | The Skeleton CLI, contains Skeleton's migrations. |
## Playgrounds
Isolated sandbox environments for developing, testing and experimenting.
\| Path | Description |
\| ------------------------------ | ----------------------------------------------------- |
\| `/playgrounds/skeleton-svelte` | A SvelteKit playground for testing the Svelte package |
\| `/playgrounds/skeleton-react` | A NextJS playground for testing the React package |
## Branch
Create and target all pull requests against the `main` branch unless otherwise instructed.
\| Branch | Description | Pull Requests |
\| ------ | -------------------------------------------------- | -------------------------------------------------- |
\| `main` | Represents the release branch of the all projects. | Allowed |
### PR Branch Conventions
Please use the following naming convention when creating your pull request.
\| Branch | Role |
\| ----------- | ------------------------------------- |
\| `docs/*` | When updating the documentation site. |
\| `feature/*` | When implementing a new feature. |
\| `task/*` | When implementing a small task. |
\| `bugfix/*` | When implementing a fix for a bug. |
Keep branch names short and semantic, and use snake-case to separate words.
```
docs/get-started-typo-fix
bugfix/accordion-render-issue
```
## Documentation Schema
Before your first run of the `/sites/skeleton.dev` documentation project, make sure to run `pnpm generate:types` at least one time. This will generate the assets required to populate API Reference tables on each component's documentation page.
## Changesets
[Changesets](https://github.com/changesets/changesets) are used to automatically generate the changelog for each release.
* Any contributions made within `/packages` *must* contain a Changeset
* Any contributions made within `/sites` should not include a Changeset.
Follow these instructions to generate a changeset:
1. Make sure you're within your local pull request feature branch.
2. Navigate to the root of the Skeleton monorepo.
3. Run `pnpm changeset` to trigger the Changeset CLI.
4. Follow the instructions when prompted.
5. Changeset are added as `.md` files within the `.changeset/` directory.
6. You may edit or revise a Changeset before your PR is merged.
Changesets use semantic versioning. We recommend the following convention.
\| Version | Role |
\| ------- | ------------------------------------------- |
\| `major` | Do not use. Reserved for maintainers only. |
\| `minor` | For notable changes, such as a new feature. |
\| `patch` | For small changes, such as a fixing a bug. |
Changeset descriptions will appear verbatim on the [Changelog](https://github.com/skeletonlabs/skeleton/blob/dev/packages/skeleton/CHANGELOG.md). Keep it short, semantic, and and include the same [branch prefix](/docs/resources/contribute/get-started#pr-branch-conventions).
```mdx
---
'@skeletonlabs/skeleton-svelte': minor
---
feature: Added a new Avatar component.
```
## Tooling
Skeleton makes use of the following technology to improve the developer experience. It's recommended you run these tools before flagging the PR as "ready for review" on GitHub.
### Root Commands
Run the following commands in the monorepo root. Each will run recursively for supported packages.
* `pnpm format` - Formats the monorepo using [Prettier](https://prettier.io/).
* `pnpm lint` - Finds (and attempts to fix) any issues within the monorepo using [ESLint](https://eslint.org/).
* `pnpm test` - Runs all unit tests using [Vitest](https://vitest.dev/).
* `pnpm check` - Runs framework specific diagnostics, such as [Svelte Check](https://svelte.dev/docs/cli/sv-check), [Astro Check](https://docs.astro.build/en/reference/cli-reference/#astro-check), etc.
### Local Commands
Additionally, you may also run the local instance of each command. Consult the local `package.json` for available options. For `format` and `lint` commands, use the following syntax to draw from the root `package.json`:
```shell
pnpm -w
```
### VS Code Extensions
We recommend the use of [VSCode](https://code.visualstudio.com/) for contributions, and the following VSCode extensions.
* [Tailwind](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss)
* [Astro](https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode)
* [MDX](https://marketplace.visualstudio.com/items?itemName=unifiedjs.vscode-mdx)
* [Svelte](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode)
* [Prettier](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
* [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)
# Components
Guidelines for contributing new Skeleton components.
### Dev Server
To run all packages/playgrounds/sites in watch mode, use the following command in the monorepo root:
```shell
pnpm dev
```
We've also provide a number of sub-commands for a more limited set of packages:
```shell
pnpm dev:{command}
```
* `dev:docs` - runs all dependencies for the Documentation website.
* `dev:themes` - runs all dependencies for the Theme Generator website.
* `dev:svelte` - runs all dependencies for the Svelte Playground.
* `dev:react` - runs all dependencies for the React Playground.
### Server Ports
The following represents the *default* localhost address and port for each project. This will be displayed in the terminal when starting each dev server.
* Documentation Site: `http://localhost:4321/`
* Svelte Playground: `http://localhost:5173/`
* React Playground: `http://localhost:3000/`
You may run the sites and playgrounds in parallel at the same time. If a server shares a port, this will increment by one for the next server (ex: `5174`, `5175`, etc). Keep your eye on the terminal to retrieve the specific local address for each.
### Zag.js
Skeleton components are built using a foundation of [Zag.js](https://zagjs.com/). This provides a suite of headless component primitives that handle logic and state, while providing a universal set of features per all supported frameworks. The Skeleton design system is then implemented as a layer on top of this.
When introducing a new Skeleton component, please refer to the documentation for each respective framework. For example:
* Avatar (React): https\://zagjs.com/components/react/avatar
* Avatar (Svelte): https\://zagjs.com/components/svelte/avatar
Continue reading below to learn how implement the Zag primitives as components using Skeleton-specific conventions.
***
## Adding Components
### Anatomy
When creating a component, start by breaking it down into its core parts. If the component utilizes a [Zag primitive](https://zagjs.com/components/svelte/avatar), you may copy the source [directly from Zag's Usage section](https://zagjs.com/components/svelte/avatar#usage). For custom in-house components, you may use Skeleton's common terminology and discuss the potential anatomy with Skeleton maintainers.
For example, the Zag Avatar component utilizes the following DOM structure:
```html
...
```
As such, we'll implement one component part respective of each element:
* `` - the root element
* `` - the child image
* `` - the fallback span
We'll also include two special Skeleton-specific components:
* `` - Similar to `` but allows the user to pass in the api.
* `` - Provides access to the component tree's Context API.
### Directory and File Names
Components are housed in the following location per framework:
\| Framework | Directory |
\| --------- | ------------------------------------------- |
\| React | `/packages/skeletlon-react/src/components` |
\| Svelte | `/packages/skeletlon-svelte/src/components` |
Skeleton uses a consistent naming convention per component:
```
avatar/
├── anatomy/
│ ├── fallback.{tsx|svelte}
│ ├── image.{tsx|svelte}
│ ├── root-context.{tsx|svelte}
│ ├── root-provider.{tsx|svelte}
│ └── root.{tsx|svelte}
├── modules/
│ ├── anatomy.ts
│ ├── provider(.svelte).ts
│ └── root-context.ts
└── index.ts
```
### Anatomy Folder
The anatomy folder contains each component part inside a seperate file.
### Component Part File
Every component part should export their component as a default export and their prop types as named exports.
**React**
```tsx title="avatar-root.tsx"
export interface AvatarRootProps {
// ...
}
export default function Root(props: AvatarRootProps) {
// ...
}
```
**Svelte**
```svelte title="avatar-root.svelte"
```
Note that you may need to extend or omit portions of the type to avoid conflicts between Zag and HTML attributes.
#### Extend
* `PropsWithElement` - via Skeleton's `@/internal/props-with-element`; allows for HTML template overrides.
* `HTMLAttributes` - via Skeleton's `@/internal/html-attributes`; allows for standard HTML attributes.
#### Omit
* `Omit` - omit the `id` field from the `Props` interface as they will be provided inside the component itself.
### Modules Folder
#### Anatomy File
The `anatomy.ts` file contains the exported anatomy, which enables the friendly dot notation syntax when consumed.
```ts title="avatar-anatomy.ts"
import Fallback from '../anatomy/fallback';
import Image from '../anatomy/image';
import Root from '../anatomy/root';
export const Avatar = Object.assign(
Root, //
{
Image: Image, //
Fallback: Fallback, //
},
);
```
#### Context Files
The `{part}-context.ts` file contains the exported context for each component part's [context](/docs/resources/contribute/components#context-api). This pattern enables strong typing of the context itself.
For most components this will only be necessary for the root component, some components however may require context for their children well. Reference existing components for real world examples.
```ts title="avatar-root-context.ts"
import type { useAvatar } from './use-avatar';
import { createContext } from '@/internal/create-context';
export const AvatarRootContext = createContext>();
```
#### Index File
The index prepares all required component files for export.
```ts
export { Avatar } from './modules/anatomy';
export { useAvatar } from './modules/provider';
export type { AvatarRootProps } from './anatomy/root';
export type { AvatarRootProviderProps } from './anatomy/root-provider';
export type { AvatarRootContextProps } from './anatomy/root-context';
export type { AvatarImageProps } from './anatomy/image';
export type { AvatarFallbackProps } from './anatomy/fallback';
```
### Component Exports
Finally, make sure to export the new component for each respective component's framework package. This is handled in `/packages/skeleton-{framework}/src/index.ts`.
```ts
export * from './components/accordion/index';
export * from './components/avatar/index';
// ...
```
***
## Using Zag Primitives
### Source Code
Locate the respective framework component source code on the Zag website. For example:
\| Framework | Directory |
\| --------- | --------------------------------------------------------------- |
\| React | [Avatar Docs](https://zagjs.com/components/react/avatar#usage) |
\| Svelte | [Avatar Docs](https://zagjs.com/components/svelte/avatar#usage) |
In most cases, Zag provides all source code in a single file. Take care when splitting this into multiple component parts. We recommend starting with the root component - including the primitive imports, and defining the `machine` and `api`. Then utilize Context API and child components for each additional sub-component.
### Context API
In some cases you may need to pass data from parent down to child components. For this, we can utilize each framework's Context API:
\| Framework | Documentation |
\| --------- | ----------------------------------------------------------------------------------------------------------- |
\| React | [View Component API docs](https://react.dev/learn/passing-data-deeply-with-context) |
\| Svelte | [View Component API docs](https://svelte.dev/docs/kit/state-management#Using-state-and-stores-with-context) |
Note that Skeleton implements a [set convention for Context API](/docs/resources/contribute/components#context-files) to enable strong typing.
### Common Conventions
While each component will present a unique set of challenges, we recommend you reference other existing components to see how we've handled specific situations. But there are a few common conventions we'll detail below.
* Try to stick as close to the Zag implementation DOM structure and naming as possible; don't get creative.
* Use whitespace to seperate Zag versus Skeleton logic, including: props, attributes, and context definitions.
* Avoid hardcoded english text or icons. Consider pass-throughs using props, snippets, or sub-components.
* Default to the named import pattern, such as `import { foo, bar, fizz } from 'whatever';` (Including Zag's imports)
#### React Specific
* Pass the `id` field into the `useMachine` hook using the `useId()` hook from `react`.
* Consume context using `use(Context)` from `react`.
* Use the `className` attribute to pass Skeleton classes.
#### Svelte Specific
* Pass the `id` field into the `useMachine` function using the `props.id()` rune from `svelte`.
* Consume context using the `Context.consume()`.
* Use the `class` attribute to pass Skeleton classes.
> NOTE: We welcome contributions to expand this section!
***
## Styling Components
Component classes are now common and shared between all framework iterations. These reside in `/packages/skeleton-common` and are named to match their respective component.
```
packages/
└── skeleton-common/
└── src/
├── classes/
| ├── accordion.ts
| ├── avatar.ts
| └── ...
└── index.ts
```
Here's an example of the Avatar styles found in `avatar.ts`:
```ts title="avatar.ts"
import { defineSkeletonClasses } from '../internal/define-skeleton-classes' with { type: 'macro' };
export const classesAvatar = defineSkeletonClasses({
root: 'isolate bg-surface-400-600 size-16 rounded-full overflow-hidden',
image: 'w-full object-cover',
fallback: 'size-full flex justify-center items-center',
});
```
* We'll cover the import `{ type: 'macro' }` in the [style prefix](#style-prefix) section.
* Use the naming convention of `classes{Component}`
* Create a key for each component part.
* The values provide the default utility classes to the component's class list.
* You can optionally pass an array of strings `['', '']` to document multi-line.
* Make sure to export the component class file in `/packages/skeletlon-common/index.ts`.
### Array Notation
You can optionally provide an array of strings whenever the class list is long or can be split into logical sections. This improves readability. The `defineSkeletonClasses` function will flatten the array into a single string at build time.
```ts title="avatar.ts"
import { defineSkeletonClasses } from '../internal/define-skeleton-classes' with { type: 'macro' };
export const classesProgress = defineSkeletonClasses({
root: [
// Common
'items-center justify-center gap-2',
// Horizontal Orientation
'data-[orientation=horizontal]:flex data-[orientation=horizontal]:flex-row data-[orientation=horizontal]:w-full',
// Vertical Orientation
'data-[orientation=vertical]:inline-flex data-[orientation=vertical]:flex-col',
],
// ...
});
```
### Style Prefix
It's worth noting that during build time, Skeleton will automatically prefix each class in the class list with `skb:` (short for "Skeleton Base"). By applying `with { type: 'macro' }` to the import, the import will run `defineSkeletonClasses` specifically at build time. This variant prefix will assign each class to the Tailwind `@base` layer, ensuring user-provided classes take precedence over our internally defined classes. This is accomplished using the following Tailwind custom variant.
```css title="/packages/skeleton/src/variants/base.css"
@custom-variant skb {
@layer base {
@slot;
}
}
```
If you need to prevent a class from being prefixed at build time, apply a variant of `not-skb:` to that class.
> NOTE: This should be a rare use-case requiring discussion with the Skeleton team prior to implementation as it means the user won't be able to override that specific class without using the anti-pattern: `!` for `!important`.
### Importing Class Lists
For Zag primitives, you can import and implement each class list Using Zag's `mergeProps` utility for attributes.
```tsx title="root.tsx"
import type { HTMLAttributes } from '@/internal/html-attributes';
import type { PropsWithElement } from '@/internal/props-with-element';
import { classesAvatar } from '@skeletonlabs/skeleton-common';
import type { Props } from '@zag-js/avatar';
import { mergeProps } from '@zag-js/react';
export interface AvatarRootProps extends Omit, PropsWithElement<'div'>, HTMLAttributes<'div', 'id'> {
// ...
}
export default function (props: AvatarRootProps) {
const { children, ...rest } = props;
const attributes = mergeProps(
api.getRootProps(),
{
className: classesAvatar.root,
},
rest,
);
return {children}
;
}
```
The process is similar for custom components without Zag primitives. We still use the Zag `mergeProps` utility, just without the `api.getPartProps()`.
```tsx title="root.tsx"
import { classesNavigation } from '@skeletonlabs/skeleton-common';
import { mergeProps } from '@zag-js/react';
export default function (props: NavigationRootProps) {
const { children, ...rest } = props;
const attributes = mergeProps(
{
className: classesNavigation.root,
},
rest,
);
return {children}
;
}
```
## Testing Components
We recommend you reference existing components to see how we've handled testing. Each framework has slightly different testing conventions, but all utilize [Vitest](https://vitest.dev/) with [Testing Library](https://testing-library.com/).
Test files are located in `packages/skeleton-{framework}/test/components/{component}` and each contain two files:
* `index.test.{tsx|tsx}` - contains the actual test cases.
* `test.{tsx/svelte}` - contains a wrapper component used to provide `data-testid` attributes to each respective component part.
## Additional Resources
* [Component Party](https://component-party.dev/) - easily compare features between each framework
* [React Documentation](https://react.dev/) - the React documentation website.
* [Svelte Documentation](https://svelte.dev/) - the Svelte documentation website.
# Documentation
Guidelines for contributing to the Skeleton documentation website.
## Astro
The Skeleton documentation website is maintained using the Astro framework.
### Integrations
Review the full list of integrations in `astro.config.js`.
* [Partytown](https://docs.astro.build/en/guides/integrations-guide/partytown/)
* [Svelte](https://docs.astro.build/en/guides/integrations-guide/svelte/)
* [React](https://docs.astro.build/en/guides/integrations-guide/react/)
* [Expressive Code](https://expressive-code.com/)
* [Icon](https://www.astroicon.dev/)
* [AutoImport](https://github.com/delucis/astro-auto-import)
* [MDX (Markdown + JSX)](https://docs.astro.build/en/guides/markdown-content/)
## App Structure
Navigate the app structure within the `/src` directory. This includes the following directories:
\| Path | Description |
\| ------------- | ----------------------------------------------------------------------------------------------------------------------------- |
\| `/components` | Contains our components. |
\| `/content` | Contains our MDX content managed with [Astro's content collections](https://docs.astro.build/en/guides/content-collections/). |
\| `/images` | Contains our images. |
\| `/lib` | Contains our modules. |
\| `/pages` | Contains our pages. |
## Pages
### Standard Pages
1. Browse to `/content/docs/` and create a new `.mdx` file
2. Populate all required Frontmatter metadata within the frontmatter `---` fences, see the content configuration in `/src/content.config.ts` for which properties need to be set.
3. New pages will be automatically added to the sidebar navigation.
### Component Pages
Component page content is split into three files within `/content/docs/components//`.
* `meta.mdx` - common frontmatter metadata for the page header (ex: title, description, etc).
* `react.mdx` - examples and usage information specific to the React page.
* `svelte.mdx` - examples and usage information specific to the Svelte page.
### Hidden Pages
If you wish to prevent a page from showing in the navigation, prefix it with an understore: `_example.mdx`.
## Using MDX
View the [Astro MDX Documentation](https://docs.astro.build/en/guides/markdown-content/) or refer to `/src/content/docs/resources/_markdown.md` for a "kitchen sink" example page.
## Doc-Only Components
Functional components for the Astro project are housed in `/src/components`. These support Astro/React.
* Astro - used for simple presentational components without logic.
* React - functional components that implement state, logic, or interaction.
> TIP: For React components, make sure to use [Astro's hydration directives](https://docs.astro.build/en/guides/framework-components/#hydrating-interactive-components).
## Global Components
A suite of global components are automatically imported within MDX pages via [astro-auto-importer](https://github.com/delucis/astro-auto-import/tree/main/packages/astro-auto-import).
> TIP: These components are configure via `astro.config.mjs` > `AutoImport()` in the project root.
### Essential Code
Code Blocks are provided via [Expressive Code](https://expressive-code.com/) via either the `` component or Markdown fences. This is powered by the [Shiki](https://shiki.matsu.io/) syntax highlighter. View the [list of supported languages](https://github.com/shikijs/textmate-grammars-themes/blob/main/packages/tm-grammars/README.md).
```tsx
Skeleton`} lang="html" />
```
### Preview
Allows you to quickly toggle between an example component and its source code.
```ts
import Default from '@/components/examples/foo/default';
import DefaultRaw from '@/components/examples/foo/default?raw';
```
```astro
```
#### Framework Specific Code
To allow for a common preview to have framework specific code, use the `codeReact` and `codeSvelte` slots. For generic code that is not framework specific, such as an Astro component along with JavaScript, use the `code` slot instead.
```astro
```
> TIP: For React or Svelte components, make sure to use [Astro's hydration directives](https://docs.astro.build/en/guides/framework-components/#hydrating-interactive-components).
### API Tables
When placed on a component documentation page, these will automatically fetch and display the type schema for the respective component.
```mdx
## API Reference
```
## Icons
### Lucide
This documentation app implements the [React version](https://lucide.dev/guide/packages/lucide-react) of [Lucide](https://lucide.dev/) for most icons. View
Iconography details.
### SVG Components
View the [Astro documentation](https://docs.astro.build/en/guides/images/#svg-components) for more information.