diff --git a/.gitignore b/.gitignore
index 150de1370..d7fd20052 100644
--- a/.gitignore
+++ b/.gitignore
@@ -32,4 +32,4 @@ yarn-error.log*
.fleet
# Fumadocs build (TEMPORARY)
-fumadocs
+# fumadocs
diff --git a/convert-themed-images.js b/convert-themed-images.js
new file mode 100755
index 000000000..117e88b08
--- /dev/null
+++ b/convert-themed-images.js
@@ -0,0 +1,121 @@
+#!/usr/bin/env node
+
+const fs = require('fs');
+const path = require('path');
+
+/**
+ * Converts ThemedImage components to standard markdown image syntax
+ * @param {string} content - The file content to process
+ * @returns {string} - The converted content
+ */
+function convertThemedImages(content) {
+ // Regex to match ThemedImage components with optional p tags
+ const themedImageRegex =
+ /\s*');
+ console.log('Examples:');
+ console.log(
+ ' node convert-themed-images.js fumadocs/content/blog/2023-10-02-what-is-a-state-machine/index.mdx',
+ );
+ console.log(' node convert-themed-images.js fumadocs/content/blog/');
+ process.exit(1);
+ }
+
+ const targetPath = args[0];
+
+ if (!fs.existsSync(targetPath)) {
+ console.error(`❌ Path does not exist: ${targetPath}`);
+ process.exit(1);
+ }
+
+ const stat = fs.statSync(targetPath);
+
+ if (stat.isFile()) {
+ if (targetPath.endsWith('.mdx')) {
+ processFile(targetPath);
+ } else {
+ console.error('❌ File must be a .mdx file');
+ process.exit(1);
+ }
+ } else if (stat.isDirectory()) {
+ console.log(`🔄 Processing directory: ${targetPath}`);
+ processDirectory(targetPath);
+ }
+
+ console.log('✨ Conversion complete!');
+}
+
+// Run the script
+main();
diff --git a/fumadocs/.gitignore b/fumadocs/.gitignore
new file mode 100644
index 000000000..55a12ae71
--- /dev/null
+++ b/fumadocs/.gitignore
@@ -0,0 +1,28 @@
+# deps
+/node_modules
+
+# generated content
+.contentlayer
+.content-collections
+.source
+
+# test & build
+/coverage
+/.next/
+/out/
+/build
+*.tsbuildinfo
+
+# misc
+.DS_Store
+*.pem
+/.pnp
+.pnp.js
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# others
+.env*.local
+.vercel
+next-env.d.ts
\ No newline at end of file
diff --git a/fumadocs/README.md b/fumadocs/README.md
new file mode 100644
index 000000000..70fd7dfd2
--- /dev/null
+++ b/fumadocs/README.md
@@ -0,0 +1,45 @@
+# fumadocs
+
+This is a Next.js application generated with
+[Create Fumadocs](https://github.com/fuma-nama/fumadocs).
+
+Run development server:
+
+```bash
+npm run dev
+# or
+pnpm dev
+# or
+yarn dev
+```
+
+Open http://localhost:3000 with your browser to see the result.
+
+## Explore
+
+In the project, you can see:
+
+- `lib/source.ts`: Code for content source adapter, [`loader()`](https://fumadocs.dev/docs/headless/source-api) provides the interface to access your content.
+- `lib/layout.shared.tsx`: Shared options for layouts, optional but preferred to keep.
+
+| Route | Description |
+| ------------------------- | ------------------------------------------------------ |
+| `app/(home)` | The route group for your landing page and other pages. |
+| `app/docs` | The documentation layout and pages. |
+| `app/api/search/route.ts` | The Route Handler for search. |
+
+### Fumadocs MDX
+
+A `source.config.ts` config file has been included, you can customise different options like frontmatter schema.
+
+Read the [Introduction](https://fumadocs.dev/docs/mdx) for further details.
+
+## Learn More
+
+To learn more about Next.js and Fumadocs, take a look at the following
+resources:
+
+- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js
+ features and API.
+- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
+- [Fumadocs](https://fumadocs.dev) - learn about Fumadocs
diff --git a/fumadocs/app/(home)/layout.tsx b/fumadocs/app/(home)/layout.tsx
new file mode 100644
index 000000000..b8b7d1b90
--- /dev/null
+++ b/fumadocs/app/(home)/layout.tsx
@@ -0,0 +1,77 @@
+import { baseOptions } from '@/lib/layout.shared';
+import type { ReactNode } from 'react';
+import { HomeLayout } from 'fumadocs-ui/layouts/home';
+import { TelescopeIcon } from 'lucide-react';
+
+export default function Layout({ children }: { children: ReactNode }) {
+ return (
+
+
+ ),
+ url: 'https://github.com/statelyai/xstate',
+ external: true,
+ },
+ ]}
+ >
+ {children}
+
+ );
+}
diff --git a/fumadocs/app/(home)/page.tsx b/fumadocs/app/(home)/page.tsx
new file mode 100644
index 000000000..4393163a5
--- /dev/null
+++ b/fumadocs/app/(home)/page.tsx
@@ -0,0 +1,5 @@
+import { redirect } from 'next/navigation';
+
+export default function HomePage() {
+ redirect('/docs');
+}
diff --git a/fumadocs/app/api/chat/route.ts b/fumadocs/app/api/chat/route.ts
new file mode 100644
index 000000000..9952728f6
--- /dev/null
+++ b/fumadocs/app/api/chat/route.ts
@@ -0,0 +1,30 @@
+import { ProvideLinksToolSchema } from '../../../lib/inkeep-qa-schema';
+import { createOpenAICompatible } from '@ai-sdk/openai-compatible';
+import { convertToModelMessages, streamText } from 'ai';
+
+export const runtime = 'edge';
+
+const openai = createOpenAICompatible({
+ name: 'inkeep',
+ apiKey: process.env.INKEEP_API_KEY,
+ baseURL: 'https://api.inkeep.com/v1',
+});
+
+export async function POST(req: Request) {
+ const reqJson = await req.json();
+
+ const result = streamText({
+ model: openai('inkeep-qa-sonnet-4'),
+ tools: {
+ provideLinks: {
+ inputSchema: ProvideLinksToolSchema,
+ },
+ },
+ messages: convertToModelMessages(reqJson.messages, {
+ ignoreIncompleteToolCalls: true,
+ }),
+ toolChoice: 'auto',
+ });
+
+ return result.toUIMessageStreamResponse();
+}
diff --git a/fumadocs/app/api/search/route.ts b/fumadocs/app/api/search/route.ts
new file mode 100644
index 000000000..7ba7e8231
--- /dev/null
+++ b/fumadocs/app/api/search/route.ts
@@ -0,0 +1,7 @@
+import { source } from '@/lib/source';
+import { createFromSource } from 'fumadocs-core/search/server';
+
+export const { GET } = createFromSource(source, {
+ // https://docs.orama.com/docs/orama-js/supported-languages
+ language: 'english',
+});
diff --git a/fumadocs/app/blog/[slug]/page.client.tsx b/fumadocs/app/blog/[slug]/page.client.tsx
new file mode 100644
index 000000000..d88f56be3
--- /dev/null
+++ b/fumadocs/app/blog/[slug]/page.client.tsx
@@ -0,0 +1,24 @@
+'use client';
+import { Check, Share } from 'lucide-react';
+import { cn } from '@/lib/cn';
+import { buttonVariants } from '@/components/ui/button';
+import { useCopyButton } from 'fumadocs-ui/utils/use-copy-button';
+
+export function Control({ url }: { url: string }) {
+ const [isChecked, onCopy] = useCopyButton(() => {
+ void navigator.clipboard.writeText(`${window.location.origin}${url}`);
+ });
+
+ return (
+
+ {isChecked ?
+ );
+}
diff --git a/fumadocs/app/blog/[slug]/page.tsx b/fumadocs/app/blog/[slug]/page.tsx
new file mode 100644
index 000000000..1a3fcb702
--- /dev/null
+++ b/fumadocs/app/blog/[slug]/page.tsx
@@ -0,0 +1,88 @@
+import type { Metadata } from 'next';
+import { notFound } from 'next/navigation';
+import Link from 'next/link';
+import { InlineTOC } from 'fumadocs-ui/components/inline-toc';
+import { blog } from '@/lib/source';
+import { buttonVariants } from '@/components/ui/button';
+import { Control } from '@/app/blog/[slug]/page.client';
+import { getMDXComponents } from '@/mdx-components';
+import path from 'node:path';
+
+export default async function Page(props: PageProps<'/blog/[slug]'>) {
+ const params = await props.params;
+ const page = blog.getPage([params.slug]);
+
+ if (!page) notFound();
+ const { body: Mdx, toc } = page.data;
+
+ return (
+ <>
+
+
+ {page.data.title}
+
+
{page.data.description}
+
+ Back
+
+
+
+
+
+
+
Written by
+
{page.data.authors.join(', ')}
+
+
+
At
+
+ {new Date(
+ page.data.date ??
+ path.basename(page.path, path.extname(page.path)),
+ ).toDateString()}
+
+
+
+
+
+ );
+}
+
+export async function generateMetadata(
+ props: PageProps<'/blog/[slug]'>,
+): Promise {
+ const params = await props.params;
+ const page = blog.getPage([params.slug]);
+
+ if (!page) notFound();
+
+ return {
+ title: page.data.title,
+ description:
+ page.data.description ?? 'The library for building documentation sites',
+ };
+}
+
+export function generateStaticParams(): { slug: string }[] {
+ return blog.getPages().map((page) => ({
+ slug: page.slugs[0],
+ }));
+}
diff --git a/fumadocs/app/blog/layout.tsx b/fumadocs/app/blog/layout.tsx
new file mode 100644
index 000000000..8e9ec7226
--- /dev/null
+++ b/fumadocs/app/blog/layout.tsx
@@ -0,0 +1,11 @@
+import { DocsLayout } from 'fumadocs-ui/layouts/docs';
+import { baseOptions } from '@/lib/layout.shared';
+import { source } from '@/lib/source';
+
+export default function Layout({ children }: LayoutProps<'/docs'>) {
+ return (
+
+ {children}
+
+ );
+}
diff --git a/fumadocs/app/blog/page.tsx b/fumadocs/app/blog/page.tsx
new file mode 100644
index 000000000..3cba584c3
--- /dev/null
+++ b/fumadocs/app/blog/page.tsx
@@ -0,0 +1,64 @@
+import Link from 'next/link';
+import { blog } from '@/lib/source';
+
+export default function Page() {
+ const posts = [...blog.getPages()].sort(
+ (a, b) =>
+ new Date(b.data.date ?? b.file.name).getTime() -
+ new Date(a.data.date ?? a.file.name).getTime(),
+ );
+
+ const svg = `
+
+
+
+ `;
+
+ return (
+
+
+
+ Stately Blog
+
+
+ The latest news and updates from the Stately team
+
+
+ {posts.map((post) => (
+
+
{post.data.title}
+
+ {post.data.description}
+
+
+
+ {new Date(post.data.date ?? post.file.name).toDateString()}
+
+
+ ))}
+
+ );
+}
diff --git a/fumadocs/app/docs/[[...slug]]/page.tsx b/fumadocs/app/docs/[[...slug]]/page.tsx
new file mode 100644
index 000000000..357971e55
--- /dev/null
+++ b/fumadocs/app/docs/[[...slug]]/page.tsx
@@ -0,0 +1,62 @@
+import { getPageImage, source } from '@/lib/source';
+import {
+ DocsBody,
+ DocsDescription,
+ DocsPage,
+ DocsTitle,
+} from 'fumadocs-ui/page';
+import { notFound } from 'next/navigation';
+import { getMDXComponents } from '@/mdx-components';
+import type { Metadata } from 'next';
+import { createRelativeLink } from 'fumadocs-ui/mdx';
+import { LLMCopyButton, ViewOptions } from '@/components/page-actions';
+
+export default async function Page(props: PageProps<'/docs/[[...slug]]'>) {
+ const params = await props.params;
+ const page = source.getPage(params.slug);
+ if (!page) notFound();
+
+ const MDX = page.data.body;
+
+ return (
+
+ {page.data.title}
+ {page.data.description}
+
+
+
+
+
+ );
+}
+
+export async function generateStaticParams() {
+ return source.generateParams();
+}
+
+export async function generateMetadata(
+ props: PageProps<'/docs/[[...slug]]'>,
+): Promise {
+ const params = await props.params;
+ const page = source.getPage(params.slug);
+ if (!page) notFound();
+
+ return {
+ title: page.data.title,
+ description: page.data.description,
+ openGraph: {
+ images: getPageImage(page).url,
+ },
+ };
+}
diff --git a/fumadocs/app/docs/layout.tsx b/fumadocs/app/docs/layout.tsx
new file mode 100644
index 000000000..bac1433aa
--- /dev/null
+++ b/fumadocs/app/docs/layout.tsx
@@ -0,0 +1,576 @@
+import { DocsLayout } from 'fumadocs-ui/layouts/docs';
+import { baseOptions } from '@/lib/layout.shared';
+
+export default function Layout({ children }: LayoutProps<'/docs'>) {
+ return (
+
+ {children}
+
+ );
+}
diff --git a/fumadocs/app/global.css b/fumadocs/app/global.css
new file mode 100644
index 000000000..b6b46defd
--- /dev/null
+++ b/fumadocs/app/global.css
@@ -0,0 +1,85 @@
+@import 'tailwindcss';
+@import 'fumadocs-ui/css/neutral.css';
+@import 'fumadocs-ui/css/preset.css';
+@import 'fumadocs-twoslash/twoslash.css';
+
+@theme {
+ /* Light mode - matching original custom.css colors */
+ --color-fd-background: white;
+ --color-fd-foreground: hsl(240, 4.3%, 17.6%); /* #2d2e34 - st-gray-800 */
+ --color-fd-muted: hsl(240, 5.9%, 94.1%); /* #efeff1 - st-gray-50 */
+ --color-fd-muted-foreground: hsl(
+ 240,
+ 3.8%,
+ 40.4%
+ ); /* #5d5f6a - st-gray-600 */
+ --color-fd-popover: white;
+ --color-fd-popover-foreground: hsl(
+ 240,
+ 4.3%,
+ 17.6%
+ ); /* #2d2e34 - st-gray-800 */
+ --color-fd-card: hsl(240, 5.9%, 94.1%); /* #efeff1 - st-gray-50 */
+ --color-fd-card-foreground: hsl(240, 4.3%, 17.6%); /* #2d2e34 - st-gray-800 */
+ --color-fd-border: hsl(240, 5.9%, 88.2%); /* #e1e2e5 - st-gray-100 */
+ --color-fd-primary: hsl(240, 5.1%, 8.2%); /* #15151d - st-gray-900 */
+ --color-fd-primary-foreground: white;
+ --color-fd-secondary: hsl(240, 5.9%, 94.1%); /* #efeff1 - st-gray-50 */
+ --color-fd-secondary-foreground: hsl(
+ 240,
+ 4.3%,
+ 17.6%
+ ); /* #2d2e34 - st-gray-800 */
+ --color-fd-accent: hsl(240, 5.9%, 88.2%); /* #e1e2e5 - st-gray-100 */
+ --color-fd-accent-foreground: hsl(
+ 240,
+ 4.3%,
+ 17.6%
+ ); /* #2d2e34 - st-gray-800 */
+ --color-fd-ring: hsl(240, 3.7%, 46.1%); /* #757785 - st-gray-500 */
+}
+.dark {
+ /* Dark mode - matching original custom.css colors */
+ --color-fd-background: #15151d; /* #15151d - st-gray-900 */
+ --color-fd-foreground: hsl(240, 4.9%, 78.8%); /* #c6c7cd - st-gray-200 */
+ --color-fd-muted: hsl(240, 4.3%, 17.6%); /* #2d2e34 - st-gray-800 */
+ --color-fd-muted-foreground: hsl(
+ 240,
+ 3.7%,
+ 58.2%
+ ); /* #8f919d - st-gray-400 */
+ --color-fd-popover: hsl(240, 4.3%, 17.6%); /* #2d2e34 - st-gray-800 */
+ --color-fd-popover-foreground: hsl(
+ 240,
+ 4.9%,
+ 78.8%
+ ); /* #c6c7cd - st-gray-200 */
+ --color-fd-card: #15151d; /* #2d2e34 - st-gray-800 */
+ --color-fd-card-foreground: hsl(240, 5.9%, 96.1%); /* #efeff1 - st-gray-50 */
+ --color-fd-border: hsl(240, 3.4%, 28.6%); /* #45464f - st-gray-700 */
+ --color-fd-primary: hsl(240, 5.9%, 96.1%); /* #efeff1 - st-gray-50 */
+ --color-fd-primary-foreground: hsl(
+ 240,
+ 5.1%,
+ 8.2%
+ ); /* #15151d - st-gray-900 */
+ --color-fd-secondary: hsl(240, 4.3%, 17.6%); /* #2d2e34 - st-gray-800 */
+ --color-fd-secondary-foreground: hsl(
+ 240,
+ 4.9%,
+ 78.8%
+ ); /* #c6c7cd - st-gray-200 */
+ --color-fd-accent: hsl(240, 3.4%, 28.6%); /* #45464f - st-gray-700 */
+ --color-fd-accent-foreground: hsl(
+ 240,
+ 5.9%,
+ 96.1%
+ ); /* #efeff1 - st-gray-50 */
+ --color-fd-ring: hsl(240, 3.7%, 46.1%); /* #757785 - st-gray-500 */
+}
+
+.prose {
+ svg {
+ display: inline-block;
+ }
+}
diff --git a/fumadocs/app/layout.tsx b/fumadocs/app/layout.tsx
new file mode 100644
index 000000000..0b9d76415
--- /dev/null
+++ b/fumadocs/app/layout.tsx
@@ -0,0 +1,17 @@
+import '@/app/global.css';
+import { RootProvider } from 'fumadocs-ui/provider/next';
+import { Inter } from 'next/font/google';
+
+const inter = Inter({
+ subsets: ['latin'],
+});
+
+export default function Layout({ children }: LayoutProps<'/'>) {
+ return (
+
+
+ {children}
+
+
+ );
+}
diff --git a/fumadocs/app/llms-full.txt/route.ts b/fumadocs/app/llms-full.txt/route.ts
new file mode 100644
index 000000000..d494d2cbb
--- /dev/null
+++ b/fumadocs/app/llms-full.txt/route.ts
@@ -0,0 +1,10 @@
+import { getLLMText, source } from '@/lib/source';
+
+export const revalidate = false;
+
+export async function GET() {
+ const scan = source.getPages().map(getLLMText);
+ const scanned = await Promise.all(scan);
+
+ return new Response(scanned.join('\n\n'));
+}
diff --git a/fumadocs/app/llms.mdx/[[...slug]]/route.ts b/fumadocs/app/llms.mdx/[[...slug]]/route.ts
new file mode 100644
index 000000000..c029b0f44
--- /dev/null
+++ b/fumadocs/app/llms.mdx/[[...slug]]/route.ts
@@ -0,0 +1,24 @@
+import { getLLMText } from '@/lib/get-llm-text';
+import { source } from '@/lib/source';
+import { notFound } from 'next/navigation';
+
+export const revalidate = false;
+
+export async function GET(
+ _req: Request,
+ { params }: RouteContext<'/llms.mdx/[[...slug]]'>,
+) {
+ const { slug } = await params;
+ const page = source.getPage(slug);
+ if (!page) notFound();
+
+ return new Response(await getLLMText(page), {
+ headers: {
+ 'Content-Type': 'text/markdown',
+ },
+ });
+}
+
+export function generateStaticParams() {
+ return source.generateParams();
+}
diff --git a/fumadocs/app/middleware.ts b/fumadocs/app/middleware.ts
new file mode 100644
index 000000000..826a697b0
--- /dev/null
+++ b/fumadocs/app/middleware.ts
@@ -0,0 +1,12 @@
+import { NextRequest, NextResponse } from 'next/server';
+import { isMarkdownPreferred, rewritePath } from 'fumadocs-core/negotiation';
+const { rewrite: rewriteLLM } = rewritePath('/docs/*path', '/llms.mdx/*path');
+export function middleware(request: NextRequest) {
+ if (isMarkdownPreferred(request)) {
+ const result = rewriteLLM(request.nextUrl.pathname);
+ if (result) {
+ return NextResponse.rewrite(new URL(result, request.nextUrl));
+ }
+ }
+ return NextResponse.next();
+}
diff --git a/fumadocs/app/og/docs/[...slug]/route.tsx b/fumadocs/app/og/docs/[...slug]/route.tsx
new file mode 100644
index 000000000..f5df96dbc
--- /dev/null
+++ b/fumadocs/app/og/docs/[...slug]/route.tsx
@@ -0,0 +1,36 @@
+import { getPageImage, source } from '@/lib/source';
+import { notFound } from 'next/navigation';
+import { ImageResponse } from 'next/og';
+import { generate as DefaultImage } from 'fumadocs-ui/og';
+
+export const revalidate = false;
+
+export async function GET(
+ _req: Request,
+ { params }: RouteContext<'/og/docs/[...slug]'>,
+) {
+ const { slug } = await params;
+ const page = source.getPage(slug.slice(0, -1));
+ if (!page) notFound();
+
+ return new ImageResponse(
+ (
+ ;
+}
+
+export function rehypeWrapWords() {
+ return (tree: Root) => {
+ visit(tree, ['text', 'element'], (node, index, parent) => {
+ if (node.type === 'element' && node.tagName === 'pre') return 'skip';
+ if (node.type !== 'text' || !parent || index === undefined) return;
+
+ const words = node.value.split(/(?=\s)/);
+
+ // Create new span nodes for each word and whitespace
+ const newNodes: ElementContent[] = words.flatMap((word) => {
+ if (word.length === 0) return [];
+
+ return {
+ type: 'element',
+ tagName: 'span',
+ properties: {
+ class: 'animate-fd-fade-in',
+ },
+ children: [{ type: 'text', value: word }],
+ };
+ });
+
+ Object.assign(node, {
+ type: 'element',
+ tagName: 'span',
+ properties: {},
+ children: newNodes,
+ } satisfies RootContent);
+ return 'skip';
+ });
+ };
+}
+
+function createProcessor(): Processor {
+ const processor = remark()
+ .use(remarkGfm)
+ .use(remarkRehype)
+ .use(rehypeWrapWords);
+
+ return {
+ async process(content) {
+ const nodes = processor.parse({ value: content });
+ const hast = await processor.run(nodes);
+
+ return toJsxRuntime(hast, {
+ development: false,
+ jsx,
+ jsxs,
+ Fragment,
+ components: {
+ ...defaultMdxComponents,
+ pre: Pre,
+ img: undefined, // use JSX
+ },
+ });
+ },
+ };
+}
+
+function Pre(props: ComponentProps<'pre'>) {
+ const code = Children.only(props.children) as ReactElement;
+ const codeProps = code.props as ComponentProps<'code'>;
+ const content = codeProps.children;
+ if (typeof content !== 'string') return null;
+
+ let lang =
+ codeProps.className
+ ?.split(' ')
+ .find((v) => v.startsWith('language-'))
+ ?.slice('language-'.length) ?? 'text';
+
+ if (lang === 'mdx') lang = 'md';
+
+ return {text}
}>
+ >();
+
+function Renderer({ text }: { text: string }) {
+ const result = cache.get(text) ?? processor.process(text);
+ cache.set(text, result);
+
+ return use(result);
+}
diff --git a/fumadocs/components/page-actions.tsx b/fumadocs/components/page-actions.tsx
new file mode 100644
index 000000000..63ccf70cd
--- /dev/null
+++ b/fumadocs/components/page-actions.tsx
@@ -0,0 +1,247 @@
+'use client';
+import { useMemo, useState } from 'react';
+import {
+ Check,
+ ChevronDown,
+ Copy,
+ ExternalLinkIcon,
+ MessageCircleIcon,
+} from 'lucide-react';
+import { cn } from '../lib/cn';
+import { useCopyButton } from 'fumadocs-ui/utils/use-copy-button';
+import { buttonVariants } from './ui/button';
+import {
+ Popover,
+ PopoverContent,
+ PopoverTrigger,
+} from 'fumadocs-ui/components/ui/popover';
+import { cva } from 'class-variance-authority';
+
+const cache = new Map();
+
+export function LLMCopyButton({
+ /**
+ * A URL to fetch the raw Markdown/MDX content of page
+ */
+ markdownUrl,
+}: {
+ markdownUrl: string;
+}) {
+ const [isLoading, setLoading] = useState(false);
+ const [checked, onClick] = useCopyButton(async () => {
+ const cached = cache.get(markdownUrl);
+ if (cached) return navigator.clipboard.writeText(cached);
+
+ setLoading(true);
+
+ try {
+ await navigator.clipboard.write([
+ new ClipboardItem({
+ 'text/plain': fetch(markdownUrl).then(async (res) => {
+ const content = await res.text();
+ cache.set(markdownUrl, content);
+
+ return content;
+ }),
+ }),
+ ]);
+ } finally {
+ setLoading(false);
+ }
+ });
+
+ return (
+
+ {checked ?
+ );
+}
+
+const optionVariants = cva(
+ 'text-sm p-2 rounded-lg inline-flex items-center gap-2 hover:text-fd-accent-foreground hover:bg-fd-accent [&_svg]:size-4',
+);
+
+export function ViewOptions({
+ markdownUrl,
+ githubUrl,
+}: {
+ /**
+ * A URL to the raw Markdown/MDX content of page
+ */
+ markdownUrl: string;
+
+ /**
+ * Source file URL on GitHub
+ */
+ githubUrl: string;
+}) {
+ const items = useMemo(() => {
+ const fullMarkdownUrl =
+ typeof window !== 'undefined'
+ ? new URL(markdownUrl, window.location.origin)
+ : 'loading';
+ const q = `Read ${fullMarkdownUrl}, I want to ask questions about it.`;
+
+ return [
+ {
+ title: 'Open in GitHub',
+ href: githubUrl,
+ icon: (
+
+ GitHub
+
+ ),
+ },
+ {
+ title: 'Open in Scira AI',
+ href: `https://scira.ai/?${new URLSearchParams({
+ q,
+ })}`,
+ icon: (
+
+ Scira AI
+
+ ),
+ },
+ {
+ title: 'Open in ChatGPT',
+ href: `https://chatgpt.com/?${new URLSearchParams({
+ hints: 'search',
+ q,
+ })}`,
+ icon: (
+
+ OpenAI
+
+ ),
+ },
+ {
+ title: 'Open in Claude',
+ href: `https://claude.ai/new?${new URLSearchParams({
+ q,
+ })}`,
+ icon: (
+
+ Anthropic
+
+ ),
+ },
+ {
+ title: 'Open in T3 Chat',
+ href: `https://t3.chat/new?${new URLSearchParams({
+ q,
+ })}`,
+ icon:
+
+ Open
+
+
+ {items.map((item) => (
+
+ {item.icon}
+ {item.title}
+
+ ))}
+
+
+ );
+}
diff --git a/fumadocs/components/search.tsx b/fumadocs/components/search.tsx
new file mode 100644
index 000000000..42ab84d10
--- /dev/null
+++ b/fumadocs/components/search.tsx
@@ -0,0 +1,385 @@
+'use client';
+import { RemoveScroll } from 'react-remove-scroll';
+import {
+ type ComponentProps,
+ createContext,
+ type SyntheticEvent,
+ use,
+ useEffect,
+ useMemo,
+ useRef,
+ useState,
+} from 'react';
+import { Loader2, RefreshCw, SearchIcon, Send, X } from 'lucide-react';
+import { cn } from '../lib/cn';
+import { buttonVariants } from './ui/button';
+import Link from 'fumadocs-core/link';
+import { type UIMessage, useChat, type UseChatHelpers } from '@ai-sdk/react';
+import type { ProvideLinksToolSchema } from '../lib/inkeep-qa-schema';
+import type { z } from 'zod';
+import { DefaultChatTransport } from 'ai';
+import { Markdown } from './markdown';
+import { Presence } from '@radix-ui/react-presence';
+
+const Context = createContext<{
+ open: boolean;
+ setOpen: (open: boolean) => void;
+ chat: UseChatHelpers;
+} | null>(null);
+
+function useChatContext() {
+ return use(Context)!.chat;
+}
+
+function SearchAIActions() {
+ const { messages, status, setMessages, regenerate } = useChatContext();
+ const isLoading = status === 'streaming';
+
+ if (messages.length === 0) return null;
+
+ return (
+ <>
+ {!isLoading && messages.at(-1)?.role === 'assistant' && (
+ regenerate()}
+ >
+
+ )}
+ setMessages([])}
+ >
+ Clear Chat
+
+
+ );
+}
+
+function SearchAIInput(props: ComponentProps<'form'>) {
+ const { status, sendMessage, stop } = useChatContext();
+ const [input, setInput] = useState('');
+ const isLoading = status === 'streaming' || status === 'submitted';
+ const onStart = (e?: SyntheticEvent) => {
+ e?.preventDefault();
+ void sendMessage({ text: input });
+ setInput('');
+ };
+
+ useEffect(() => {
+ if (isLoading) document.getElementById('nd-ai-input')?.focus();
+ }, [isLoading]);
+
+ return (
+
+ );
+}
+
+function List(props: Omit, 'dir'>) {
+ const containerRef = useRef(null);
+
+ useEffect(() => {
+ if (!containerRef.current) return;
+ function callback() {
+ const container = containerRef.current;
+ if (!container) return;
+
+ container.scrollTo({
+ top: container.scrollHeight,
+ behavior: 'instant',
+ });
+ }
+
+ const observer = new ResizeObserver(callback);
+ callback();
+
+ const element = containerRef.current?.firstElementChild;
+
+ if (element) {
+ observer.observe(element);
+ }
+
+ return () => {
+ observer.disconnect();
+ };
+ }, []);
+
+ return (
+
+ {props.children}
+
+ );
+}
+
+function Input(props: ComponentProps<'textarea'>) {
+ const ref = useRef(null);
+ const shared = cn('col-start-1 row-start-1', props.className);
+
+ return (
+
+
+
+ {`${props.value?.toString() ?? ''}\n`}
+
+
= {
+ user: 'you',
+ assistant: 'fumadocs',
+};
+
+function Message({
+ message,
+ ...props
+}: { message: UIMessage } & ComponentProps<'div'>) {
+ let markdown = '';
+ let links: z.infer['links'] = [];
+
+ for (const part of message.parts ?? []) {
+ if (part.type === 'text') {
+ markdown += part.text;
+ continue;
+ }
+
+ if (part.type === 'tool-provideLinks' && part.input) {
+ links = (part.input as z.infer).links;
+ }
+ }
+
+ return (
+
+
+ {roleName[message.role] ?? 'unknown'}
+
+
+
+ {links && links.length > 0 ? (
+
+ {links.map((item, i) => (
+
+
{item.title}
+
Reference {item.label}
+
+ ))}
+
+ ) : null}
+
({ chat, open, setOpen }), [chat, open])}>
+
+
+ {
+ if (e.target === e.currentTarget) {
+ setOpen(false);
+ e.preventDefault();
+ }
+ }}
+ >
+
+
+ Powered by Inkeep AI
+
+
setOpen(false)}
+ >
+
+
+
+
+ {chat.messages
+ .filter((msg) => msg.role !== 'system')
+ .map((item) => (
+
+
+
+
+
+ setOpen(true)}
+ >
+
+
+
+
+
+
+
+ );
+}
diff --git a/fumadocs/components/ui/button.tsx b/fumadocs/components/ui/button.tsx
new file mode 100644
index 000000000..b427d4e08
--- /dev/null
+++ b/fumadocs/components/ui/button.tsx
@@ -0,0 +1,28 @@
+import { cva, type VariantProps } from 'class-variance-authority';
+
+const variants = {
+ primary: 'bg-fd-primary text-fd-primary-foreground hover:bg-fd-primary/80',
+ outline: 'border hover:bg-fd-accent hover:text-fd-accent-foreground',
+ ghost: 'hover:bg-fd-accent hover:text-fd-accent-foreground',
+ secondary:
+ 'border bg-fd-secondary text-fd-secondary-foreground hover:bg-fd-accent hover:text-fd-accent-foreground',
+} as const;
+
+export const buttonVariants = cva(
+ 'inline-flex items-center justify-center rounded-md p-2 text-sm font-medium transition-colors duration-100 disabled:pointer-events-none disabled:opacity-50 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-fd-ring',
+ {
+ variants: {
+ variant: variants,
+ // fumadocs use `color` instead of `variant`
+ color: variants,
+ size: {
+ sm: 'gap-1 px-2 py-1.5 text-xs',
+ icon: 'p-1.5 [&_svg]:size-5',
+ 'icon-sm': 'p-1.5 [&_svg]:size-4.5',
+ 'icon-xs': 'p-1 [&_svg]:size-4',
+ },
+ },
+ },
+);
+
+export type ButtonProps = VariantProps;
diff --git a/fumadocs/content/blog/2019-11-13-no-disabling-a-button-is-not-app-logic/index.mdx b/fumadocs/content/blog/2019-11-13-no-disabling-a-button-is-not-app-logic/index.mdx
new file mode 100644
index 000000000..0153548e9
--- /dev/null
+++ b/fumadocs/content/blog/2019-11-13-no-disabling-a-button-is-not-app-logic/index.mdx
@@ -0,0 +1,549 @@
+---
+title: 'No, disabling a button is not app logic.'
+description: >-
+ Disabling a button is not logic. Rather, it is a sign that logic is fragile
+ and bug-prone. Let’s explore this with a simple example: fetching data in a
+ React component.
+tags: [data fetching, state machine, statechart, state, business logic]
+authors: [david]
+image: /blog/2019-11-13-no-disabling-a-button-is-not-app-logic.png
+slug: 2019-11-13-no-disabling-a-button-is-not-app-logic
+date: 2019-11-13
+---
+
+
+
+
{dog &&
+
+
{
+ setIsLoading(true);
+ fetch(`https://dog.ceo/api/breeds/image/random`)
+ .then((data) => data.json())
+ .then((response) => {
+ setDog(response.message);
+ setIsLoading(false);
+ });
+ }}
+ >
+ {isLoading ? 'Fetching...' : 'Fetch dog!'}
+
+
{
+ // ... excessive amount of ad-hoc logic
+ }}
+ disabled={isLoading}
+ >
+ {isLoading ? 'Fetching...' : 'Fetch dog!'}
+ ;
+
+ // ...
+}
+```
+
+This also works; you’re probably satisfied with this solution. Allow me to burst this bubble.
+
+## What can possibly go wrong?
+
+Currently, the logic reads like this:
+
+> When the button is clicked, fetch a new random dog, and set a flag to make sure that the button cannot be clicked again to fetch a dog while one is being fetched.
+
+However, the logic you _really_ want is this:
+
+> When a new dog is requested, fetch it and make sure that another dog can’t be fetched at the same time.
+
+See the difference? The desired logic is completely separate from the button being clicked; it doesn’t matter _how_ the request is made; it only matters what logic happens afterwards.
+
+Suppose that you want to add the feature that double-clicking the image loads a new dog. What would you have to do?
+
+It’s all too easy to forget to add the same “guard” logic on `figure` (after all, `` won’t work, go figure), but let’s say you’re an astute developer who remembers to add this logic:
+
+```ts
+ function DogFetcher() {
+ // ...
+
+ {
+ if (isLoading) return;
+
+ // copy-paste the fetch logic from the button onClick handler
+ }}
+ >
+ {/* ... */}
+
+
+ // ...
+
+ {
+ // fetch logic
+ }}
+ disabled={isLoading}
+ >
+ {/* ... */}
+
+
+ // ...
+ }
+```
+
+In reality, you can think about this as any use-case where some sort of “trigger” can happen from multiple locations, such as:
+
+- a form being able to be submitted by pressing “Enter” in an input or clicking the “Submit” button
+- an event being triggered by a user action _or_ a timeout
+- any app logic that needs to be shared between different platforms with different event-handling implementations (think React Native)
+
+But there’s a code smell here. Our same fetch logic is implemented in more than one place, and understanding the app logic requires developers to jump around in multiple parts of the code base, finding all of the event handlers where there are tidbits of logic and connecting them together mentally.
+
+## DRYing up the splashes of logic
+
+Okay, so putting logic in our event handlers is probably not a good idea, but we can’t exactly put our finger on the reason why yet. Let’s move the fetch logic out into a function:
+
+```ts
+function DogFetcher() {
+ const [isLoading, setIsLoading] = useState(false);
+ const [dog, setDog] = useState(null);
+
+ function fetchDog() {
+ if (isLoading) return;
+
+ setIsLoading(true);
+ fetch(`https://dog.ceo/api/breeds/image/random`)
+ .then((data) => data.json())
+ .then((response) => {
+ setDog(response.message);
+ setIsLoading(false);
+ });
+ }
+
+ return (
+
+
+ {dog &&
+
+
+ {isLoading ? 'Fetching...' : 'Fetch dog!'}
+
+
+ {error &&
{error} }
+
+ {dog &&
+
+
+ {isLoading ? 'Fetching...' : 'Fetch dog!'}
+
+
Cancel
+
+ {error &&
{error} }
+
dispatch({ type: 'FETCH' })}>
+ {dog &&
+
+
dispatch({ type: 'FETCH' })}>
+ {status === 'loading' ? 'Fetching...' : 'Fetch dog!'}
+
+
dispatch({ type: 'CANCEL' })}>Cancel
+
` attribute. In fact, we completely forgot to do so anyway, and the logic still works!
+
+This is how you know your logic is robust; when it works, regardless of the UI. Whether the “Fetch dog” button is disabled or not, clicking it multiple times in a row won’t exhibit any unexpected behavior.
+
+Also, because most of the logic is delegated to a `dogReducer` function defined _outside_ of your component, it is:
+
+- easy to make into a custom hook
+- easy to test
+- easy to reuse in other components
+- easy to reuse in other _frameworks_
+
+## The final result
+
+Change the `
+ {error &&
{error} }
+
send('FETCH')}>
+ {dog &&
+
+
send('FETCH')}>
+ {current.matches('loading') && 'Fetching...'}
+ {current.matches('success') && 'Fetch another dog!'}
+ {current.matches('idle') && 'Fetch dog'}
+ {current.matches('failure') && 'Try again'}
+
+
send('CANCEL')}>Cancel
+
` is fragile is because we admit that some “FETCH” event can cause an effect no matter which state we’re in, so we have to clean up our ~mess~ faulty logic by preventing the user from clicking the button while loading.
+
+Instead, it’s better to be proactive about your logic. Fetching should only happen when the app is not in some `"loading"` state, which is what is clearly defined in the state machine -- the `"FETCH"` event is not handled in the `"loading"` state, which means it has no effect. Perfect.
+
+## Final points
+
+Disabling a button is not logic. Rather, it is a sign that logic is fragile and bug-prone. In my opinion, disabling a button should only be a visual cue to the user that clicking the button _will have no effect_.
+
+So when you’re creating fetching logic (or any other kind of complex logic) in your applications, no matter the framework, ask yourself these questions:
+
+- What are the concrete, finite states this app/component can be in? E.g., "loading", "success", "idle", "failure", etc.
+- What are all the possible events that can occur, regardless of state? This includes events that don't come from the user (such as `"RESOLVE"` or `"REJECT"` events from promises)
+- Which of the finite states should handle these events?
+- How can I organize my app logic so that these events are handled properly in those states?
+
+You do not need a state machine library (like XState) to do this. In fact, you might not even need `useReducer` when you’re first adopting these principles. Even something as simple as having a state variable representing a finite state can already clean up your logic plenty:
+
+```ts
+function DogFetcher() {
+ // 'idle' or 'loading' or 'success' or 'error'
+ const [status, setStatus] = useState('idle');
+}
+```
+
+And just like that, you’ve eliminated `isLoading`, `isError`, `isSuccess`, `startedLoading`, and whatever Boolean flags you were going to create. And if you really start to miss that `isLoading` flag (for whatever reason), you can still have it, but ONLY if it’s derived from your organized, finite states. The `isLoading` variable should NEVER be a primary source of state:
+
+```ts
+function DogFetcher() {
+ // 'idle' or 'loading' or 'success' or 'error'
+ const [status, setStatus] = useState('idle');
+
+ const isLoading = status === 'loading';
+
+ return (
+ // ...
+ {/* ... */}
+ // ...
+ );
+}
+```
+
+And we’ve come full circle. Thanks for reading.
diff --git a/fumadocs/content/blog/2019-12-09-xstate-version-47-and-the-future/index.mdx b/fumadocs/content/blog/2019-12-09-xstate-version-47-and-the-future/index.mdx
new file mode 100644
index 000000000..edfec2755
--- /dev/null
+++ b/fumadocs/content/blog/2019-12-09-xstate-version-47-and-the-future/index.mdx
@@ -0,0 +1,258 @@
+---
+title: 'XState: version 4.7 and the future'
+description: >-
+ XState version 4.7 has just been released. This is a minor version bump, but a
+ major reworking of the internal algorithms, a lot of new capabilites, bug
+ fixes and a better TypeScript experience.
+tags: [update, state machine, statechart, xstate, state]
+authors: [david]
+image: /blog/2019-12-09-xstate-version-47-and-the-future.png
+slug: 2019-12-09-xstate-version-47-and-the-future
+date: 2019-12-09
+---
+
+
+
+ {children}
+
+ );
+};
+
+export const useCartContext = () => {
+ return useContext(CartContext);
+};
+```
+
+And then use it in your components:
+
+```jsx
+const CartView = () => {
+ const [state, dispatch] = useCartContext();
+
+ // ...
+};
+```
+
+Not too bad, right? In general, this is not a problem that can be solved in Redux without going against-the-grain, since Redux is fundamentally a single, atomic global store.
+
+## What do others think?
+
+I ran a non-scientific poll on Twitter to see where most app state lives, and how developers feel about it:
+
+Loading...
;
+}
+```
+
+The reason these are good booleans is that their underlying mechanism is based on an enum. Bad booleans represent state. Good booleans are derived from state:
+
+```js
+let status: Status = 'loading';
+
+// Derived from the status above
+let isLoading = status === 'loading';
+```
+
+You can safely use this `isLoading` to display your loading spinner, happy in the knowledge that you've removed all impossible states.
+
+## Addendum: Enums in Javascript
+
+We can represent a state enum in Javascript as well. While the above code will work without typings, you can represent enums as an object type.
+
+```ts
+const statusEnum = {
+ loading: 'loading',
+ complete: 'complete',
+ errored: 'errored',
+};
+
+let status = statusEnum.loading;
+
+const makeFetch = async () => {
+ status = statusEnum.loading;
+ try {
+ await fetch('/users');
+
+ status = statusEnum.complete;
+ } catch (e) {
+ status = statusEnum.errored;
+ }
+};
+```
diff --git a/fumadocs/content/blog/2020-07-27-state-machines-how-to-stop-making-horcruxes-in-your-code/index.mdx b/fumadocs/content/blog/2020-07-27-state-machines-how-to-stop-making-horcruxes-in-your-code/index.mdx
new file mode 100644
index 000000000..04ffbb9db
--- /dev/null
+++ b/fumadocs/content/blog/2020-07-27-state-machines-how-to-stop-making-horcruxes-in-your-code/index.mdx
@@ -0,0 +1,116 @@
+---
+title: 'State machines: How to stop making Horcruxes in your code'
+description: >-
+ There are several ways of mitigating horcruxes. But visualisations can prevent
+ bugs, so why not go further?
+tags: [business logic, xstate, statechart, useReducer]
+authors: [matt]
+image: /blog/2020-07-27-state-machines-how-to-stop-making-horcruxes-in-your-code.png
+slug: 2020-07-27-state-machines-how-to-stop-making-horcruxes-in-your-code
+date: 2020-07-27
+---
+
+
+ dispatch({ type: 'OPEN' })}>Open Modal ;
+```
+
+If you want to know what happens when you dispatch the `OPEN` action, you only need look in one place: the `modalReducer`. This part of your app is easy to keep bug-free, because all the logic for how it works is contained in one place.
+
+But let’s say that requirements change. Now, before you open the modal you’ll need to fetch something from the API to check if you can open it. This seems intuitive enough:
+
+```ts
+ const [state, dispatch] = useReducer(modalReducer);
+
+ {
+ const canOpenTheModal = await checkIfUserCanOpenIt();
+ if (canOpenTheModal) {
+ dispatch({ type: 'OPEN' });
+ }
+ }>
+ Open Modal
+
+```
+
+The `onClick` handler is now making the API check to see if it should open the modal. If there’s a bug with the way the modal opens, there are now two places you need to check, the reducer and the event handler.
+
+The soul of your business logic has been split. Just like that, you made a Horcrux.
+
+## Going beyond usual evil
+
+The first Horcrux is never really the issue. You can survive one or two splits in your business logic. The trouble comes when you reach six or seven, split out over several 800-line files. I have wept over classes with dozens of methods, sequences with dozens of asynchronous steps.
+
+Logic split into more than one place cannot be visualised. If it can’t be visualised, it can’t be modified, deleted or extended safely.
+
+Let me make this plain: **Any code that cannot be concretely visualised will, at some point, result in a bug.**
+
+There are several ways of mitigating horcruxes. You can push to make your code more readable, writing clean event handlers which don’t contain any logic. You can try to colocate as much as your logic as possible, for instance using [ducks](https://github.com/erikras/ducks-modular-redux) patterns.
+
+But now we know that visualisation can prevent bugs, why not go further?
+
+## Statecharts
+
+I recently embarked on the most complex task I’d ever attempted as a developer - building a video chat app with multiple third-party integrations. Most of the business logic would take place on a single page - the chat portal. I needed to handle multiple user types, chat, notifications, input changes... And many more things.
+
+I’d been using [XState](https://github.com/davidkpiano/xstate), and read that it could be used for visualising complex behaviours, such as Ryan Florence’s checkout:
+
+({});
+
+const ParentComponent = () => {
+ /**
+ * We instantiate the service here...
+ */
+ const [state, send, service] = useMachine(machine);
+
+ return ;
+}
+
+const ChildComponent = (props: ChildComponentProps) => {
+ /**
+ * ...and receive it here
+ */
+ const [state, send] = useService(props.service);
+
+ return (
+ send('TOGGLE')}>
+ {state.matches('open') ? 'Open' : 'Closed'}
+
+ );
+};
+```
+
+I don’t like this pattern. For someone not used to XState, it’s unclear what a ‘service’ is. We don’t get clarity from reading the types, which is a particularly ugly `Interpreter` with multiple generics.
+
+The machine appears to bleed across multiple components. Its service seems to have a life of its own, outside of React's tree. To a newbie, this feels like misdirection.
+
+#### Just pass props
+
+This can be expressed much more cleanly using props:
+
+```ts
+import { useMachine } from '@xstate/react';
+import { createMachine } from 'xstate';
+
+/**
+ * Types for the machine declaration
+ */
+type MachineContext = {};
+type MachineEvent = { type: 'TOGGLE' };
+
+const machine = createMachine({});
+
+const ParentComponent = () => {
+ const [state, send] = useMachine(machine);
+
+ return (
+ send('TOGGLE')}
+ />
+ );
+};
+
+/**
+ * Note that the props declarations are
+ * much more specific
+ */
+interface ChildComponentProps {
+ isOpen: boolean;
+ toggle: () => void;
+}
+
+const ChildComponent = (props: ChildComponentProps) => {
+ return (
+ props.toggle()}>
+ {props.isOpen ? 'Open' : 'Closed'}
+
+ );
+};
+```
+
+Much better. We get several improvements in clarity in the `ChildComponent` - the types are much easier to read. We get to ditch the use of `Interpreter` and `useService` entirely.
+
+The best improvement, though, is in the `ParentComponent`. In the previous example, the machine crossed multiple components by passing its service around. In this example, it’s scoped to the component, and props are derived from its state. This is far easier to grok for someone unused to XState.
+
+### Keep state as local as possible
+
+Unlike tools which require a global store, XState has no opinion on where you keep your state. If you have a piece of state which belongs near the root of your app, you can use React Context to make it globally available:
+
+```ts
+import React, { createContext } from 'react';
+import { useMachine } from '@xstate/react';
+import { createMachine } from 'xstate';
+
+const globalMachine = createMachine({});
+
+interface GlobalContextType {
+ isOpen: boolean;
+ toggle: () => void;
+}
+
+export const GlobalContext = createContext();
+
+const Provider: React.FC = ({ children }) => {
+ const [state, send] = useMachine(globalMachine);
+
+ return (
+ send('TOGGLE') }}
+ >
+ {children}
+
+ );
+};
+```
+
+_Just as above, we’re not passing a service, but props, into context._
+
+If you have a piece of state which needs to belong lower in your tree, then obey the usual rules by [lifting state up](https://reactjs.org/docs/lifting-state-up.html) to where it’s needed.
+
+If that feels familiar, you’re right. You’re making the same decisions you’re used to: where to store state and how to pass it around.
+
+## Examples and challenges
+
+### Syncing parents and children
+
+Sometimes, you need to use a parent machine _and_ a child machine. Let’s say that you need the child to pay attention to when a prop changes from the parent - for instance to sync some data. Here’s how you can do it:
+
+```ts
+const machine = createMachine({
+ initial: 'open',
+ context: {
+ numberToStore: 0,
+ },
+ on: {
+ /**
+ * When REPORT_NEW_NUMBER occurs, sync
+ * the new number to context
+ */
+ REPORT_NEW_NUMBER: {
+ actions: [
+ assign((context, event) => {
+ return {
+ numberToStore: event.newNumber,
+ };
+ }),
+ ],
+ },
+ },
+});
+
+interface ChildComponentProps {
+ someNumber: number;
+}
+
+const ChildComponent = (props: ChildComponentProps) => {
+ const [state, send] = useMachine(machine);
+
+ useEffect(() => {
+ send({
+ type: 'REPORT_NEW_NUMBER',
+ newNumber: props.someNumber,
+ });
+ }, [props.someNumber]);
+};
+```
+
+This can also be used to sync data from other sources, such as query hooks:
+
+```ts
+const ChildComponent = () => {
+ const [result] = useSomeDataHook(() => fetchNumber());
+
+ const [state, send] = useMachine(machine);
+
+ useEffect(() => {
+ send({
+ type: 'REPORT_NEW_NUMBER',
+ newNumber: result.data.someNumber,
+ });
+ }, [result.data.someNumber]);
+};
+```
+
+## Summary
+
+In the “just use props” approach, XState lets React take charge. We stick to idiomatic React by passing props, not services. We keep machines scoped to components. And we put state at the level it’s needed, just like you’re used to.
+
+This article isn’t finished. I’m sure there will be many more questions about integrating XState with React. My plan is to come back to this article again with more examples and clarifications. Thanks for your time, and I’m looking forward to seeing what you build with XState.
diff --git a/fumadocs/content/blog/2021-01-20-you-dont-need-a-library-for-state-machines/index.mdx b/fumadocs/content/blog/2021-01-20-you-dont-need-a-library-for-state-machines/index.mdx
new file mode 100644
index 000000000..79c4ed08d
--- /dev/null
+++ b/fumadocs/content/blog/2021-01-20-you-dont-need-a-library-for-state-machines/index.mdx
@@ -0,0 +1,382 @@
+---
+title: You don’t need a library for state machines
+description: >-
+ Do you need a library to create and interpret state machines in your programs?
+ No. But there are more things to consider.
+tags: [finite state machine, statechart, xstate, state machine]
+authors: [david]
+image: /blog/2021-01-20-you-dont-need-a-library-for-state-machines.png
+slug: 2021-01-20-you-dont-need-a-library-for-state-machines
+date: 2021-01-20
+---
+
+
+ ({ ...config });
+```
+
+Whereas `createMachine` asks you to insert it at the end:
+
+```ts
+import { createMachine } from 'xstate';
+
+interface Context {}
+
+type Event = { type: 'EVENT_NAME' };
+
+type States = {};
+
+const machine = createMachine({ ...config });
+```
+
+Whichever you choose, there is _no functional difference in the created machine_. The two functions reference the same code, and create the machine in the same way.
+
+## What should I choose?
+
+Going forward, you should use `createMachine`. That’s the syntax that will be preferred when v5 releases. But if you're happy with Machine, you can keep using it.
diff --git a/fumadocs/content/blog/2021-04-29-should-this-be-a-state-or-in-context/index.mdx b/fumadocs/content/blog/2021-04-29-should-this-be-a-state-or-in-context/index.mdx
new file mode 100644
index 000000000..89f833dc7
--- /dev/null
+++ b/fumadocs/content/blog/2021-04-29-should-this-be-a-state-or-in-context/index.mdx
@@ -0,0 +1,154 @@
+---
+title: 'Should this be a state, or in context?'
+description: How to decide when to use state or context.
+tags: [context, state machine, xstate, state]
+authors: [matt]
+image: /blog/2021-04-29-should-this-be-a-state-or-in-context.png
+slug: 2021-04-29-should-this-be-a-state-or-in-context
+date: 2021-04-29
+---
+
+State machines offer several API’s for expressing state. Like other tools, you can keep arbitrary values in a store (usually expressed as an object) called `context`.
+
+{/* truncate */}
+
+This is handy for values which change over time and you need to keep updated, like the value of a form input:
+
+```ts
+import { createMachine, assign } from 'xstate';
+
+const machine = createMachine({
+ context: {
+ name: '',
+ },
+ on: {
+ CHANGE_NAME: {
+ actions: assign((context, event) => {
+ return {
+ name: event.value,
+ };
+ }),
+ },
+ },
+});
+```
+
+Every time the `CHANGE_NAME` event is sent to the machine, we'll update the value in `context`. We can then use that value to display the value in our UI or send it to an API.
+
+XState also gives you another way of expressing state - through finite states. Let's imagine a modal:
+
+```ts
+const machine = createMachine({
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: 'open',
+ },
+ },
+ open: {
+ on: {
+ CLOSE: 'close',
+ },
+ },
+ },
+});
+```
+
+Here, the modal's state is expressed through the `states: {}` attribute, which also defines which events can be received during each state. You can only `CLOSE` the modal when it's `open`, and vice versa.
+
+## Which should I choose?
+
+The choice between using `context` and `states` isn't always clear. For instance, the modal machine above could be expressed using `context`:
+
+```ts
+const machine = createMachine({
+ context: {
+ isOpen: false,
+ },
+ on: {
+ OPEN: {
+ actions: assign({ isOpen: true }),
+ },
+ CLOSE: {
+ actions: assign({ isOpen: false }),
+ },
+ },
+});
+```
+
+This gives you exactly the same functionality as the states-based one above - you can track when the modal is open and closed, and send the same events.
+
+The reason this can be expressed using both `states` and `context` is because _all of the events do the same thing no matter what state you’re in_. There are no events you need to declare as impossible in certain states.
+
+To show you what I mean, let’s imagine a form input inside a modal. We only want to allow changes to the form input while the modal is open.
+
+```ts
+const machine = createMachine({
+ initial: 'closed',
+ context: {
+ name: '',
+ },
+ states: {
+ closed: {
+ on: {
+ OPEN: 'open',
+ },
+ },
+ open: {
+ on: {
+ CLOSE: 'close',
+ CHANGE_NAME: {
+ actions: assign((context, event) => {
+ return {
+ name: event.value,
+ };
+ }),
+ },
+ },
+ },
+ },
+});
+```
+
+When the modal is in the `closed` state, the `CHANGE_NAME` event will not change the value in `context`. State machines are great at this - only allowing the things you want to happen to happen. Some other examples might be:
+
+- Not allowing users to submit a form while the previous API call is loading
+- Only allowing users to log in if they’re not already logged in
+
+## Putting things in context
+
+You might be wondering - but, I _can_ express the above in `context`!
+
+```ts
+const machine = createMachine({
+ context: {
+ name: '',
+ isOpen: false,
+ },
+ on: {
+ OPEN: { actions: assign({ isOpen: true }) },
+ CLOSE: { actions: assign({ isOpen: false }) },
+ CHANGE_NAME: {
+ actions: assign((context, event) => {
+ // This acts as the guard to prevent editing
+ // the name while it's open
+ if (!context.isOpen) return {};
+ return {
+ name: event.value,
+ };
+ }),
+ },
+ },
+});
+```
+
+I think this is incorrect for two reasons. First, as requirements grow, so will the complexity of your logic. Let’s imagine that the modal can now be either `closing` (i.e. animating out) or `closed`. We’ll soon see an explosion of booleans, as I discussed in [this article on useState/useReducer](https://dev.to/mpocock1/usestate-vs-usereducer-vs-xstate-part-1-modals-569e).
+
+Second, XState is auto-documenting via the [XState visualiser](https://xstate.js.org/viz/). The more your logic is expressed in `states`, the easier it’s going to be to visualise. The machine above is basically a single state with its logic expressed in ways that XState can’t visualise.
+
+## Rules to live by
+
+You should be keeping most of your state in context. That includes form values, API data - anything which cannot be expressed finitely.
+
+But state machines are powerful _because_ of their states. Use states when you want to express your logic visually, or gate events to certain states.
diff --git a/fumadocs/content/blog/2021-04-30-should-this-be-an-action-or-a-service/index.mdx b/fumadocs/content/blog/2021-04-30-should-this-be-an-action-or-a-service/index.mdx
new file mode 100644
index 000000000..045079eb4
--- /dev/null
+++ b/fumadocs/content/blog/2021-04-30-should-this-be-an-action-or-a-service/index.mdx
@@ -0,0 +1,218 @@
+---
+title: 'Should this be an action, or a service?'
+description: Whether to use an action or a service in XState.
+tags: [action, state machine, xstate, service]
+authors: [matt]
+image: /blog/2021-04-30-should-this-be-an-action-or-a-service.png
+slug: 2021-04-30-should-this-be-an-action-or-a-service
+date: 2021-04-30
+---
+
+XState offers several ways of orchestrating side effects. Since it’s a statechart tool, [with significantly more power than a reducer](https://dev.to/mpocock1/usestate-vs-usereducer-vs-xstate-part-1-modals-569e), side effects are treated as a first-class concept.
+
+{/* truncate */}
+
+‘Side effects’ as a concept spring from the idea of ‘pure’ functions. I.e. a function is at its best when it takes an input and returns an output. Pure functions don’t tend to involve:
+
+- Waiting a set amount of time
+- Making an API call to an external service
+- Logging things to an external service
+
+So we can think of all of the above as ‘side effects’ of our programme running. The name gives them a negative, medical, connotation - but really, they’re the meat of your app. Apps that don’t have side effects don’t talk to anything external, don’t worry about time, and don’t react to unexpected errors.
+
+## Actions
+
+> “Thank u, next.” - Ariana Grande
+
+Side effects can be expressed in two ways in XState. First, as a fire-and-forget `action`. Let’s imagine that when the user opens this modal, we want to report to a logging service that this happened.
+
+```ts
+const modalMachine = createMachine(
+ {
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: 'open',
+ },
+ },
+ open: {
+ entry: ['reportThatUserOpenedTheModal'],
+ on: {
+ CLOSE: 'closed',
+ },
+ },
+ },
+ },
+ {
+ actions: {
+ // Note that I'm declaring the action name above, but implementing
+ // it here. This keeps the logic and implementation separate,
+ // which I like
+ reportThatUserOpenedTheModal: async () => {
+ await fetch('/external-service/user-opened-modal');
+ },
+ },
+ },
+);
+```
+
+Actions are fire-and-forget, which means you can fire them off without worrying about consequences. If the action I declared above errors, my state machine won’t react - it’s already forgotten about it.
+
+Actions represent a single point in time, like a dot on a graph. This means that you can place them very flexibly. Above, I’ve placed them on the `entry` attribute of the state, meaning that action will be fired when we enter the state. I could also place them on the transition:
+
+```ts
+const modalMachine = createMachine(
+ {
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: {
+ actions: 'reportThatUserOpenedTheModal',
+ target: 'open',
+ },
+ },
+ },
+ open: {
+ on: {
+ CLOSE: 'closed',
+ },
+ },
+ },
+ },
+ {
+ actions: {
+ reportThatUserOpenedTheModal: async () => {
+ // implementation
+ },
+ },
+ },
+);
+```
+
+This means that whenever `OPEN` is called from the `closed` state, that action will be fired. In this modal, we could also fire the action whenever the user leaves the `closed` state, since we know they’ll be going to the `open` state.
+
+```ts
+const modalMachine = createMachine(
+ {
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: 'open',
+ },
+ exit: ['reportThatUserOpenedTheModal'],
+ },
+ open: {
+ on: {
+ CLOSE: 'closed',
+ },
+ },
+ },
+ },
+ {
+ actions: {
+ reportThatUserOpenedTheModal: async () => {
+ // implementation
+ },
+ },
+ },
+);
+```
+
+Actions are flexible precisely because we don’t care about their outcome. We can hang them on the hooks our state machine gives us: transitions between states, exiting states and entering states.
+
+## Services
+
+> “And I plan to be forgotten when I’m gone…” - The Tallest Man on Earth
+
+But actions have a specific limitation - they are designed to be forgotten. Let’s imagine that you wanted to track whether the analytics call you made was successful, and only open the modal if it was. We’ll add an `opening` state which handles that check.
+
+```ts
+const modalMachine = createMachine({
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: 'opening',
+ },
+ },
+ opening: {
+ entry: [
+ async () => {
+ await fetch('/external-service/user-opened-modal');
+
+ // OK, this was successful - how do I get to the open state?!
+ },
+ ],
+ },
+ open: {
+ on: {
+ CLOSE: 'closed',
+ },
+ },
+ },
+});
+```
+
+This isn’t possible in an action. We can’t fire back an event to the machine, because it’s already forgotten about us.
+
+When you care about the result of an action, put it in a service. This is how this would be expressed as a service:
+
+```ts
+const modalMachine = createMachine({
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: 'opening',
+ },
+ },
+ opening: {
+ invoke: {
+ // This uses the invoked callback syntax - my favourite
+ // syntax for expressing services
+ src: () => async (send) => {
+ await fetch('/external-service/user-opened-modal');
+
+ send('OPENED_SUCCESSFULLY');
+ },
+ onError: {
+ target: 'closed',
+ },
+ },
+ on: {
+ OPENED_SUCCESSFULLY: {
+ target: 'open',
+ },
+ },
+ },
+ open: {
+ on: {
+ CLOSE: 'closed',
+ },
+ },
+ },
+});
+```
+
+If actions are a dot on the graph, services represent a line - a continuous process which takes some amount of time. If the service errors, it’ll trigger an event called `error.platform.serviceName`, which you can listen for with the `onError` attribute, as above.
+
+Crucially, they can also send events back to the machine, using the `send` function above. Notice that we’re both sending back the `OPENED_SUCCESSFULLY` event _and_ listening to it in the `on: {}` attribute of the `opening` state.
+
+Services are less flexible than actions, because they demand more from you. You can’t hang them on every hook your machine offers. They must be contained within one state, and they’re cancelled when you leave that state. (Note: they can also be at the root of the machine definition, meaning they run for the lifetime of the machine.)
+
+## Guidelines
+
+Actions are the ‘thank u, next’ of the XState world. They represent points in time. Use them for fire-and-forget actions. Actions are great for:
+
+- `console.log`
+- Showing ephemeral error or success messages (toasts)
+- Navigating between pages
+- Firing off events to external services or parents of your machine
+
+Services are like a ‘phase’ your machine goes through. They represent a length of time. Use them for processes where you care about the outcome, or you want the process to run for a long time. Services are great for:
+
+- API calls
+- Event listeners (`window.addEventListener`)
diff --git a/fumadocs/content/blog/2021-05-13-why-i-love-invoked-callbacks/index.mdx b/fumadocs/content/blog/2021-05-13-why-i-love-invoked-callbacks/index.mdx
new file mode 100644
index 000000000..57e75ccdf
--- /dev/null
+++ b/fumadocs/content/blog/2021-05-13-why-i-love-invoked-callbacks/index.mdx
@@ -0,0 +1,186 @@
+---
+title: Why I love invoked callbacks
+description: >-
+ I’ve written a bit about services, but today I wanted to talk about my
+ favourite way of expressing services: the Invoked Callback.
+tags: [services, invoked callback, state machine, xstate]
+authors: [matt]
+image: /blog/2021-05-13-why-i-love-invoked-callbacks.png
+slug: 2021-05-13-why-i-love-invoked-callbacks
+date: 2021-05-13
+---
+
+XState offers several primitives for representing long-running application processes. These are usually expressed as [services](https://xstate.js.org/docs/guides/communication.html). I’ve written a bit about services [here](https://dev.to/mpocock1/xstate-should-this-be-an-action-or-a-service-2cp0) - but today I wanted to talk about my favourite way of expressing services: the Invoked Callback.
+
+{/* truncate */}
+
+The [Invoked Callback](https://xstate.js.org/docs/guides/communication.html#invoking-callbacks) combines immense flexibility with good readability and a solid Typescript experience. They look like this:
+
+```ts
+createMachine({
+ invoke: {
+ src: (context, event) => (send, onReceive) => {
+ // Run any code you like inside here
+
+ return () => {
+ // Any code inside here will be called when
+ // you leave this state, or the machine is stopped
+ };
+ },
+ },
+});
+```
+
+Let’s break this down. You get access to `context` and `event`, just like promise-based services. But `send` is where things really get interesting. Let’s break down what makes `send` useful with an example.
+
+## File Uploads
+
+Imagine you need to build a file uploader, and you have a handy function called `startUpload` that uploads some data, and exposes an `onProgressUpdate` parameter to update the progress.
+
+```ts
+createMachine({
+ context: {
+ progress: 0,
+ },
+ initial: 'idle',
+ states: {
+ idle: {
+ on: {
+ START: 'pending',
+ },
+ },
+ pending: {
+ on: {
+ PROGRESS_UPDATED: {
+ assign: assign({
+ progress: (context, event) => event.progress,
+ }),
+ },
+ CANCEL: {
+ target: 'idle',
+ },
+ },
+ invoke: {
+ src: (context) => (send) => {
+ const uploader = startUpload({
+ onProgressUpdate: (progress) => {
+ send({
+ type: 'PROGRESS_UPDATED',
+ progress,
+ });
+ },
+ });
+
+ return () => {
+ uploader.cancel();
+ };
+ },
+ },
+ },
+ },
+});
+```
+
+This machine starts in the `idle` state, but on the `START` event begins its invoked service, which uploads the file. It then listens for `PROGRESS_UPDATED` events, and updates the context based on its updates.
+
+The `CANCEL` event will trigger the `uploader.cancel()` function, which gets called when the state is left. React users may recognise this syntax - it’s the same as the cleanup function in the [useEffect hook](https://reactjs.org/docs/hooks-reference.html#cleaning-up-an-effect).
+
+Note how simple and idiomatic it is to cancel the uploader - just exit the state, and the service gets cleaned up.
+
+## Event Listeners
+
+The invoked callback’s cleanup function makes it very useful for event listeners, for instance `window.addEventListener()`. XState Catalogue’s [Tab Focus Machine](https://xstate-catalogue.com/machines/tab-focus) is a perfect example of this - copied here for ease:
+
+```ts
+createMachine(
+ {
+ initial: 'userIsOnTab',
+ states: {
+ userIsOnTab: {
+ invoke: {
+ src: 'checkForDocumentBlur',
+ },
+ on: {
+ REPORT_TAB_BLUR: 'userIsNotOnTab',
+ },
+ },
+ userIsNotOnTab: {
+ invoke: {
+ src: 'checkForDocumentFocus',
+ },
+ on: {
+ REPORT_TAB_FOCUS: 'userIsOnTab',
+ },
+ },
+ },
+ },
+ {
+ services: {
+ checkForDocumentBlur: () => (send) => {
+ const listener = () => {
+ send('REPORT_TAB_BLUR');
+ };
+
+ window.addEventListener('blur', listener);
+
+ return () => {
+ window.removeEventListener('blur', listener);
+ };
+ },
+ checkForDocumentFocus: () => (send) => {
+ const listener = () => {
+ send('REPORT_TAB_FOCUS');
+ };
+
+ window.addEventListener('focus', listener);
+
+ return () => {
+ window.removeEventListener('focus', listener);
+ };
+ },
+ },
+ },
+);
+```
+
+When in the `userIsOnTab` state, we listen for the window’s `blur` event. When that happens, and `REPORT_TAB_BLUR` is fired, we clean up the event listener and head right on over to `userIsNotOnTab`, where we fire up the other service.
+
+## Websockets
+
+Invoked callbacks can also receive events via the `onReceive` function. This is perfect when you need to communicate to your service, such as sending events to websockets.
+
+```ts
+import { createMachine, forwardTo } from 'xstate';
+
+createMachine({
+ on: {
+ SEND: {
+ actions: forwardTo('websocket'),
+ },
+ },
+ invoke: {
+ id: 'websocket',
+ src: () => (send, onReceive) => {
+ const websocket = connectWebsocket();
+
+ onReceive((event) => {
+ if (event.type === 'SEND') {
+ websocket.send(event.message);
+ }
+ });
+
+ return () => {
+ websocket.disconnect();
+ };
+ },
+ },
+});
+```
+
+In order to receive events, services need an `id`. Not all events are forwarded to the invoked service, only those which we select via the `forwardTo` action.
+
+Here, we can connect to the websocket, establish two-way communication, and clean it up all in a few lines of code.
+
+## My Love Letter
+
+Invoked callbacks are a concise, flexible method of invoking services in XState. There isn’t a case they can’t cover - and they’re one of my favourite parts of the XState API.
diff --git a/fumadocs/content/blog/2021-05-27-global-state-xstate-react/index.mdx b/fumadocs/content/blog/2021-05-27-global-state-xstate-react/index.mdx
new file mode 100644
index 000000000..27d3120eb
--- /dev/null
+++ b/fumadocs/content/blog/2021-05-27-global-state-xstate-react/index.mdx
@@ -0,0 +1,131 @@
+---
+title: How to manage global state with XState and React
+description: 'Everything you need to know to manage global state with XState and React.'
+authors: [matt]
+date: 2021-05-27
+tags: [xstate, react, redux, webdev]
+category: entry
+image: /blog/2021-05-27-global-state-xstate-react.png
+slug: 2021-05-27-global-state-xstate-react
+---
+
+Many React applications follow the Flux architecture popularised by [Redux](https://redux.js.org/). This setup can be characterised by a few key ideas:
+
+1. It uses a single object at the top of your app which stores all application state, often called the **store**.
+2. It provides a single `dispatch` function which can be used to send messages up to the store. Redux calls these `action`s, but I'll be calling them `events` - as they're known in XState.
+3. How the store responds to these messages from the app are expressed in pure functions - most often in **reducers**.
+
+This article won't go into depth on whether the Flux architecture is a good idea. David Khourshid's article [Redux is half a pattern](https://dev.to/davidkpiano/redux-is-half-of-a-pattern-1-2-1hd7) goes into great detail here. For the purposes of this article, we're going to assume that you like having a global store, and you want to replicate it in XState.
+
+{/* truncate */}
+
+There are many reasons for wanting to do so. XState is second-to-none when it comes to managing complex asynchronous behaviour and modelling difficult problems. Managing this in Redux apps usually involves middleware: either [redux-thunk](https://github.com/reduxjs/redux-thunk), [redux-loop](https://github.com/redux-loop/redux-loop) or [redux-saga](https://github.com/redux-saga/redux-saga). Choosing XState gives you a first-class way to manage complexity.
+
+## A globally available store
+
+To mimic Redux's globally-available store, we're going to use React context. React context can be a tricky tool to work with - if you pass in values which change too often, in can result in re-renders all the way down the tree. That means we need to pass in values which change as little as possible.
+
+Luckily, XState gives us a first-class way to do that.
+
+```ts
+import React, { createContext } from 'react';
+import { useInterpret } from '@xstate/react';
+import { authMachine } from './authMachine';
+import { ActorRefFrom } from 'xstate';
+
+interface GlobalStateContextType {
+ authService: ActorRefFrom;
+}
+
+export const GlobalStateContext = createContext(
+ // Typed this way to avoid TS errors,
+ // looks odd I know
+ {} as GlobalStateContextType,
+);
+
+export const GlobalStateProvider = (props) => {
+ const authService = useInterpret(authMachine);
+
+ return (
+
+ {props.children}
+
+ );
+};
+```
+
+Using `useInterpret` returns a `service`, which is a static reference to the running machine which can be subscribed to. This value never changes, so we don't need to worry about wasted re-renders.
+
+## Utilising context
+
+Further down the tree, you can subscribe to the service like this:
+
+```ts
+import React, { useContext } from 'react';
+import { GlobalStateContext } from './globalState';
+import { useActor } from '@xstate/react';
+
+export const SomeComponent = (props) => {
+ const globalServices = useContext(GlobalStateContext);
+ const [state] = useActor(globalServices.authService);
+
+ return state.matches('loggedIn') ? 'Logged In' : 'Logged Out';
+};
+```
+
+The `useActor` hook listens for whenever the service changes, and updates the `state` value.
+
+## Improving Performance
+
+There's an issue with the implementation above - this will update the component for any change to the service. Redux offers tools for deriving state using selectors - functions which restrict which parts of the state can result in components re-rendering.
+
+Luckily, XState provides that too.
+
+```ts
+import React, { useContext } from 'react';
+import { GlobalStateContext } from './globalState';
+import { useSelector } from '@xstate/react';
+
+const selector = (state) => {
+ return state.matches('loggedIn');
+};
+
+export const SomeComponent = (props) => {
+ const globalServices = useContext(GlobalStateContext);
+ const isLoggedIn = useSelector(globalServices.authService, selector);
+
+ return isLoggedIn ? 'Logged In' : 'Logged Out';
+};
+```
+
+Now, this component will only re-render when `state.matches('loggedIn')` returns a different value. This is my recommended approach over `useActor` for when you want to optimise performance.
+Dispatching events
+
+For dispatching events to the global store, you can call a service's send function directly.
+
+```ts
+import React, { useContext } from 'react';
+import { GlobalStateContext } from './globalState';
+
+export const SomeComponent = (props) => {
+ const globalServices = useContext(GlobalStateContext);
+
+ return (
+ globalServices.authService.send('LOG_OUT')}>
+ Log Out
+
+ );
+};
+```
+
+Note that you don't need to call useActor for this, it's available right on the context.
+
+## Deviations from Flux
+
+Keen-eyed readers may spot that this implementation is slightly different from Flux. For instance - instead of a single global store, one might have several running machines at once: `authService`, `dataCacheService`, and `globalTimeoutService`. Each of them have their own `send` attributes, too - so you're not calling a global dispatch.
+
+These changes can be worked around. One could create a synthetic send inside the global store which called all the services' `send` function manually. But personally, I prefer knowing exactly which services my messages are being passed to, and it avoids having to keep events globally namespaced.
+
+## Summary
+
+XState can work beautifully as a global store for a React application. It keeps application logic co-located, treats side effects as first-class citizens, and offers good performance with `useSelector`. You should choose this approach if you're keen on the Flux architecture but feel your app's logic is getting out of hand.
diff --git a/fumadocs/content/blog/2021-07-28-usestate-vs-usereducer-vs-xstate-part-1-modals/index.mdx b/fumadocs/content/blog/2021-07-28-usestate-vs-usereducer-vs-xstate-part-1-modals/index.mdx
new file mode 100644
index 000000000..e59b273ca
--- /dev/null
+++ b/fumadocs/content/blog/2021-07-28-usestate-vs-usereducer-vs-xstate-part-1-modals/index.mdx
@@ -0,0 +1,327 @@
+---
+title: 'useState vs useReducer vs XState - Part 1: Modals'
+description: >-
+ Managing state at different levels of complexity is hard. This series of
+ articles should help you make the right choices off the bat. Today we’re
+ starting with modals.
+tags: [modal, react, useState, useReducer, xstate]
+authors: [matt]
+image: /blog/2021-07-28-usestate-vs-usereducer-vs-xstate-part-1-modals.png
+slug: 2021-07-28-usestate-vs-usereducer-vs-xstate-part-1-modals
+date: 2021-07-28
+---
+
+Managing state at different levels of complexity is hard. Different tools make different trade-offs between readability, complexity and speed of development. The worst part is that as apps get more complex, it’s easy to regret choices that were made early on.
+
+This series of articles should help you make the right choice off the bat. The plan is to cover a bunch of state use cases, starting with the simple and graduating to more complexity as we go. We’ll see how easy they are to write, and also how they survive changing requirements.
+
+Today, we’re starting with [modals](https://material-ui.com/components/modal/).
+
+{/* truncate */}
+
+## useState
+
+For modals, the key piece of state is whether or not the modal is open. `useState` lets us capture that single piece of state pretty succinctly.
+
+```ts
+const [isOpen, setIsOpen] = useState(false);
+
+const open = () => {
+ setIsOpen(true);
+};
+
+const close = () => {
+ setIsOpen(false);
+};
+
+const toggle = () => {
+ setIsOpen(!isOpen);
+};
+```
+
+Highly readable, simple enough, fast to write, bug-proof. For a simple toggle like this, `useState` is great.
+
+## useReducer
+
+```ts
+const reducer = (state = { isOpen: false }, action) => {
+ switch (action.type) {
+ case 'OPEN':
+ return {
+ isOpen: true,
+ };
+ case 'CLOSE':
+ return {
+ isOpen: false,
+ };
+ case 'TOGGLE':
+ return {
+ isOpen: !state.isOpen,
+ };
+ default:
+ return state;
+ }
+};
+
+const [state, dispatch] = useReducer(reducer, { isOpen: false });
+
+const open = () => {
+ dispatch({ type: 'OPEN' });
+};
+
+const close = () => {
+ dispatch({ type: 'CLOSE' });
+};
+
+const toggle = () => {
+ dispatch({ type: 'TOGGLE' });
+};
+```
+
+`useReducer` gives us a reducer, a powerful centralized spot in our code where we can visualise the changes happening. However, it took us quite a few more lines of code to reach the same result as `useState`. For now, I’d say `useState` has the edge.
+
+## useMachine
+
+`useMachine` is a hook from XState, which allows us to use the power of state machines in our code. Let’s see how it looks.
+
+```ts
+const machine = Machine({
+ id: 'modalMachine',
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: {
+ target: 'open',
+ },
+ TOGGLE: 'open',
+ },
+ },
+ open: {
+ on: {
+ TOGGLE: 'closed',
+ CLOSE: 'closed',
+ },
+ },
+ },
+});
+
+const [state, send] = useMachine(machine);
+
+const open = () => {
+ send({ type: 'OPEN' });
+};
+
+const close = () => {
+ send({ type: 'CLOSE' });
+};
+
+const toggle = () => {
+ send({ type: 'TOGGLE' });
+};
+```
+
+_You can see the state machine on the [XState visualiser here](https://xstate.js.org/viz/?gist=cf1578f5baa04cf9408ef6e48695f04c)._
+
+It’s remarkably similar in structure to the reducer above. Similar amount of lines, nearly the same event handlers. The state machine takes the edge over the reducer because of being able to easily visualise its logic - that’s something the reducer can’t match.
+
+However, the `useState` implementation still has the edge for me. The simplicity of execution, the elegance. It’s hard to see how it could be beaten...
+
+## Alert: requirements changing
+
+Oh no. Requirements have changed. Now, instead of immediately closing, the modal needs to animate out. This means we need to insert a third state, `closing`, which we automatically leave after 500ms. Let’s see how our implementations hold up.
+
+### useState
+
+**Refactor 1**: Our initial `isOpen` boolean won't handle all the states we need it to any more. Let’s change it to an enum: `closed`, `closing` and `open`.
+
+**Refactor 2**: `isOpen` is no longer a descriptive variable name, so we need to rename it to `modalState` and `setModalState`.
+
+**Refactor 3**: `useState` doesn’t handle async changes by itself, so we need to bring in `useEffect` to run a timeout when the state is in the `closing` state. We also need to clear the timeout if the state is no longer `closing`.
+
+**Refactor 4**: We need to change the toggle event handler to add logic to ensure it only triggers on the `closed` and `open` states. Toggles work great for booleans, but become much harder to manage with enums.
+
+```ts
+// Refactor 1, 2
+const [modalState, setModalState] = useState('closed');
+
+// Refactor 3
+useEffect(() => {
+ if (modalState === 'closing') {
+ const timeout = setTimeout(() => {
+ setModalState('closed');
+ }, 500);
+ return () => {
+ clearTimeout(timeout);
+ };
+ }
+}, [modalState]);
+
+// Refactor 1, 2
+const open = () => {
+ setModalState('open');
+};
+
+// Refactor 1, 2
+const close = () => {
+ setModalState('closing');
+};
+
+// Refactor 1, 2, 4
+const toggle = () => {
+ if (modalState === 'closed') {
+ setModalState('open');
+ } else if (modalState === 'open') {
+ setModalState('closing');
+ }
+};
+```
+
+Yuck. That was an enormous amount of refactoring to do just to add a simple, single requirement. On code that might be subject to changing requirements, think twice before using `useState`.
+
+### useReducer
+
+**Refactor 1**: Same as above - we turn the `isOpen` boolean to the same enum.
+
+**Refactor 2**: Same as above, `isOpen` is now improperly named, so we need to change it to `status`. This is changed in fewer places than `useState`, but there are still some changes to make.
+
+**Refactor 3**: The same as above, we use `useEffect` to manage the timeout. An additional wrinkle is that we need a new action type in the reducer, `REPORT_ANIMATION_FINISHED`, to cover this.
+
+**Refactor 4**: The same as above, but instead of the logic being in the event handler, we can actually change the logic inside the reducer. This is a cleaner change, but is still similar in the amount of lines it produces.
+
+```ts
+// Refactor 1, 2
+const reducer = (state = { status: 'closed' }, action) => {
+ switch (action.type) {
+ // Refactor 2
+ case 'OPEN':
+ return {
+ status: 'open',
+ };
+ // Refactor 2
+ case 'CLOSE':
+ return {
+ status: 'closing',
+ };
+ // Refactor 3
+ case 'REPORT_ANIMATION_FINISHED':
+ return {
+ status: 'closed',
+ };
+ // Refactor 4
+ case 'TOGGLE':
+ switch (state.status) {
+ case 'closed':
+ return {
+ status: 'open',
+ };
+ case 'open':
+ return {
+ status: 'closing',
+ };
+ }
+ break;
+ default:
+ return state;
+ }
+};
+
+// Refactor 1
+const [state, dispatch] = useReducer(reducer, { status: 'closed' });
+
+// Refactor 3
+useEffect(() => {
+ if (state.status === 'closing') {
+ const timeout = setTimeout(() => {
+ dispatch({ type: 'REPORT_ANIMATION_FINISHED' });
+ }, 500);
+ return () => {
+ clearTimeout(timeout);
+ };
+ }
+}, [state.status]);
+
+const open = () => {
+ dispatch({ type: 'OPEN' });
+};
+
+const close = () => {
+ dispatch({ type: 'CLOSE' });
+};
+
+const toggle = () => {
+ dispatch({ type: 'TOGGLE' });
+};
+```
+
+This file required the same number of refactors as the `useState` implementation. One crucial advantage is that these refactors were mostly located together: most changes occurred inside the reducer, and the event handlers went largely untouched. For me, this gives `useReducer` the edge over `useState`.
+
+### useMachine
+
+**Refactor 1**: Add a new closing state, which after 500 milliseconds goes to the closed state.
+
+**Refactor 2**: Changed the targets of the `TOGGLE` and `CLOSE` actions to point at `closing` instead of `closed`.
+
+```ts
+export const machine = Machine({
+ id: 'modalMachine',
+ initial: 'closed',
+ states: {
+ closed: {
+ on: {
+ OPEN: {
+ target: 'open',
+ },
+ TOGGLE: 'open',
+ },
+ },
+ // Refactor 1
+ closing: {
+ after: {
+ 500: 'closed',
+ },
+ },
+ open: {
+ on: {
+ // Refactor 2
+ TOGGLE: 'closing',
+ CLOSE: 'closing',
+ },
+ },
+ },
+});
+
+const [state, send] = useMachine(machine);
+
+const open = () => {
+ send({ type: 'OPEN' });
+};
+
+const close = () => {
+ send({ type: 'CLOSE' });
+};
+
+const toggle = () => {
+ send({ type: 'TOGGLE' });
+};
+```
+
+> [See the changed machine here](https://xstate.js.org/viz/?gist=61bbac74d69894c9472571e44c98f765).
+
+The difference here is stark. A minimal number of refactors, all within the state machine itself. The amount of lines has hardly changed. None of the event handlers changed. AND we have a working visualisation of the new implementation.
+
+## Conclusion
+
+Before the requirements changed, `useState` was the champion. It’s faster, easier to implement, and fairly clear. `useReducer` and `useMachine` were too verbose, but `useMachine` took the edge by being easier to visualise.
+
+But after the requirements changed, `useState` hit the floor. It quickly became the _worst_ implementation. It was the hardest to refactor, and its refactors were in the most diverse places. `useReducer` was equally hard to refactor, with the same set of changes. `useMachine` emerged as the champion, with a minimal diff required to build in new, complex functionality.
+
+So if you’re looking to build a modal fast, use `useState`. If you want to build it right, use `useMachine`.
+
+I’m excited to work on this set of articles - I’m looking forward to tackling the toughest state models out there. What would you like to see covered in the next one? Some ideas:
+
+- Data fetching
+- Form state
+- Multi-step sequences (checkout flows, signup flows)
+
+Let me know in the comments below, and follow me for the next article!
diff --git a/fumadocs/content/blog/2021-10-02-intro-fsm-sc/index.mdx b/fumadocs/content/blog/2021-10-02-intro-fsm-sc/index.mdx
new file mode 100644
index 000000000..ef5efd7a5
--- /dev/null
+++ b/fumadocs/content/blog/2021-10-02-intro-fsm-sc/index.mdx
@@ -0,0 +1,182 @@
+---
+title: Introduction to state machines and statecharts
+description: Introduction to state machines and statecharts
+tags: [introduction, state machine, statechart, state]
+authors: [laura]
+category: entry
+image: /blog/2021-10-02-intro-fsm-sc.png
+slug: 2021-10-02-intro-fsm-sc
+date: 2021-10-02
+---
+
+
+
+
+
+
+**XState and TypeScript are a match made in heaven**. TypeScript gives you type safety, and XState gives you logical safety. Together, they give you confidence that your code will do what you expect.
+
+However, we’ve been hearing from the community for some time that the _experience_ of using TypeScript with XState needed improving.
+
+Today's your lucky day. **XState’s TypeScript experience just got an _enormous_ upgrade**.
+
+{/* truncate */}
+
+We have brought type generation into XState v4.29.0, and we’re aiming for **perfect types on all parts of XState’s API**.
+
+We’re releasing typegen today as an opt-in beta. Be sure to check out the [known limitations](https://xstate.js.org/docs/guides/typescript.html#known-limitations) section of the docs.
+
+## Getting Started
+
+You can visit the [official docs](https://xstate.js.org/docs/guides/typescript.html#typegen) for the full guide, or follow the instructions:
+
+1. Download and install the [VS Code extension](https://marketplace.visualstudio.com/items?itemName=statelyai.stately-vscode).
+
+2. Open a new file and create a new machine, passing the schema attributes:
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ schema: {
+ context: {} as { value: string },
+ events: {} as { type: 'FOO'; value: string } | { type: 'BAR' },
+ },
+ initial: 'a',
+ states: {
+ a: {
+ on: {
+ FOO: {
+ actions: 'consoleLogValue',
+ target: 'b',
+ },
+ },
+ },
+ b: {
+ entry: 'consoleLogValueAgain',
+ },
+ },
+});
+```
+
+3. Add `tsTypes: {}` to the machine and save the file:
+
+```diff
+const machine = createMachine({
++ tsTypes: {},
+ schema: {
+ context: {} as { value: string },
+ events: {} as { type: "FOO"; value: string } | { type: "BAR" },
+ },
+ initial: "a",
+ states: {
+ /* ... */
+ },
+});
+```
+
+4. The extension should automatically add a generic to the machine:
+
+```ts
+const machine = createMachine({
+ // This generic just got added!
+ tsTypes: {} as import('./filename.typegen').Typegen0,
+ /* ... */
+});
+```
+
+5. Add a second parameter into the `createMachine` call - this is where you implement the actions, services, guards and delays for the machine.
+
+```ts
+const machine = createMachine(
+ {
+ /* ... */
+ },
+ {
+ actions: {
+ consoleLogValue: (context, event) => {
+ // Wow! event is typed to { type: 'FOO' }
+ console.log(event.value);
+ },
+ consoleLogValueAgain: (context, event) => {
+ // Wow! event is typed to { type: 'FOO' }
+ console.log(event.value);
+ },
+ },
+ },
+);
+```
+
+## Typing improvements
+
+Let’s get into the nitty-gritty and show you exactly what’s improved.
+
+### Events in machine options
+
+One of the most common pain points we heard from our community was using named actions, services and guards with TypeScript. The main reason is that you needed to write code like this:
+
+```ts
+createMachine(
+ {
+ schema: {
+ events: {} as { type: 'FOO'; value: string } | { type: 'BAR' },
+ },
+ on: {
+ FOO: {
+ actions: 'myAction',
+ },
+ },
+ },
+ {
+ actions: {
+ myAction: (context, event) => {
+ /**
+ * TS don't know if the event is FOO or BAR,
+ * so we have to defensively check here
+ */
+ if (event.type === 'FOO') {
+ /**
+ * Now we know that event.value
+ * is present on FOO, because
+ * we checked
+ */
+ console.log(event.value);
+ }
+ },
+ },
+ },
+);
+```
+
+The VS Code extension **statically analyzes your machine**, and knows which events lead to which actions.
+
+```ts
+createMachine(
+ {
+ /* config */
+ },
+ {
+ actions: {
+ myAction: (context, event) => {
+ /**
+ * No more defensive check needed! event
+ * is typed to only the events that cause
+ * the action
+ */
+ console.log(event.value);
+ },
+ },
+ },
+);
+```
+
+This works for actions, services, guards and delays. It even works for **entry actions**, another big pain point from the community.
+
+We’re hoping this lets you cut hundreds of lines of useless defensive code.
+
+### Autocomplete on machine options
+
+Another thing we’ve been hearing from the community is that it’s easy to make typos on machine options.
+
+Now, with typegen, you get **autocomplete on all machine options**. The following code will error:
+
+```ts
+createMachine(
+ {
+ entry: ['sayHello'],
+ },
+ {
+ actions: {
+ /*
+ * This will error, because sayhello does not
+ * exist in the machine declaration above
+ */
+ sayhello: () => {},
+ },
+ },
+);
+```
+
+We’ve also made it so any _missing_ machine options will error when
+you implement them later. So, in a React component:
+
+```tsx
+const machine = createMachine({
+ entry: ['sayHello'],
+});
+
+const App = () => {
+ /**
+ * This will error, because you haven't implemented
+ * sayHello in your actions object
+ */
+ const [state, send] = useMachine(machine);
+};
+```
+
+That gives you 100% confidence that your machine has all the things it needs to work.
+
+### Typing of promise-services
+
+Using promise-based services might be the single biggest pain point with XState and TypeScript. We used to have an entire troubleshooting section in our docs dedicated to them.
+
+Now, you can **strongly type the results of promise-based services**. Here’s how:
+
+```ts
+createMachine(
+ {
+ schema: {
+ /**
+ * Pass the 'services' attribute to schema,
+ * with all the names of your services and
+ * the data they return
+ */
+ services: {} as {
+ myService: {
+ // The data that gets returned from the service
+ data: { id: string };
+ };
+ },
+ },
+ invoke: {
+ src: 'myService',
+ onDone: {
+ actions: 'consoleLogId',
+ },
+ },
+ },
+ {
+ services: {
+ /**
+ * This service will now type error if it
+ * returns anything other than { id: string }
+ */
+ myService: async () => {
+ return {
+ id: '1',
+ };
+ },
+ },
+ actions: {
+ consoleLogId: (context, event) => {
+ /**
+ * This event now knows that it will
+ * receive a data attribute with { id: string }
+ */
+ console.log(event.data.id);
+ },
+ },
+ },
+);
+```
+
+This makes handling data return types in XState intuitive, easy and type-safe.
+
+## Acknowledgements
+
+I want to thank my Stately colleague [Andarist](https://twitter.com/AndaristRake). His TypeScript wizardry, incredible attention to detail and deep love of open source helped make this possible. We’ve literally been talking about this for 18 months - and it’s finally here.
diff --git a/fumadocs/content/blog/2022-02-14-modelling-101-how-to-build-a-statechart-from-scratch/index.mdx b/fumadocs/content/blog/2022-02-14-modelling-101-how-to-build-a-statechart-from-scratch/index.mdx
new file mode 100644
index 000000000..91213bdcd
--- /dev/null
+++ b/fumadocs/content/blog/2022-02-14-modelling-101-how-to-build-a-statechart-from-scratch/index.mdx
@@ -0,0 +1,196 @@
+---
+title: 'Modelling 101: How to build a statechart from scratch'
+description: Stately dev Matt Pocock takes you through a step-by-step guide on modelling statecharts
+tags: [xstate, tutorial, statechart, modelling]
+authors: [matt]
+image: /blog/2022-02-15-modelling-101-how-to-build-a-statechart-from-scratch.png
+slug: 2022-02-15-modelling-101-how-to-build-a-statechart-from-scratch
+date: 2022-02-17
+---
+
+Modelling using statecharts changed my career as a dev. Of all the state management solutions I’ve tried, it feels the most complete, logical and robust. Even if you don’t use them in your app’s code, statecharts let you break down complex features into states, events, services, actions and guards.
+
+{/* truncate */}
+
+It took me a long time to get comfortable modelling with statecharts. Even when I’d learned all the terms, it took time to work out a step-by-step process for building statecharts from scratch.
+
+Today, I’m going to share **an opinionated, step-by-step guide for building statecharts from scratch**. This process _works for me_, but it might not work for you. Feel free to tweak it as you go.
+
+## What you’ll need
+
+1. A pen and paper, or a digital notepad of some kind
+2. A statechart builder, such as [our visual editor](https://stately.ai/editor) or an XState machine in our [XState visualizer](https://stately.ai/viz)
+3. A clear idea of what you’re building. Maybe something you’ve implemented at work? You could also pick something from [XState Catalogue](https://xstate-catalogue.com).
+
+I’ve also built this [process as a statechart](https://stately.ai/registry/editor/d24479eb-ac20-44ae-a7b7-c0910e6247ad) using our visual editor.
+
+## 1. List all the possible events
+
+The first step in this process is to work out all the events that can be received by your statechart. You can think of an event as ‘something that happens’ in your app. There are plenty of examples even on this page:
+
+1. Press the escape key
+2. Press the space bar
+3. Select some text
+4. Click on an image
+
+You don’t need to list _all_ possible events that the user can perform. You only need to **list the events that your statechart cares about**. Here are some examples:
+
+For a submit form:
+
+- User changes the value of an input
+- User submits form
+
+For a spreadsheet:
+
+- User clicks a cell on the spreadsheet
+- User holds down the `shift`/`ctrl` key
+- User presses `escape`
+- User scrolls up or down
+
+Seeing all the events in a big list may start giving you an idea of what is possible in your statechart. You might start thinking in terms of _sequences of events_ — i.e. `User changes input` -> `User submits form`. Write down any sequences that pop into your head, they’ll be useful later.
+
+## 2. List all the possible tasks
+
+Next, it’s important to consider the _tasks_ your app needs to perform. These tasks could be called ‘side effects’ — things that happen as a result of your statechart running. These could be as diverse as:
+
+1. **Adding an item to a todo list (in local state)**
+2. **Sending a request to the API to load some data**
+3. **Focusing an input**
+4. **Waiting for a video to load**
+5. **Subscribing to something for updates** (perhaps via `window.addEventListener()`)
+
+_NOTE: I’m using ‘tasks’ loosely. This isn’t an official term in the XState docs — but ‘services’ and ‘actions’ are._
+
+Once you have a list of tasks, you need to divide them into two groups.
+
+### 2a. Services
+
+The first group is for services, tasks where you need to _do something when they finish_. I wrote a [longer guide about the distinction between actions and services here](../../docs/assets/blog/2021-04-30-should-this-be-an-action-or-a-service/index).
+
+From our list above, these are services:
+
+2. **Sending a request to the API to load some data**
+
+We need to get something from the API, meaning that we need to wait until we receive the data. This task can also fail — if we’re having network trouble or the API method fails. That means we care whether it succeeds or fails.
+
+4. **Waiting for a video to load**
+
+Same as above — we need to wait for the video to be loaded, and we care if it fails to load.
+
+5. **Subscribing to something for updates**
+
+Here, it’s a little different — when you subscribe to something, you need to clean up the listener to prevent a memory leak. For instance:
+
+```ts
+const listener = () => {
+ console.log('Hello!');
+};
+
+// Subscribe
+window.addEventListener('focus', listener);
+
+// Unsubscribe
+window.removeEventListener('focus', listener);
+```
+
+Here, we care about the outcome because we need to _run something at the end of the process_ — i.e. unsubscribe from the listener.
+
+#### Adding onDone/onError events
+
+Service completions/errors are handled _as events_ in your statechart, meaning they’re on the same level as your user clicking buttons.
+
+When you’ve got your list of services, note down two things:
+
+For each service that we need to wait for it to complete, add a `serviceName.onDone` event to your list.
+
+For each service that might reasonably be expected to error, add a `serviceName.onError` event to your list.
+
+### 2b. Actions
+
+The second group is for actions, tasks that you can ‘fire and forget’. Unlike services, the statechart forgets about actions as soon as they’re fired.
+
+From our list above, these are actions:
+
+1. **Adding an item to a todo list (in local state)**
+
+Changes to local state are pretty much always fire-and-forget. The reason is that, since we manage the local state ourselves, updating it is instant. [XState’s assign action](https://xstate.js.org/docs/guides/context.html#assign-action) is a good example.
+
+2. **Focusing an input**
+
+Focusing an input, in the same vein, is fire-and-forget. We don’t care about the outcome, and it’s unlikely to fail.
+
+## 3. Work out the very first state
+
+Now that you know _what can happen_ (events) and _what can be done_ (actions & services) in your statechart, it’s time to start adding some states.
+
+### 3a. Know your statechart’s lifecycle
+
+It’s always easiest to start at the beginning. Before you add your first state, consider the moment that your statechart gets initiated. What causes your statechart to run? Some examples:
+
+An **authentication** statechart, which manages the state for whether the user is logged in to a website or not. This would be started the _first moment_ the user clicks on to any page of your app, and finished when they close your app.
+
+A **sign up form** statechart, which handles a user signing up to your app. This might be started when the user visits the `/sign-up` route, and stopped when they exit it.
+
+### 3b. Write down your first state
+
+Now that you know what your app looks like when your statechart gets initiated, it’s time to name its initial state. Consider what the statechart is doing at that time. It could be `Loading data`, or `Waiting for user to submit form`, or even just `Idle`, waiting for something to happen.
+
+#### Dynamic initial states
+
+Every statechart _must_ have an initial state, and it can’t be dynamic — it must be the same every time your statechart runs.
+
+If you feel your statechart _does_ have more than one initial state (for instance it could start in two different modes) consider using a ‘checking’ state via an [eventless transition](https://xstate.js.org/docs/guides/transitions.html#eventless-always-transitions).
+
+## 4. Build out the states
+
+Now that you have your first state, you can start the process of building out the states. Every state represents a length of time, so consider _what is happening_ during that state.
+
+### 4a. Work out if any tasks are running
+
+Do you have any services running? If so, _invoke_ those services using [XState’s invoke property](https://xstate.js.org/docs/guides/communication.html#invoking-services).
+
+Does an action need to happen when you enter or exit the state? If so, add it as an [entry or exit action](https://xstate.js.org/docs/guides/actions.html#actions).
+
+Remember, the _statechart itself_ is also a state. We often call it the ‘root state’. This means that you can run services or listen to events for the _entire duration of your statechart_. You can also run entry actions when your statechart starts, and exit actions when it stops.
+
+### 4b. Work out which events can happen in that state
+
+Consider the period of time your state represents. Which events should _do_ something, and what should they do?
+
+#### Events that change state
+
+If an event results in:
+
+1. A new service running
+2. Something new appearing on screen
+3. Other types of events becoming possible
+4. A current service stopping
+
+Then it might need to move to a new state. A great example is a **data fetcher**. Your app is in two distinct states:
+
+- **Fetching data**: it doesn’t yet have the data, and the ‘fetch data’ service is running.
+- **Showing data**: it has the data, and is showing it on screen. The ‘fetch data’ service has stopped.
+
+If you have an event like this, draw out the new event and either create a new state, or make it target an existing one if needed.
+
+#### Events that don’t change state
+
+Sometimes, [events can be used to fire an action](https://xstate.js.org/docs/guides/actions.html#api) instead of changing state. A good example of this is when a form input changes, and you need to save the new value to local state.
+
+This is called a [self-transition](https://xstate.js.org/docs/guides/transitions.html#self-transitions), where the event doesn’t change the state — the state transitions to itself.
+
+#### Events that do nothing
+
+It’s important to bear in mind that when your statechart is in a certain state, _only the events that you specify_ will be handled. In other words, any event you don’t specify will do _nothing_ when it’s sent to the statechart.
+
+A classic example of this is a form. When you submit the form, you go to the ‘submitting’ state. It’s important that you don’t allow the ‘submit’ event to be received while in the ‘submitting’ state — otherwise the form might get sent twice!
+
+## 5. Keep going!
+
+Once you’ve figured out which actions/services are running in which states, and what all the events do, you’ve modelled your first state! You’ll likely have states which branch off your initial state — so go through those one-by-one and build them out.
+
+You can also leave parts of your statechart unimplemented, and dive into building the frontend/actions/services before returning to modelling again.
+
+I’ve found this approach really useful when getting to grips with what my app does. You can even use a statechart as an early validation tool to confirm that what you’re building is correct.
+
+If you’ve got any more questions, do [join our Discord](https://discord.gg/invite/xstate) and ask in the ‘modelling-help’ channel.
diff --git a/fumadocs/content/blog/2022-03-03-introducing-the-xstate-cli/index.mdx b/fumadocs/content/blog/2022-03-03-introducing-the-xstate-cli/index.mdx
new file mode 100644
index 000000000..5ba538680
--- /dev/null
+++ b/fumadocs/content/blog/2022-03-03-introducing-the-xstate-cli/index.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Introducing: The XState CLI'
+description: 'Get ready to run XState’s typegen commands outside of VSCode in our all-new CLI.'
+tags: [cli, xstate, announcement, typescript]
+authors: [matt]
+image: /blog/2022-03-03-introducing-the-xstate-cli.png
+slug: 2022-03-03-introducing-the-xstate-cli
+date: 2022-03-03
+---
+
+Around a month ago, we released [TypeScript Typegen](../../docs/assets/blog/2022-01-27-introducing-typegen/index) - an enormous upgrade to the TypeScript experience for XState.
+
+We’ve had a great response to it so far, but it’s only been available for VSCode users.
+
+Until now. With our new XState CLI, **you can get Typegen from the command line**.
+
+{/* truncate */}
+
+- Read the full documentation on the [`@xstate/cli` docs](https://xstate.js.org/docs/packages/xstate-cli).
+- Check out [our updated TypeScript Typegen guide](https://xstate.js.org/docs/guides/typescript.html#typegen).
+- Find the code on the [@xstate/cli GitHub repo](https://github.com/statelyai/xstate-tools/tree/main/apps/cli).
+
+## Installation
+
+```bash
+npm install @xstate/cli
+```
+
+OR
+
+```bash
+yarn add @xstate/cli
+```
+
+## Commands
+
+### `xstate typegen `
+
+```bash
+xstate typegen "src/**/*.tsx?"
+```
+
+Run the typegen against a glob of files. This will scan every targeted file and generate a typegen file accompanying it. It will also import the typegen into your file, as described in [our typegen documentation](https://xstate.js.org/docs/guides/typescript.html#typegen).
+
+Ensure you wrap your glob in quotes so that it executes correctly. Otherwise, you’ll get unexpected results.
+
+#### Options
+
+```bash
+xstate typegen "src/**/*.tsx?" --watch
+```
+
+Runs the task on a watch, monitoring for changed files and running the typegen script against them.
+
+## The Future
+
+We’re really excited about the CLI, and all the cool things it’ll enable. The typegen really is just the surface. If you’ve got ideas for what we could do with it, don’t hesitate to add a feature request to the [`xstate-tools` repo](https://github.com/statelyai/xstate-tools/issues).
diff --git a/fumadocs/content/blog/2022-03-11-xstate-vscode-extension-now-available-on-the-open-vsx-registry/index.mdx b/fumadocs/content/blog/2022-03-11-xstate-vscode-extension-now-available-on-the-open-vsx-registry/index.mdx
new file mode 100644
index 000000000..4d8541f7c
--- /dev/null
+++ b/fumadocs/content/blog/2022-03-11-xstate-vscode-extension-now-available-on-the-open-vsx-registry/index.mdx
@@ -0,0 +1,35 @@
+---
+title: Open VSX XState VSCode extension now available
+description:
+ 'If you use VSCodium, Coder, Gitpod or another editor with VSCode-compatible
+ extensions, you can now install the XState VSCode extension.'
+tags: [extension, open source, xstate, vscode]
+authors: [laura]
+slug: /2022/03/11/xstate-vscode-extension-now-available-on-the-open-vsx-registry
+image: /blog/2022/03/11/xstate-vscode-extension-now-available-on-the-open-vsx-registry.png
+date: 2022-03-15
+---
+
+
+ send('TOGGLE')}>
+ {state.value === 'inactive'
+ ? 'Click to activate'
+ : 'Active! Click to deactivate'}
+
+ );
+};
+```
+
+This example shows how you can then evaluate `state.value` to render the corresponding UI for the toggle state and you can also call `send('TOGGLE')` in a button’s `onClick` handler to toggle the state.
+
+Similarly, one could access other state methods and properties like `state.matches()`, `state.can()`, `state.hasTag()`, or even `state.context` to evaluate state and show the correct UI.
+
+### A custom machine hook
+
+But what if your component really doesn’t need access to all of those features when using a machine? That’s where the custom machine hook comes into play. We can still create a machine and pass it to the `useMachine` hook but this can all be done inside of the custom hook.
+
+Here’s an example of what that custom hook might look like, including a [React/TypeScript CodeSandbox version](https://codesandbox.io/s/usetogglemachine-example-1-lazy-machine-8zcbvs?file=/src/Toggler.tsx):
+
+```ts
+import { useMachine } from '@xstate/react';
+import { useEffect } from 'react';
+import { createMachine } from 'xstate';
+
+export const useToggleMachine = (
+ initialActive: boolean = false,
+): [boolean, () => void] => {
+ const [state, send] = useMachine(() =>
+ createMachine({
+ id: 'toggle',
+ initial: initialActive ? 'active' : 'inactive',
+ states: {
+ inactive: {
+ on: { TOGGLE: 'active' },
+ },
+ active: {
+ on: { TOGGLE: 'inactive' },
+ },
+ },
+ }),
+ );
+
+ const isActive = state.matches('active');
+ const toggle = () => send('TOGGLE');
+
+ return [isActive, toggle];
+};
+```
+
+#### Why a hook?
+
+Why might we opt for this extra layer of abstraction? Well, consider what we need to do in the example:
+
+1. Create the `toggleMachine`, including states and possible transitions.
+2. Pass the machine to the `useMachine` hook.
+3. Expose the most relevant pieces to our component.
+
+From this hook, we can expose a minimal interface to components. In fact, we don’t even need to export the machine at all. By encapsulating the XState code, we allow components to focus on their core task, rendering UI as a function of data/props. Sweet!
+
+Our `useToggleMachine` hook now fully manages a toggle state for any component that uses it. This is now more resuable since a single component can create multiple instances of `useToggleMachine`. Similarly, multiple components can instantiate this hook one or more times to keep track of multiple, separate toggle states.
+
+Related: If you’re wondering about how to create a global machine hook then have a look at this [RFC for a Global Hooks API](https://github.com/statelyai/rfcs/pull/8).
+
+Let’s dive deeper into a the details of this `useToggleMachine` hook.
+
+#### Hook params
+
+If you recall, we initialized our machine to start out in its “inactive” state by specifying `initial: 'inactive'` in the machines config object. But we’re also receiving an `initialActive` value as the one and only argument passed into this hook. If that value is false or omitted, since it defaults to false, then the inital value will be in sync with the machine’s default state.
+
+But what if we want to start out with `initialActive` passed in as `true`? We need a way to immediately transiton our machine away from its own initial state to be synchronized with the incoming `initialActive` value.
+
+The original version of this post included an example that used the infamous `useEffect` hook to dynamically establish the initial state, based on the `initialActive` prop passed into the hook.
+
+```ts
+// This example is deprecated
+useEffect(() => {
+ if (initialActive && state.matches('inactive')) {
+ send('TOGGLE');
+ }
+}, [initialActive]);
+```
+
+Some readers noted in their feedback that they prefer to avoid using the `useEffect` hook altogether for understandable reasons. The `state` really should be included in the dependency array to make the linter happy and using `useEffect` here feels generally awkward.
+
+Instead, I've updated the example by wrapping the call to `createMachine` in a function passed to `useMachine`, utilizing a sort of ["lazily created machine"](https://xstate.js.org/docs/packages/xstate-react/#usemachine-machine-options).
+
+```ts
+const [state, send] = useMachine(() =>
+ createMachine({
+ id: 'toggle',
+ initial: initialActive ? 'active' : 'inactive',
+ states: {
+ inactive: {
+ on: { TOGGLE: 'active' },
+ },
+ active: {
+ on: { TOGGLE: 'inactive' },
+ },
+ },
+ }),
+);
+```
+
+This gives our machine config object access to the incoming `initialActive` prop so that we can dynamically assign the machine's initial value. It's a subtle but significant change.
+
+```ts
+initial: initialActive ? "active" : "inactive",
+```
+
+You can read about alternative methods and proposals in our [RFC for input](https://github.com/statelyai/rfcs/pull/9).
+
+#### Return values
+
+We’ve looked at the input param for `useToggleMachine` so now let’s look at its return values.
+
+```ts
+const isActive = state.matches('active');
+const toggle = () => send('TOGGLE');
+
+return [isActive, toggle];
+```
+
+We have a boolean `isActive` value which is derived from the state of the machine, the raison d’être of this hook. This is a simple mapping of one of two machine states to a boolean in this example. But you can imagine how states of a more complex machine might be derived from evaluating matches on the current state, possible next events, and even tags. Vist the [docs on state methods](https://xstate.js.org/docs/guides/states.html#state-methods-and-properties) for details.
+
+We also have a `toggle` function which enables us to toggle the state of the machine. It’s an anonymous function wrapping the call to XState’s `send('TOGGLE')`.
+
+Our hook returns an array of just these values much like `useState` or `useMachine` would and they should be destructured in the component.
+
+### Using the hook in a component
+
+What does this look like for the `Toggler` component to now use our `useToggleMachine` hook? It looks pretty good!
+
+```tsx
+const Toggler = () => {
+ const [isActive, toggle] = useToggleMachine(false); // Or pass true.
+
+ return Click me ({isActive ? '✅' : '❌'}) ;
+};
+```
+
+In that example, we use the value of `isActive` to specify the button’s text but it could easily be used for other purposes in this component or as a prop to pass down to child components.
+
+For the `Toggler` component’s `onChange` handler, we set its value to be the `toggle` function. Since that is already wrapping XState’s `send('TOGGLE')` call, we don’t even need to use another anonymous function. It all just works as is, in a tidy functional style.
+
+### Reusability
+
+As you can see, this pattern separates our normal React component code from our state machine implementation which keeps files neat and focused. Hooks make for more reusable machines across many components and in different situations. A `useToggleMachine` may be used to represent a toggle switch in one component but it might also represent the showing or hiding of UI or something else in another component.
+
+```ts
+const [isAnimationEnabled, toggleAnimation] = useToggleMachine(false);
+
+const [isDarkMode, toggleLightDarkMode] = useToggleMachine(true);
+```
+
+In a future blog post we can explore ways to compose machine hooks to build up more sophisticated machines from reusable parts, not unlike how small reusable functions are typically composed to create larger functions.
+
+### Team specialization
+
+This separation of code also means that **team members who are more familiar with XState can create and manage machine hooks** with autonomy. Meanwhile, their teammates, who may be less familiar with state machines or with XState, can still rapidly churn out UI components that will, nevertheless, be backed by the power of state machines. This greatly **facilitates incremental adoption**. You can begin using XState in small bits and pieces right away, neither needing to design your entire application as a large statechart nor rewrite everything to fit that way of working.
+
+### Caveats
+
+If you only have one component and all you need to do is toggle a boolean flag, then creating a machine and a hook on top of that may feel like unnecessary ceremony. Splitting code into two different files has the usual tradeoffs. Also, understanding how changing the `initialActive` prop works with the state machine’s own internal state can be a bit tricky although we’d still need to transition the machine to a non-initial state, in a similar way, from within a component that calls `useMachine()`.
+
+### Summary
+
+We saw a baseline example of how components traditionally employ the `useMachine` hook from `XState/react` with a [complete example](https://codesandbox.io/s/usetogglemachine-example-1-lazy-machine-8zcbvs?file=/src/Toggler.tsx) of how to separate the machine into its own custom `useToggleMachine` hook for comparison. We covered implementation details for this hook, as well as how to wire it up in a React component. I’ve offered several benefits that I believe make this abstraction worthwhile like incremental adoption and future feature scaling.
+
+### Next steps
+
+Again, the toggle example is a small yet usable example for creating a machine with XState and wrapping it in a hook. But we can take this even further. What about **combining multiple machines** into a single hook? How about **overriding machine implmentation details** via hooks on a per use basis? I’ll be exploring these patterns and more in some upcoming blog posts so stay tuned!
+
+In the meantime, if you like using XState then keep creating your own machines and try wrapping those in custom hooks to use in your components. Additonally, you can build upon machine/hook examples in these posts for your own purposes and even find machines in the [Discovery section of the Stately Studio](https://stately.ai/registry/discover) and turn those into hooks. Whatever path you take, I hope you **get hooked on using XState** to make your UI more robust and more reusable!
diff --git a/fumadocs/content/blog/2022-08-03-whats-new-august-2022/august-22-editor-improvements.png b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/august-22-editor-improvements.png
new file mode 100644
index 000000000..8640c7a74
Binary files /dev/null and b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/august-22-editor-improvements.png differ
diff --git a/fumadocs/content/blog/2022-08-03-whats-new-august-2022/index.mdx b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/index.mdx
new file mode 100644
index 000000000..5351f5710
--- /dev/null
+++ b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/index.mdx
@@ -0,0 +1,82 @@
+---
+title: 'What’s new in August 2022?'
+description: Get up and running faster with our XState VS Code extension and enjoy all the design details in the Stately studio experience.
+tags: [stately, xstate, announcement, vscode extension, studio, survey]
+authors: [laura]
+image: /blog/2022-08-03-whats-new-august-2022.png
+slug: 2022-08-03-whats-new-august-2022
+date: 2022-08-05
+---
+
+## Updates to our VS Code extension
+
+Our [XState VS Code extension](https://marketplace.visualstudio.com/items?itemName=statelyai.stately-vscode) has now been installed 10k times! Install the extension yourself from inside VS Code or find the [XState extension on the Open VSX Registry](https://stately.ai/blog/2022/03/11/xstate-vscode-extension-now-available-on-the-open-vsx-registry) to enjoy the following new features.
+
+{/* truncate */}
+
+### `xsm` snippet
+
+We want to make it fast and easy to use XState and the visual editor in your code. By adding the `xsm` snippet to our VS Code extension, we’ve made it possible to go from nothing to a full-blown machine you can open in the visual editor in a few keystrokes.
+
+Use our new `xsm` snippet ([Anders says “think **X** **S**tate **M**achine”](https://youtu.be/EkhWpJfVLDo?t=155)) with the latest version of the extension to insert a state machine template into your code, with the cursor ready for you to type the name of the machine.
+
+```js
+import { createMachine } from 'xstate';
+const nameOfMachine = createMachine({
+ id: 'nameOf',
+ initial: 'initialState',
+ states: {
+ initialState: {},
+ },
+});
+```
+
+Just give your machine a name, hit “Open visual editor,” and you’ll be able to continue creating your machine with the visual editor.
+
+
+
+### The editor now syncs with your VS Code theme
+
+You can now set your light mode or dark mode preference for the visual editor inside the VS Code extension:
+
+- Auto: syncs to your VS Code preference
+- Light: always uses light mode
+- Dark: always uses dark mode
+
+
+
+
+
+If the editor is open when you change the setting, you’ll need to close and re-open the editor tab to view the change.
+
+### Initial support for non-VS Code editors
+
+If you don’t use VS Code, we haven’t forgotten about you! We intend to support more code editors in the future and have recently taken the first step of making it easier to edit machine code using other code editors. Watch [Anders’ demo using Webstorm](https://www.youtube.com/watch?v=EkhWpJfVLDo&t=252s) during last week’s office hours to find out more.
+
+## Updates to Stately editor
+
+If you haven’t used the [Stately editor](https://stately.ai/editor) in a while, you’re in for a treat!
+
+### Canvas refinements
+
+We’ve made some small changes that have significantly changed how machines look and behave. Icons are now only used to distinguish the history states and final states, reducing the noise and increasing the readability of your machines.
+
+
+
+The transition line drawing algorithm has been improved further for straighter, more reasonable lines with fewer bends. The lines are now highlighted on hover, making them easier to select. We’ll continue to improve the algorithm so that it’s more intelligent about drawing even better lines.
+
+We’ve also removed the terminal squares at the end of the transition lines and put a little space between the transition lines and nodes. These subtle changes make the machines look less crowded, helping you focus more on your modeling.
+
+### Select all with the keyboard shortcut
+
+You can now use the cmd /ctrl **+** a keyboard shortcut to select all nodes and transitions in the editor. This shortcut is so common that you’ve probably tried to use it already… now the shortcut will work!
+
+
+
+## New privacy options
+
+We now have a modal asking for your consent the next time you log into the Stately Studio. We are sending some non-personal activity data to Mixpanel to help us understand how you use our features, but we need your permission to connect this data to a hash of your user ID. Many tech companies won’t ask for your explicit consent for similar activities. Still, at Stately, we want to use best practices regarding your privacy and be transparent about the minimal data we collect, how we use that data, and how we design for privacy by default. You can update your choices at any time in the studio settings.
+
+## Please give us feedback in our yearly survey
+
+Soon we’ll be closing [the Stately 2022 survey](https://stately.ai/survey). Do you know someone who isn’t using our tools but should be? Please get them to respond to our survey! We’d love to understand what features folks need to start using Stately tools. And if you’ve not responded yet, get your response in soon! All the questions are optional, and it will take just five minutes of your time.
diff --git a/fumadocs/content/blog/2022-08-03-whats-new-august-2022/select-all-keyboard-shortcut.gif b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/select-all-keyboard-shortcut.gif
new file mode 100644
index 000000000..5a25b2511
Binary files /dev/null and b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/select-all-keyboard-shortcut.gif differ
diff --git a/fumadocs/content/blog/2022-08-03-whats-new-august-2022/vscode-darkmode.png b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/vscode-darkmode.png
new file mode 100644
index 000000000..db2890c0b
Binary files /dev/null and b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/vscode-darkmode.png differ
diff --git a/fumadocs/content/blog/2022-08-03-whats-new-august-2022/vscode-lightmode.png b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/vscode-lightmode.png
new file mode 100644
index 000000000..3908a65ea
Binary files /dev/null and b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/vscode-lightmode.png differ
diff --git a/fumadocs/content/blog/2022-08-03-whats-new-august-2022/xsm-snippet.gif b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/xsm-snippet.gif
new file mode 100644
index 000000000..bb3439b46
Binary files /dev/null and b/fumadocs/content/blog/2022-08-03-whats-new-august-2022/xsm-snippet.gif differ
diff --git a/fumadocs/content/blog/2022-08-10-get-started-with-xstate-using-xsm-snippet/index.mdx b/fumadocs/content/blog/2022-08-10-get-started-with-xstate-using-xsm-snippet/index.mdx
new file mode 100644
index 000000000..250b2e2d5
--- /dev/null
+++ b/fumadocs/content/blog/2022-08-10-get-started-with-xstate-using-xsm-snippet/index.mdx
@@ -0,0 +1,13 @@
+---
+title: 'XState + VS Code: xsm snippet'
+description: Create a state machine in seconds and edit using our visual editor.
+tags: [stately, xstate, vscode extension, snippet]
+authors: [laura]
+image: /blog/2022-08-10-get-started-with-xstate-using-xsm-snippet.png
+slug: 2022-08-10-get-started-with-xstate-using-xsm-snippet
+date: 2022-08-10
+---
+
+Using the XState extension for VS Code, you can create a state machine in seconds and edit the machine using our visual editor. Use the `xsm` snippet to quickly generate the code required for your state machine, then drag and drop inside our visual editor to rapidly model your machine.
+
+
+ Try the Stately Editor beta and start modeling your app logic visually.
+
+
+## Next steps
+
+The editor is the initial state towards making the ultimate collaborative tool for visually editing even the most complex app logic. We’re excited to share the Stately Editor with the world, and we’re looking forward to hearing your reactions.
+
+[Join our Discord community](https://discord.gg/xstate) to get help, ask questions, and give us your feedback.
diff --git a/fumadocs/content/blog/2022-2-6-stately-editor-public-beta/stately-editor-public-beta.png b/fumadocs/content/blog/2022-2-6-stately-editor-public-beta/stately-editor-public-beta.png
new file mode 100644
index 000000000..0ace354de
Binary files /dev/null and b/fumadocs/content/blog/2022-2-6-stately-editor-public-beta/stately-editor-public-beta.png differ
diff --git a/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-contribute.png b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-contribute.png
new file mode 100644
index 000000000..094796924
Binary files /dev/null and b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-contribute.png differ
diff --git a/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-light-mode.png b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-light-mode.png
new file mode 100644
index 000000000..d9f35eb65
Binary files /dev/null and b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-light-mode.png differ
diff --git a/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-search.png b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-search.png
new file mode 100644
index 000000000..b88310cbc
Binary files /dev/null and b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-search.png differ
diff --git a/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-xstate.png b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-xstate.png
new file mode 100644
index 000000000..aa940ebb5
Binary files /dev/null and b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs-xstate.png differ
diff --git a/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs.png b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs.png
new file mode 100644
index 000000000..76553d096
Binary files /dev/null and b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/2023-01-19-docs.png differ
diff --git a/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/index.mdx b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/index.mdx
new file mode 100644
index 000000000..3208f8562
--- /dev/null
+++ b/fumadocs/content/blog/2023-01-19-introducing-the-stately-docs/index.mdx
@@ -0,0 +1,50 @@
+---
+title: 'Introducing the Stately docs'
+description: >-
+ The time has finally come; our new docs are ready to share with you all. If you’ve been following our office hours, you know I’ve been talking about these docs for a long time…
+tags: [studio, xstate, docs, search, light mode and dark mode, contribute]
+authors: [laura]
+image: /blog/2023-01-19-introducing-the-stately-docs.png
+slug: 2023-01-19-introducing-the-stately-docs
+date: 2023-01-19
+---
+
+The time has finally come; [our new docs](https://stately.ai/docs) are ready to share with you all. If you’ve been following our office hours, you know I’ve been talking about these docs for a long time. Thanks to Anders, who used [Docusaurus](https://docusaurus.io) to build us a rock solid easily-maintainable platform with search that actually works, and the whole team, who have contributed reviews, explainers, and examples to get these docs started.
+
+{/* truncate */}
+
+
+
+## Docs for the Stately Studio
+
+Our new docs have documentation for both the [Stately Studio](https://stately.ai/editor) and [XState](https://xstate.js.org). If you want to learn how to use the Studio without having to learn any code, we’ve got you covered with a [no-code introduction to state machines and statecharts](https://stately.ai/docs/state-machines-and-statecharts) and [step-by-step tutorials for different features in the Studio](https://stately.ai/docs/states/intro). We’ve also got a [modeling section](https://stately.ai/docs/descriptions) where we’ll add more guides to modeling your machines in the future.
+
+## Docs for XState
+
+If you’re a more experienced developer who wants to [jump straight into XState](https://stately.ai/docs/xstate/basics/what-is-a-statechart), we have docs that focus on the coding experience and cover all the concepts you need to know when working with XState. Shoutout to [Matt Pocock](https://totaltypescript.com), who used his vast knowledge of XState to kick these docs off when he was with us last year.
+
+
+
+## Useful search
+
+As I mentioned earlier, the search in the docs really works. Search is a problem for a lot of documentation across the web and something we were keen to improve over the previous XState docs. Anders worked hard to make the Algolia search work for us, and while the structure of our docs navigation is essential, we all know the search is where you’ll likely go first.
+
+
+
+## Dark mode
+
+One of our most-requested features for our docs was dark mode. Inspired by Nick’s light and dark mode designs for the Studio, I’ve given the docs light mode and dark modes that should hopefully be easy on the eyes and give you the best possible reading experience. Even our images respond to the light and dark modes!
+
+
+
+## Easy to contribute
+
+At the end of every page, we have an **Edit this page on GitHub** link, which takes you directly to that page in our docs’ GitHub repository. We appreciate any contributions that help our community learn XState and the Stately Studio. We have a short [Stately Guide to Writing Docs wiki](https://github.com/statelyai/docs/wiki) on [our repository](https://github.com/statelyai/docs/) with recommendations on structure and style. Read below if you want to suggest an improvement to our docs.
+
+
+
+## Still in beta
+
+These docs are still in beta, and we want your feedback! At Stately, we care a great deal about accessible and valuable education. Our docs are a living iterable product, and we want to continuously improve them to make them as valuable a resource as possible. Please [let us know in Discord](https://discord.gg/xstate) or [on Twitter](https://twitter.com/statelyai) if you have suggestions for improvements or where we could make the docs clearer or better for you. Use [our Canny documentation request board](https://feedback.stately.ai/docs) if you have a page, feature, or example request.
+
+We hope you like our new, improved docs, and we’re looking forward to hearing from you!
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2022-11-29-import-from-code-right-panel.png b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2022-11-29-import-from-code-right-panel.png
new file mode 100644
index 000000000..715f8393a
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2022-11-29-import-from-code-right-panel.png differ
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-19-docs.png b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-19-docs.png
new file mode 100644
index 000000000..76553d096
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-19-docs.png differ
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-machine-images.png b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-machine-images.png
new file mode 100644
index 000000000..92bb2ba24
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-machine-images.png differ
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-read-only.png b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-read-only.png
new file mode 100644
index 000000000..90b165c66
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-read-only.png differ
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-stately-streams.png b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-stately-streams.png
new file mode 100644
index 000000000..2d3bb58de
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-stately-streams.png differ
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-team-in-lisbon.png b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-team-in-lisbon.png
new file mode 100644
index 000000000..86035800a
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-team-in-lisbon.png differ
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-xstate-vscode.png b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-xstate-vscode.png
new file mode 100644
index 000000000..fc320fb7b
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/2023-01-20-xstate-vscode.png differ
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/index.mdx b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/index.mdx
new file mode 100644
index 000000000..f022e614b
--- /dev/null
+++ b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/index.mdx
@@ -0,0 +1,82 @@
+---
+title: 'What’s new for Stately in 2023'
+description: >-
+ Happy 2023! We thought we’d kick off the year with a reminder of all the features we’ve released since the Stately Studio 1.0 release in October.
+tags: [recovery, restore, offline, editor, studio]
+authors: [laura]
+image: /blog/2023-01-20-whats-new-in-2023.png
+slug: 2023-01-20-whats-new-in-2023
+date: 2023-01-20
+---
+
+Happy 2023! The Stately team is back from their [first off-site of the year in Lisbon](https://twitter.com/statelyai/status/1615394794251096065) and excited to get started on our plans for this year. We thought we’d kick off the year with a reminder of all the features we’ve released since the [Stately Studio 1.0 release](https://stately.ai/blog/2022-10-18-introducing-stately-studio-1-0) in October. It’s been just three months, and we already have so much to share.
+
+{/* truncate */}
+
+
+
+## Import from code
+
+[Import from code](https://stately.ai/blog/2022-11-29-import-from-code) was one of our most-requested features from users who had already created machines using XState or our Stately Viz. You can import an existing machine from JavaScript, TypeScript or JSON using the code panel in the editor’s right tool menu or the Machines list in the left drawer. Import from code works well with our existing export as code feature, where you can export your machine as JSON, JavaScript, and TypeScript using the code panel in the right tool menu.
+
+
+
+## Moving machines
+
+You can now quickly move machines between projects from the machines list menu. You can move your machines to your own projects or any projects you share with your teams. [Watch Kevin demo moving machines](https://www.youtube.com/watch?v=MpbbgOQ9WAI&t=709s) during our office hours in December last year.
+
+## Recovery mode
+
+Recovery mode is one of those features we hope you never have to use. We now try to detect any missing connectivity or backend failure on our end while you’re editing your machines. We will let you know if a connectivity issue or other failure happens and start saving your work locally on your device. The next time you visit the Studio from that same device, we compare what we saved with the machine from the server. If the versions are different, we will give you the option to restore the safe copy to a new machine.
+
+
+
+## Editor tutorials
+
+The editor now has several tutorials to help get you started, along with basic state machine and statechart concepts. You can access the tutorials from the blue question mark button in the lower right of the editor canvas. Most tutorials also have an accompanying short video for those who like to learn visually. You can [watch the playlist of all the tutorial videos on YouTube](https://www.youtube.com/watch?v=Aixi0e53qAE&list=PLvWgkXBB3dd4I_l-djWVU2UGPyBgKfnTQ).
+
+## XState VS Code update
+
+The XState VS Code extension has had a significant overhaul making it run much faster and giving it more accurate bi-directional editing between the code and visual editing modes.
+
+
+
+We’ve also added two much-requested features from our VS Code users; you can now use the XState VS Code without logging in, and use the extension entirely offline.
+
+## Learn more with the Stately streams
+
+If you want to learn more about using the Stately Studio and XState, check out [David and Farzad’s Stately streams](https://www.youtube.com/watch?v=25zL7hUOc1k&list=PLvWgkXBB3dd5UEJZCk4C3Wn1Ys8WRMDbi). These are a series of videos where David and Farzad work through modeling and coding features and best practices with state orchestration.
+
+
+
+## Docs
+
+[We’ve finally launched our new Stately docs](https://stately.ai/blog/2023-01-19-introducing-the-stately-docs). We now have docs for the Stately Studio and XState, with how-tos, tutorials, code examples, and much more. And yes, the new docs have dark mode!
+
+
+
+## Even more in the Studio
+
+We continue making improvements to the Studio to improve your experience. We’ve improved how we track features in the Studio, enhancing your privacy by keeping our users entirely anonymous in our analytics. We now support Safari and hope to work on the touchscreen experience in the future. And we’ve also introduced dedicated support for our Pro subscription users, which has a 100% success and speedy response record so far!
+
+### Machine metadata
+
+We now support metadata for states and events for those who want to include static data in their machines. You can add your metadata as JSON key-value pairs at the end of the State details panel. The Studio will recognize and format your values as strings, numbers, or booleans; all metadata is included when you export your machines to code.
+
+### Read-only mode
+
+At the end of last year, we added a read-only mode to the editor. Previously when viewing a read-only machine, you’d be able to edit the machine even though the editor wouldn’t save your changes. Now, when checking out a read-only machine, you won’t be able to edit the machine, and you’ll see a banner explaining why you can’t make changes.
+
+
+
+### Machine images
+
+You’ll love our new machine images if you’ve been looking for an easy way to share an overview of your machines on GitHub, Slack, Discord, or any other web platform. From the machines list menu, you can choose **Copy image URL** and use that URL anywhere you want to share your machine. The image will be live-updated when your machine is updated, so you don’t need to worry about your reference images going out of date.
+
+
+
+I’ve been using these images everywhere in our new docs, and you can see there that you can get light and dark mode versions of each image. The image URL copied to your clipboard will use the same mode you’re using in the Studio, but you can always change the mode by switching the .dark.png and .light.png suffixes in the URL. This feature is part of our work toward our GitHub integration, so look out for that coming soon!
+
+## Find out more
+
+If all of that isn’t enough for you, you can catch up with [David’s wrap-up of 2022](https://www.youtube.com/watch?v=-uoEro1jsBI&t=1916s) and a [preview of what’s to come from Stately in 2023](https://www.youtube.com/watch?v=-uoEro1jsBI&t=2140s). We can’t wait to share what we’re working on!
diff --git a/fumadocs/content/blog/2023-01-20-whats-new-in-2023/recovery_restore_machine.gif b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/recovery_restore_machine.gif
new file mode 100644
index 000000000..5483a2668
Binary files /dev/null and b/fumadocs/content/blog/2023-01-20-whats-new-in-2023/recovery_restore_machine.gif differ
diff --git a/fumadocs/content/blog/2023-02-06-github-import-machines/github-import-machine.gif b/fumadocs/content/blog/2023-02-06-github-import-machines/github-import-machine.gif
new file mode 100644
index 000000000..b2dde3115
Binary files /dev/null and b/fumadocs/content/blog/2023-02-06-github-import-machines/github-import-machine.gif differ
diff --git a/fumadocs/content/blog/2023-02-06-github-import-machines/github-install-integration.gif b/fumadocs/content/blog/2023-02-06-github-import-machines/github-install-integration.gif
new file mode 100644
index 000000000..d1fb4d8ab
Binary files /dev/null and b/fumadocs/content/blog/2023-02-06-github-import-machines/github-install-integration.gif differ
diff --git a/fumadocs/content/blog/2023-02-06-github-import-machines/github-save-machine.gif b/fumadocs/content/blog/2023-02-06-github-import-machines/github-save-machine.gif
new file mode 100644
index 000000000..a44b1e5b1
Binary files /dev/null and b/fumadocs/content/blog/2023-02-06-github-import-machines/github-save-machine.gif differ
diff --git a/fumadocs/content/blog/2023-02-06-github-import-machines/index.mdx b/fumadocs/content/blog/2023-02-06-github-import-machines/index.mdx
new file mode 100644
index 000000000..ebe2596d0
--- /dev/null
+++ b/fumadocs/content/blog/2023-02-06-github-import-machines/index.mdx
@@ -0,0 +1,52 @@
+---
+title: 'Import machines from GitHub'
+description: Learn about a new pro feature in the Stately Studio; importing machines from GitHub.
+tags: [stately, studio, integration, github]
+authors: [anders]
+image: /blog/2023-02-06-github-import-machines.png
+slug: 2023-02-06-github-import-machines
+date: 2023-02-06
+---
+
+Today we’re happy to introduce another pro feature for our Stately Studio subscribers; **import machines from GitHub**. With this feature, you can quickly visually machines in any of your GitHub repositories. You can even import the machines to the Studio and keep working on them here 🎉
+
+{/* truncate */}
+
+## How to
+
+Importing a machine is easy. You open a file containing one or more machines on GitHub. Next, you modify the URL, replace `.com` with `.stately.ai`, and the import will start.
+
+
+
+### Example
+
+If you have a machine hosted at GitHub: `https://github.com/username/repo/blob/main/apps/superMachine.ts`, you update the URL to `https://github.stately.ai/username/repo/blob/main/apps/superMachine.ts` and the import will start 🚀
+
+### Saving the machine
+
+You can easily save imported machines into a Studio project. After the import, you click the save button and choose a project for the machine.
+
+
+
+## Get started
+
+This feature requires the following prerequisites:
+
+- A **professional or enterprise** subscription to the Stately Studio.
+- You must install the GitHub integration app.
+
+When importing a machine, we help you with both of those tasks.
+
+Your GitHub token is stored on your own devices by design; we don’t save it in our database. This is to keep your data as safe as possible with the tradeoff being that you must accept the integration on the initial import for each device you use.
+
+See this example where the GitHub integration gets installed during the initial import.
+
+
+
+## Future work
+
+We have much more planned for integrating with GitHub; this is just the start. Let us know what you think about the machine import and what GitHub integration features you would like to see in the Stately Studio.
+
+### Bookmarklet bonus
+
+You can create a [bookmarklet](https://en.wikipedia.org/wiki/Bookmarklet) if you want to make it extra easy to import machines from GitHub. You do this by adding a new bookmark and setting the web address to `javascript:(function(){ location.href = 'https://github.stately.ai/' + window.location.pathname;})();`. Now you can click the bookmarklet whenever you want to import a machine. The bookmarklet will work on any GitHub file containing one or more machines.
diff --git a/fumadocs/content/blog/2023-03-09-import-all-machines-from-github-repo/2023-03-09-import-all-machines-from-github-repo-button.png b/fumadocs/content/blog/2023-03-09-import-all-machines-from-github-repo/2023-03-09-import-all-machines-from-github-repo-button.png
new file mode 100644
index 000000000..092a037a8
Binary files /dev/null and b/fumadocs/content/blog/2023-03-09-import-all-machines-from-github-repo/2023-03-09-import-all-machines-from-github-repo-button.png differ
diff --git a/fumadocs/content/blog/2023-03-09-import-all-machines-from-github-repo/index.mdx b/fumadocs/content/blog/2023-03-09-import-all-machines-from-github-repo/index.mdx
new file mode 100644
index 000000000..6a60f3d28
--- /dev/null
+++ b/fumadocs/content/blog/2023-03-09-import-all-machines-from-github-repo/index.mdx
@@ -0,0 +1,33 @@
+---
+title: 'Import all machines from your GitHub repo'
+description: Learn about a new pro feature in the Stately Studio; importing all your machines from a GitHub repo.
+tags: [stately, studio, integration, github]
+authors: [laura]
+image: /blog/2023-03-09-import-all-machines-from-github-repo.png
+slug: 2023-03-09-import-all-machines-from-github-repo
+date: 2023-03-09
+---
+
+Last month, Anders showed you how you could [import a machine from GitHub by changing the GitHub URL in the browser’s address bar](../../docs/assets/blog/2023-02-06-github-import-machines/index). We’ve added more to our GitHub integration. Our [Pro](https://stately.ai/pricing) users can now import all the machines from a repository into a Stately Studio project with the **Import from GitHub** button.
+
+{/* truncate */}
+
+
+
+If you’ve been working with state machines in XState or using the [XState VS Code extension](https://marketplace.visualstudio.com/items?itemName=statelyai.stately-vscode) to visualize your machines, this is a great way to import all the machines in your repo quickly. Once you’ve imported your machines into the Stately Studio, you can visualize and improve them in our Editor and easily share your machines with your team.
+
+## How to import all the machines from a GitHub repository
+
+1. Navigate to **My Projects** from the sidebar or the Stately menu.
+2. Use **Import from GitHub** to open the Import repo from GitHub modal.
+3. The GitHub integration will fetch all available repositories (public and private).
+4. Choose the repository from which you wish to import machines.
+5. The Studio will import your machines into a new private project using the same name as your repository and open your project in the Editor.
+
+Importing a machine with **Import from GitHub** or importing a machine with a GitHub URL will prompt you to **Allow integration** to give our GitHub integration access to your GitHub repositories. You will only be prompted if you have not yet given the GitHub integration access on your current device.
+
+Currently, the **Import from GitHub** feature imports all machines from the _default branch_ in your GitHub repository. If you want to import machines from a different branch or a pull request, we recommend [importing each machine from a GitHub URL](../../docs/assets/blog/2023-02-06-github-import-machines/index).
+
+## Try our Pro plan to import from GitHub
+
+Import from GitHub is one of the [Pro features](https://stately.ai/docs/studio-pro-plan) of the Stately Studio. We offer a **free trial** on the [Stately Studio Pro account](https://stately.ai/pricing) so you can explore how our Pro features work for you and your team today!
diff --git a/fumadocs/content/blog/2023-04-03-book-a-demo/index.mdx b/fumadocs/content/blog/2023-04-03-book-a-demo/index.mdx
new file mode 100644
index 000000000..55cd7aa04
--- /dev/null
+++ b/fumadocs/content/blog/2023-04-03-book-a-demo/index.mdx
@@ -0,0 +1,41 @@
+---
+title: 'Book a demo with the Stately team'
+description: Are you looking to take your team collaboration to the next level? Do you want to explore the features of Stately and XState to their fullest potential? Then book a live demo with the Stately team!
+tags: [stately, studio, demo, xstate]
+authors: [laura]
+image: /blog/2023-04-03-book-a-demo.png
+slug: 2023-04-03-book-a-demo
+date: 2023-04-03
+---
+
+Are you looking to take your team collaboration to the next level? Do you want to explore the features of Stately and XState to their fullest potential? Then book a live demo with the Stately team !
+
+{/* truncate */}
+
+Our team is excited to give you a walkthrough of the Stately Studio and explore your use cases. During the demo, you can get answers to all your questions about Stately and XState. Learning more about you and your team will help us develop future features that benefit your work.
+
+What can you expect from a live demo with the Stately team?
+
+## Walkthrough of the Stately Studio
+
+Get an in-depth tour of Stately’s visual editor and its features. Explore how the Stately Studio works for teams and learn how to build complex state machines quickly.
+
+## Explore your use cases
+
+Our team will help you explore the Stately Studio’s features by walking you through your use cases. We can help you understand how Stately can be used to solve your specific problems and how you can integrate it into your workflow.
+
+## Answer any questions you have about Stately and XState
+
+During the demo, our team will answer your questions about Stately and XState. Whether you’re curious about a particular feature or want to know how Stately can help you solve a specific problem, our team will provide the answers you need.
+
+## Follow-up demo designed for your team and use cases
+
+After the demo, our team can work with you to schedule a follow-up demo that is designed specifically for your team and use cases. We will consider your feedback from the initial demo and create a customized demo that meets your specific needs.
+
+
+ Use the link below to book your live demo. We look forward to helping you
+ build amazing applications with Stately and XState.
+
diff --git a/fumadocs/content/blog/2023-04-21-embed-url/index.mdx b/fumadocs/content/blog/2023-04-21-embed-url/index.mdx
new file mode 100644
index 000000000..7e03a3df6
--- /dev/null
+++ b/fumadocs/content/blog/2023-04-21-embed-url/index.mdx
@@ -0,0 +1,17 @@
+---
+title: Embed URL
+description: '🤫 We’re testing a new feature where you can embed machines.'
+authors: [laura]
+tags: [changelog, new, beta]
+date: 2023-04-21
+slug: 2023-04-21-embed-url
+image: /blog/2023-07-18-embed-url.png
+---
+
+🤫 We’re testing a new feature where you can embed machines.
+
+From the **Share** menu, there’s now a **Copy embed URL** button. You can use this URL in an `
+
+Overall, I found the whole process from visualizing the logic to plugging the generated code into my web app incredibly fruitful. I've already identified ways to extend and improve the machine as needed, like adding error capturing in place of the default `logError` action and breaking out the `dropHandler` Promise actor into an explicit state machine actor. I hope folks on my team and in the [Viam community](https://discord.gg/viam) will understand this application better with this refactor in place.
+
+Happy Building!
diff --git a/fumadocs/content/blog/2024-07-29-claw-game-state-machine/mermaid-diagram-moving-states.svg b/fumadocs/content/blog/2024-07-29-claw-game-state-machine/mermaid-diagram-moving-states.svg
new file mode 100644
index 000000000..148879711
--- /dev/null
+++ b/fumadocs/content/blog/2024-07-29-claw-game-state-machine/mermaid-diagram-moving-states.svg
@@ -0,0 +1,3 @@
+
+
+Claw Machine
move
done.invoke.armMover
error.platform.armMover
xstate.after(3000)#Claw Machine.displayingMoveError
ready
moving
displayingMoveError
Claw Machine
dropAndHome
done.invoke.picker
error.platform.picker
xstate.after(2000)#Claw Machine.displayingPickerError
ready
picking
displayingPickerError
Claw Machine
connect
done.invoke.clientConnection
error.platform.clientConnection
retry
always
initializing
connectingToMachine
connected
clientErrored
ready
+
+
+In today's remote-first world, where teams are more distributed than ever before and user needs are more complex than ever before, the demand for a capable webinar platform has skyrocketed. Remote teams all need a platform for effective communication and collaboration and businesses need a way to reach their customers, enable and gauge user interaction, and be able to scale outreach as necessary. Meet WebinarGeek, the premier streaming platform for hosting webinars. WebinarGeek takes the complexity out of juggling users' own “go-lives” by providing an easy-to-use yet feature rich interface. Users can roll out fully live or hybrid sessions, create paywalls with premium webinars, and even integrate with existing industry-leading marketing tools to better understand their audiences.
+
+### Wrangling in complexity
+
+Any professional working in web broadcasting would agree that streaming media is anything but trivial. Underneath WebinarGeek's slick interface lies a massive amount of technical complexity. For handling streams alone, the team at WebinarGeek has to wrangle WebRTC and all its concerns, like managing RTMP and several other protocols. On top of that, WebinarGeek offers differentiating features for their users, like the ability to automate webinar streams to give the illusion of live streaming and integrating with popular marketing platforms. Orchestrating all these dependencies to work together consistently required a comprehensive framework for managing several stateful components, so the team at WebinarGeek turned to Stately tooling to accomplish this.
+
+WebinarGeek's platform was originally built as a monolithic Ruby on Rails application back in 2015, and the original implementation wasn't ideal. While Ruby on Rails was an excellent technical choice for building the software that managed accounts and the webinar itself, synchronizing with various events on the streaming page was difficult to implement, introducing limitations for newer features that could be implemented. For example, only one presenter could be on-screen at a time and the frontend would struggle responding to various video player events. The streaming page was responsible for managing tons of _implicit_ state and event management, but there was no core framework in place to handle this. This eventually led to spread out, disparate logic with no real context and became difficult to maintain and add new functionality to.
+
+### The “Great Refactor”: a UI overhaul with Stately tooling
+
+The team knew that a refactoring had to happen, but it wasn't until the 2020 pandemic that such a need took center stage. Demand for comprehensive streaming solutions skyrocketed with the wave of professionals working remotely, and WebinarGeek's traffic skyrocketed. To meet the demand, to scale more efficiently, and to handle heavy user interactions, the team decided to rebuild the app's streaming page with ReactJS and Typescript. With prior experience as their guide, the team knew they would need a state management library to handle all the possible events flowing through the frontend. While React gives developers the ability to create incredibly responsive applications, only re-rendering elements that have actually changed _when_ they need to change, the team found that juggling `useEffect`, `useState`, and `useContext` were not very scalable. These hooks, while useful, are not ideal for colocating business logic in a single layer for re-usability. The team investigated several alternatives, like React-Query, Redux, and XState. Ultimately, WebinarGeek settled on XState for its simple declarative programming model for handling transitions, visualizing their rather complex logic, and firing side effects. It turned out that composing their business logic with state machines made perfect sense on their streaming page. Now, the team had the ability to create _explicit_ states that more closely mirrored what was actually happening on the frontend, like “Live” and “Ended” to represent states of the running stream. By defining all possible interactions as explicit events, the team was able to implement all their business logic in a single place, and this ensured that proper side effects would always execute when transitioning from one state to another. As an example, a timer must always start when the stream has transitioned to “Live”, and an evaluation form must be presented to the audience when the webinar has transitioned to “Ended” .
+
+Building in this way, with explicit states and introducing barriers for what events to respond to, ultimately gave the team more confidence in adding more complex logic to their streaming page. As an example, during a given webinar, the application has to orchestrate events coming from various sources, like WebRTC, user button clicks, the video player, and even web sockets. All of these events have special considerations that need to be addressed, but they are all in service of achieving similar business goals. This cohesion allowed the WebinarGeek team to rebuild and ship the new streaming page in less than a year. As an example, state machine below illustrates the flow for loading new messages into the chat window:
+
+
+ Latest Blog Posts
+
+ {posts.map((post) => (
+
+
{post.data.title}
+
{post.data.description}
+
+ ))}
+
+ );
+}
diff --git a/fumadocs/content/components/EmbedMachine.tsx b/fumadocs/content/components/EmbedMachine.tsx
new file mode 100644
index 000000000..31b9bcd08
--- /dev/null
+++ b/fumadocs/content/components/EmbedMachine.tsx
@@ -0,0 +1,34 @@
+// import { useColorMode } from '@docusaurus/theme-common';
+type Embed = {
+ name: string;
+ embedURL: string;
+};
+
+export function EmbedMachine({ name, embedURL }: Embed) {
+ // const { colorMode } = useColorMode();
+ return (
+
+ );
+}
+
+function manageURL(
+ embedURL: string,
+ options?: { colorMode: 'light' | 'dark' },
+): string {
+ const url = new URL(embedURL);
+ for (const opt in options) {
+ url.searchParams.set(opt, options[opt]);
+ }
+ return url.toString();
+}
diff --git a/fumadocs/content/components/ThemedImage.tsx b/fumadocs/content/components/ThemedImage.tsx
new file mode 100644
index 000000000..7f8349304
--- /dev/null
+++ b/fumadocs/content/components/ThemedImage.tsx
@@ -0,0 +1,38 @@
+'use client';
+
+import Image from 'next/image';
+import { useTheme } from 'next-themes';
+import { useEffect, useState } from 'react';
+
+interface ThemedImageProps {
+ alt: string;
+ sources: {
+ light: string;
+ dark: string;
+ };
+ width?: number;
+ height?: number;
+ className?: string;
+ priority?: boolean;
+}
+
+export function ThemedImage({
+ alt,
+ sources,
+ width,
+ height,
+ className,
+ priority = false,
+}: ThemedImageProps) {
+ const { theme, resolvedTheme } = useTheme();
+
+ return (
+
+
+ );
+}
diff --git a/fumadocs/content/docs/actions.mdx b/fumadocs/content/docs/actions.mdx
new file mode 100644
index 000000000..b2661576c
--- /dev/null
+++ b/fumadocs/content/docs/actions.mdx
@@ -0,0 +1,1069 @@
+---
+title: 'Actions'
+---
+
+Actions are fire-and-forget effects. When a state machine transitions, it may execute actions. Actions occur in response to events, and are typically defined on transitions in the `actions: [...]` property. Actions can also be defined for any transition that enters a state in the state's `entry: [...]` property, or for any transition that exits a state in the state's `exit: [...]` property.
+
+
+
+You can visualize your state machines and easily add actions in our drag-and-drop Stately editor. [Read more about actions in Stately’s editor](editor-actions-and-actors).
+
+
+
+Actions can also be on a state’s `entry` or `exit`, also as a single action or an array.
+
+```ts
+import { setup } from 'xstate';
+
+function trackResponse(response: string) {
+ // ...
+}
+
+const feedbackMachine = setup({
+ actions: {
+ track: (_, params: { response: string }) => {
+ trackResponse(params.response);
+ // Tracks { response: 'good' }
+ },
+ showConfetti: () => {
+ // ...
+ }
+ }
+}).createMachine({
+ // ...
+ states: {
+ // ...
+ question: {
+ on: {
+ 'feedback.good': {
+ actions: [
+ { type: 'track', params: { response: 'good' } }
+ ]
+ }
+ },
+ exit: [
+ { type: 'exitAction' }
+ ]
+ }
+ thanks: {
+ entry: [
+ { type: 'showConfetti' }
+ ],
+ }
+ }
+});
+```
+
+Examples of actions:
+
+- Logging a message
+- Sending a message to another [actor](actors)
+- Updating context
+
+## Entry and exit actions
+
+Entry actions are actions that occur on any transition that enters a state node. Exit actions are actions that occur on any transition that exits a state node.
+
+Entry and exit actions are defined using the `entry: [...]` and `exit: [...]` attributes on a state node. You can fire multiple entry and exit actions on a state. Top-level final states cannot have exit actions, since the machine is stopped and no further transitions can occur.
+
+
+
+Built-in actions, such as `assign(…)`, `sendTo(…)`, and `raise(…)`, are **not imperative**; they return a special [action object](#action-objects) (e.g. `{ type: 'xstate.assign', … }`) that are interpreted by the state machine. Do not call built-in action in custom action functions.
+
+```ts
+// ❌ This will have no effect
+const machine = createMachine({
+ context: { count: 0 },
+ // [!code highlight:5]
+ entry: ({ context }) => {
+ // This action creator only returns an action object
+ // like { type: 'xstate.assign', ... }
+ assign({ count: context.count + 1 });
+ },
+});
+
+// ✅ This will work as expected
+const machine = createMachine({
+ context: { count: 0 },
+ // [!code highlight:3]
+ entry: assign({
+ count: ({ context }) => context.count + 1,
+ }),
+});
+
+// ✅ Imperative built-in actions are available in `enqueueActions(…)`
+const machine = createMachine({
+ context: { count: 0 },
+ // [!code highlight:5]
+ entry: enqueueActions(({ context, enqueue }) => {
+ enqueue.assign({
+ count: context.count + 1,
+ });
+ }),
+});
+```
+
+
+
+## Assign action
+
+The `assign(...)` action is a special action that assigns data to the state context. The `assignments` argument in `assign(assignments)` is where assignments to context are specified.
+
+Assignments can be an object of key-value pairs where the keys are `context` keys and the values are either static values or expressions that return the new value:
+
+```ts
+import { setup } from 'xstate';
+
+const countMachine = setup({
+ types: {
+ events: {} as { type: 'increment'; value: number },
+ },
+}).createMachine({
+ context: {
+ count: 0,
+ },
+ on: {
+ increment: {
+ // [!code highlight:3]
+ actions: assign({
+ count: ({ context, event }) => context.count + event.value,
+ }),
+ },
+ },
+});
+
+const countActor = createActor(countMachine);
+countActor.subscribe((state) => {
+ console.log(state.context.count);
+});
+countActor.start();
+// logs 0
+
+countActor.send({ type: 'increment', value: 3 });
+// logs 3
+
+countActor.send({ type: 'increment', value: 2 });
+// logs 5
+```
+
+For more dynamic assignments, the argument passed to `assign(...)` may also be a function that returns the partial or full `context` value:
+
+```ts
+import { setup } from 'xstate';
+
+const countMachine = setup({
+ types: {
+ events: {} as { type: 'increment'; value: number },
+ },
+}).createMachine({
+ context: {
+ count: 0,
+ },
+ on: {
+ increment: {
+ // [!code highlight:5]
+ actions: assign(({ context, event }) => {
+ return {
+ count: context.count + event.value,
+ };
+ }),
+ },
+ },
+});
+```
+
+
+
+Do not mutate the `context` object. Instead, you should use the `assign(...)` action to update `context` immutably. If you mutate the `context` object, you may get unexpected behavior, such as mutating the `context` of other actors.
+
+
+
+
+
+You can create state machines with the `assign(...)` action in our drag-and-drop Stately editor. [Read more about built-in assign action in Stately’s editor](/docs/editor-actions-and-actors/#xstate-built-in-actions).
+
+
+
+## Raise action
+
+The raise action is a special action that _raises_ an event that is received by the same machine. Raising an event is how a machine can “send” an event to itself:
+
+```ts
+import { createMachine, raise } from 'xstate';
+
+const machine = createMachine({
+ // ...
+ // [!code highlight:1]
+ entry: raise({ type: 'someEvent', data: 'someData' });
+});
+```
+
+Internally, when an event is raised, it is placed into an “internal event queue”. After the current transition is finished, these events are processed in insertion order ([first-in first-out, or FIFO]()). External events are only processed once all events in the internal event queue are processed.
+
+Raised events can be dynamic:
+
+```ts
+import { createMachine, raise } from 'xstate';
+
+const machine = createMachine({
+ // ...
+ // [!code highlight:4]
+ entry: raise(({ context, event }) => ({
+ type: 'dynamicEvent',
+ data: context.someValue,
+ })),
+});
+```
+
+Events can also be raised with a delay, which will not place them in the internal event queue, since they will not be immediately processed:
+
+```ts
+import { createMachine, raise } from 'xstate';
+
+const machine = createMachine({
+ // ...
+ entry: raise(
+ { type: 'someEvent' },
+ // [!code highlight:1]
+ { delay: 1000 }
+ );
+});
+```
+
+
+
+You can create state machines with the `raise(...)` action in our drag-and-drop Stately editor. [Read more about the built-in raise action in Stately’s editor](/docs/editor-actions-and-actors/#xstate-built-in-actions).
+
+
+
+## Send-to action
+
+The `sendTo(...)` action is a special action that sends an event to a specific actor.
+
+```ts
+const machine = createMachine({
+ on: {
+ transmit: {
+ // [!code highlight:1]
+ actions: sendTo('someActor', { type: 'someEvent' }),
+ },
+ },
+});
+```
+
+The event can be dynamic:
+
+```ts
+const machine = createMachine({
+ on: {
+ transmit: {
+ // [!code highlight:3]
+ actions: sendTo('someActor', ({ context, event }) => {
+ return { type: 'someEvent', data: context.someData };
+ }),
+ },
+ },
+});
+```
+
+The destination actor can be the actor ID or the actor reference itself:
+
+```ts
+const machine = createMachine({
+ context: ({ spawn }) => ({
+ someActorRef: spawn(fromPromise(/* ... */)),
+ }),
+ on: {
+ transmit: {
+ // [!code highlight:3]
+ actions: sendTo(({ context }) => context.someActorRef, {
+ type: 'someEvent',
+ }),
+ },
+ },
+});
+```
+
+Other options, such as `delay` and `id`, can be passed as the 3rd argument:
+
+```ts
+const machine = createMachine({
+ on: {
+ transmit: {
+ actions: sendTo(
+ 'someActor',
+ { type: 'someEvent' },
+ // [!code highlight:4]
+ {
+ id: 'transmission',
+ delay: 1000,
+ },
+ ),
+ },
+ },
+});
+```
+
+Delayed actions can be cancelled by their `id`. See [`cancel(...)`](https://stately.ai/docs/actions#cancel-action).
+
+
+
+You can create state machines with the `sendTo(...)` action in our drag-and-drop Stately editor. [Read more about the built-in sendTo action in Stately’s editor](/docs/editor-actions-and-actors/#xstate-built-in-actions).
+
+
+
+## Send-parent action
+
+The `sendParent(...)` action is a special action that sends an event to the parent actor, if it exists.
+
+
+
+It is recommended to use `sendTo(...)` by to pass actor refs (e.g. the parent actor ref) to other actors via [input](./input.ts) or events and storing those actor refs in `context` rather than using `sendParent(...)`. This avoids tight coupling between actors and can be more type-safe.
+
+
+Example using input:
+
+```ts
+import { createMachine, sendTo } from 'xstate';
+
+const childMachine = createMachine({
+ context: ({ input }) => ({
+ parentRef: input.parentRef,
+ }),
+ on: {
+ someEvent: {
+ // [!code highlight:3]
+ actions: sendTo(({ context }) => context.parentRef, {
+ type: 'tellParentSomething',
+ }),
+ },
+ },
+});
+
+const parentMachine = createMachine({
+ // ...
+ invoke: {
+ id: 'child',
+ src: childMachine,
+ // [!code highlight:3]
+ input: ({ self }) => ({
+ parentRef: self,
+ }),
+ },
+ on: {
+ tellParentSomething: {
+ actions: () => {
+ console.log('Child actor told parent something');
+ },
+ },
+ },
+});
+
+const parentActor = createActor(parentMachine);
+
+parentActor.start();
+```
+
+
+
+
+Example using input (TypeScript):
+
+```ts
+import { ActorRef, createActor, log, sendTo, setup, Snapshot } from 'xstate';
+
+// [!code highlight:5]
+type ChildEvent = {
+ type: 'tellParentSomething';
+ data?: string;
+};
+type ParentActor = ActorRef, ChildEvent>;
+
+const childMachine = setup({
+ types: {
+ context: {} as {
+ parentRef: ParentActor;
+ },
+ input: {} as {
+ parentRef: ParentActor;
+ },
+ },
+}).createMachine({
+ context: ({ input: { parentRef } }) => ({ parentRef }),
+ // [!code highlight:4]
+ entry: sendTo(({ context }) => context.parentRef, {
+ type: 'tellParentSomething',
+ data: 'Hi parent!',
+ }),
+});
+
+export const parent = setup({
+ actors: { child: childMachine },
+}).createMachine({
+ // [!code highlight:6]
+ invoke: {
+ src: 'child',
+ input: ({ self }) => ({
+ parentRef: self,
+ }),
+ },
+ on: {
+ tellParentSomething: {
+ actions: log(({ event: { data } }) => `Child actor says "${data}"`),
+ },
+ },
+});
+
+createActor(parent).start();
+```
+
+
+
+
+
+## Enqueue actions
+
+The `enqueueActions(...)` action creator is a higher-level action that enqueues actions to be executed sequentially, without actually executing any of the actions. It takes a callback that receives the `context`, `event` as well as `enqueue` and `check` functions:
+
+- The `enqueue(...)` function is used to enqueue an action. It takes an action object or action function:
+
+ ```ts
+ actions: enqueueActions(({ enqueue }) => {
+ // Enqueue an action object
+ enqueue({ type: 'greet', params: { message: 'hi' } });
+
+ // Enqueue an action function
+ enqueue(() => console.log('Hello'));
+
+ // Enqueue a simple action with no params
+ enqueue('doSomething');
+ });
+ ```
+
+- The `check(...)` function is used to conditionally enqueue an action. It takes a guard object or a guard function and returns a boolean that represents whether the guard evaluates to `true`:
+ ```ts
+ actions: enqueueActions(({ enqueue, check }) => {
+ if (check({ type: 'everythingLooksGood' })) {
+ enqueue('doSomething');
+ }
+ });
+ ```
+- There are also helper methods on `enqueue` for enqueueing built-in actions:
+ - `enqueue.assign(...)`: Enqueues an `assign(...)` action
+ - `enqueue.sendTo(...)`: Enqueues a `sendTo(...)` action
+ - `enqueue.raise(...)`: Enqueues a `raise(...)` action
+ - `enqueue.spawnChild(...)`: Enqueues a `spawnChild(...)` action
+ - `enqueue.stopChild(...)`: Enqueues a `stopChild(...)` action
+ - `enqueue.cancel(...)`: Enqueues a `cancel(...)` action
+
+Enqueued actions can be called conditionally, but they cannot be enqueued asynchronously.
+
+```ts
+const machine = createMachine({
+ // ...
+ entry: enqueueActions(({ context, event, enqueue, check }) => {
+ // assign action
+ enqueue.assign({
+ count: context.count + 1,
+ });
+
+ // Conditional actions (replaces choose(...))
+ if (event.someOption) {
+ enqueue.sendTo('someActor', { type: 'blah', thing: context.thing });
+
+ // other actions
+ enqueue('namedAction');
+ // with params
+ enqueue({ type: 'greet', params: { message: 'hello' } });
+ } else {
+ // inline
+ enqueue(() => console.log('hello'));
+
+ // even built-in actions
+ }
+
+ // Use check(...) to conditionally enqueue actions based on a guard
+ if (check({ type: 'someGuard' })) {
+ // ...
+ }
+
+ // no return
+ }),
+});
+```
+
+You can use parameters with referenced enqueue actions:
+
+```ts
+import { setup, enqueueActions } from 'xstate';
+
+const machine = setup({
+ actions: {
+ // [!code highlight:4]
+ doThings: enqueueActions(({ enqueue }, params: { name: string }) => {
+ enqueue({ type: 'greet', params: { name } });
+ // ...
+ }),
+ greet: (_, params: { name: string }) => {
+ console.log(`Hello ${params.name}!`);
+ },
+ },
+}).createMachine({
+ // ...
+ // [!code highlight:4]
+ entry: {
+ type: 'doThings',
+ params: { name: 'World' },
+ },
+});
+```
+
+## Log action
+
+The `log(...)` action is an easy way to log messages to the console.
+
+```ts
+import { createMachine, log } from 'xstate';
+
+const machine = createMachine({
+ on: {
+ someEvent: {
+ // [!code highlight:1]
+ actions: log('some message'),
+ },
+ },
+});
+```
+
+
+
+You can create state machines with the `log(...)` action in our drag-and-drop Stately editor. [Read more about the built-in log action in Stately’s editor](/docs/editor-actions-and-actors/#xstate-built-in-actions).
+
+
+
+## Cancel action
+
+The `cancel(...)` action cancels a delayed `sendTo(...)` or `raise(...)` action by their IDs:
+
+```ts
+import { createMachine, sendTo, cancel } from 'xstate';
+
+const machine = createMachine({
+ on: {
+ event: {
+ actions: sendTo(
+ 'someActor',
+ { type: 'someEvent' },
+ {
+ // [!code highlight:1]
+ id: 'someId',
+ delay: 1000,
+ },
+ ),
+ },
+ cancelEvent: {
+ // [!code highlight:1]
+ actions: cancel('someId'),
+ },
+ },
+});
+```
+
+## Stop child action
+
+The `stopChild(...)` action stops a child actor. Actors can only be stopped from their parent actor:
+
+```ts
+import { createMachine, stopChild } from 'xstate';
+
+const machine = createMachine({
+ context: ({ spawn }) => ({
+ spawnedRef: spawn(fromPromise(/* ... */), { id: 'spawnedId' }),
+ }),
+ on: {
+ stopById: {
+ // [!code highlight:1]
+ actions: stopChild('spawnedId'),
+ },
+ stopByRef: {
+ // [!code highlight:1]
+ actions: stopChild(({ context }) => context.spawnedRef),
+ },
+ },
+});
+```
+
+## Modeling
+
+If you only need to execute actions in response to events, you can create a [self-transition](/docs/transitions#self-transitions) that only has `actions: [ ... ]` defined. For example, a machine that only needs to assign to `context` in transitions may look like this:
+
+```ts
+import { createMachine } from 'xstate';
+
+const countMachine = createMachine({
+ context: {
+ count: 0,
+ },
+ // [!code highlight:12]
+ on: {
+ increment: {
+ actions: assign({
+ count: ({ context, event }) => context.count + event.value,
+ }),
+ },
+ decrement: {
+ actions: assign({
+ count: ({ context, event }) => context.count - event.value,
+ }),
+ },
+ },
+});
+```
+
+## Shorthands
+
+For simple actions, you can specify an action string instead of an action object. Though we prefer using objects for consistency.
+
+```ts
+import { createMachine } from 'xstate';
+
+const feedbackMachine = createMachine({
+ // ...
+ states: {
+ // ...
+ question: {
+ on: {
+ 'feedback.good': {
+ // [!code highlight:1]
+ actions: ['track'],
+ },
+ },
+ },
+ },
+});
+```
+
+## Actions and TypeScript
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+To strongly setup action types, use the `setup({ ... })` function and place the action implementations in the `actions: { ... }` object. The key is the action type and the value is the action function implementation.
+
+You should also strongly type the parameters of the action function, which are passed as the second argument to the action function.
+
+```ts
+import { setup } from 'xstate';
+
+const machine = setup({
+ // [!code highlight:8]
+ actions: {
+ track: (_, params: { response: string }) => {
+ // ...
+ },
+ increment: (_, params: { value: number }) => {
+ // ...
+ },
+ },
+}).createMachine({
+ // ...
+ entry: [
+ { type: 'track', params: { response: 'good' } },
+ { type: 'increment', params: { value: 1 } },
+ ],
+});
+```
+
+If you are not using `setup({ ... })` (strongly recommended), you can strongly type the `actions` of your machine in the `types.actions` property of the machine config.
+
+```ts
+const machine = createMachine({
+ types: {} as {
+ // [!code highlight:8]
+ actions:
+ | {
+ type: 'track';
+ params: {
+ response: string;
+ };
+ }
+ | { type: 'increment'; params: { value: number } };
+ },
+ // ...
+ entry: [
+ { type: 'track', params: { response: 'good' } },
+ { type: 'increment', params: { value: 1 } },
+ ],
+});
+```
+
+## Actions cheatsheet
+
+### Cheatsheet: entry and exit actions
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ // [!code highlight:3]
+ // Entry action on root
+ entry: [{ type: 'entryAction' }],
+ exit: [{ type: 'exitAction' }],
+ initial: 'start',
+ states: {
+ start: {
+ // [!code highlight:2]
+ entry: [{ type: 'startEntryAction' }],
+ exit: [{ type: 'startExitAction' }],
+ },
+ },
+});
+```
+
+### Cheatsheet: transition actions
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ on: {
+ someEvent: {
+ actions: [
+ // [!code highlight:2]
+ { type: 'doSomething' },
+ { type: 'doSomethingElse' },
+ ],
+ },
+ },
+});
+```
+
+### Cheatsheet: inline action functions
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ on: {
+ someEvent: {
+ actions: [
+ // [!code highlight:3]
+ ({ context, event }) => {
+ console.log(context, event);
+ },
+ ],
+ },
+ },
+});
+```
+
+### Cheatsheet: setting up actions
+
+```ts
+import { setup } from 'xstate';
+
+const someAction = () => {
+ //...
+};
+
+const machine = setup({
+ actions: {
+ someAction,
+ },
+}).createMachine({
+ entry: [
+ // [!code highlight:1]
+ { type: 'someAction' },
+ ],
+ // ...
+});
+```
+
+### Cheatsheet: providing actions
+
+```ts
+import { setup } from 'xstate';
+
+const someAction = () => {
+ //...
+};
+
+const machine = setup({
+ actions: {
+ someAction,
+ },
+}).createMachine({
+ // ...
+});
+
+const modifiedMachine = machine.provide({
+ someAction: () => {
+ // Overridden action implementation
+ },
+});
+```
+
+### Cheatsheet: assign action
+
+#### With property assigners
+
+```ts
+import { createMachine } from 'xstate';
+
+const countMachine = createMachine({
+ context: {
+ count: 0,
+ },
+ on: {
+ increment: {
+ // [!code highlight:5]
+ actions: assign({
+ count: ({ context, event }) => {
+ return context.count + event.value;
+ },
+ }),
+ },
+ },
+});
+```
+
+#### With function assigners
+
+```ts
+import { createMachine } from 'xstate';
+
+const countMachine = createMachine({
+ context: {
+ count: 0,
+ },
+ on: {
+ increment: {
+ // [!code highlight:5]
+ actions: assign(({ context, event }) => {
+ return {
+ count: context.count + event.value,
+ };
+ }),
+ },
+ },
+});
+```
+
+### Cheatsheet: raise action
+
+```ts
+import { createMachine, raise } from 'xstate';
+
+const machine = createMachine({
+ on: {
+ someEvent: {
+ // [!code highlight:1]
+ actions: raise({ type: 'anotherEvent' }),
+ },
+ },
+});
+```
+
+### Cheatsheet: send-to action
+
+```ts
+const machine = createMachine({
+ on: {
+ transmit: {
+ // [!code highlight:1]
+ actions: sendTo('someActor', { type: 'someEvent' }),
+ },
+ },
+});
+```
+
+### Cheatsheet: enqueue actions
+
+```ts
+import { createMachine, enqueueActions } from 'xstate';
+
+const machine = createMachine({
+ // [!code highlight:15]
+ entry: enqueueActions(({ enqueue, check }) => {
+ enqueue({ type: 'someAction' });
+
+ if (check({ type: 'someGuard' })) {
+ enqueue({ type: 'anotherAction' });
+ }
+
+ enqueue.assign({
+ count: 0,
+ });
+
+ enqueue.sendTo('someActor', { type: 'someEvent' });
+
+ enqueue.raise({ type: 'anEvent' });
+ }),
+});
+```
diff --git a/fumadocs/content/docs/actor-model.mdx b/fumadocs/content/docs/actor-model.mdx
new file mode 100644
index 000000000..af8eb59d2
--- /dev/null
+++ b/fumadocs/content/docs/actor-model.mdx
@@ -0,0 +1,82 @@
+---
+title: The Actor model
+---
+
+The [Actor model](https://en.wikipedia.org/wiki/Actor_model) in computer science is a mathematical model of concurrent computation in which an “actor” is the basic building block.
+
+The actor model allows developers to build reliable message-based systems by using actors to communicate. State machines and statecharts can model the logic of actors. These actors can communicate with each other, and with other actors, in the same way.
+
+
+When you run a state machine in XState, it becomes an actor.
+
+
+### What defines an “actor”?
+
+Actors are independent “live” objects that can communicate with each other via asynchronous message passing. In XState, we refer to these messages as [_events_](transitions).
+
+- An actor has its own internal, encapsulated state that can only be updated by the actor itself. An actor may choose to update its internal state in response to a message it receives, but it cannot be updated by any other entity.
+- Actors communicate with other actors by sending and receiving events asynchronously.
+- Actors process one message at a time. They have an internal “mailbox” that acts like an event queue, processing events sequentially.
+- Internal actor state is not shared between actors. The only way for an actor to share any part of its internal state is by:
+ - Sending events to other actors
+ - Or emitting snapshots, which can be considered implicit events sent to subscribers.
+- Actors can create (spawn/invoke) new actors.
+
+You’ll find strong similarities to the actor model in software you may already be familiar with. The concept of objects encapsulating state and passing messages to each other may be familiar from Object-Oriented Programming. And actors are analagous to real-world physical concepts like cell biology, and communication in human relationships.
+
+## State
+
+An actor has its own internal, encapsulated state that only the actor itself can update. An actor may update its internal state in response to a message it receives, but it cannot be updated by any other entity. Actors do not share state. The only way for an actor to share data is by sending events.
+
+[Read more about XState actors and state](actors).
+
+## Communication with events
+
+Actors communicate with other actors by sending and receiving events asynchronously. Actors use an internal “mailbox” that acts like an event queue, processing events one at a time.
+
+[Read more about XState events and transitions](transitions).
+
+## Spawning
+
+Actors can spawn new actors, which is useful in situations where an actor needs to delegate work to another actor. Spawning allows for a flexible and dynamic system where actors can be created and destroyed as needed to handle the workload efficiently.
+
+- [Read more about spawning actors in XState](spawn).
+- [Read about the difference between invoking and spawning actors in XState](actors.mdx#invoking-and-spawning-actors).
+
+## The actor model in backend development
+
+The actor model is often used to coordinate backend systems. There are direct implementations of the Actor model, like [Akka](https://doc.akka.io/docs/akka/current/typed/guide/introduction.html) for the JVM. In [Erlang](https://www.erlang.org/docs), processes can be seen as actors, which can send and receive messages and spawn new processes. Erlang is used by massive distributed systems, like Discord and WhatsApp.
+
+In [Stately Sky](https://stately.ai/docs/stately-sky-getting-started), a state machine actor can be used to manage long-running backend processes like medical patient onboarding flows, inventory management, or multi-player collaborative experiences like whiteboard canvases or games.
+
+## The actor model in frontend development
+
+The actor model is especially useful for coordinating the many moving parts of a front-end web application.
+
+**Your front-end app is always a distributed system**, and managing distributed systems is where the actor model shines. This is because in a browser environment **you never really have a “global source of truth”**, you instead have **many independent sources of state and events**: 3rd-party components, local component state, local storage, query parameters, routers, network I/O, DOM events and their listeners, etc.
+
+> […] there is no such thing as a single source of truth in any non-trivial application. All applications, even front-end apps, are distributed at some level. – via: [Redux is Half of a Pattern (2/2)](https://dev.to/davidkpiano/redux-is-half-of-a-pattern-2-2-4jo3)
+
+So even for simple web apps, with small app-specific state and a few known app-specific events, the actor model can be helpful.
+
+## XState
+
+Actors in XState can:
+
+- **Accept messages** as [events](/docs/transitions/#event-objects) passed to their own internal logic, or for state machines as received by [transitions](transitions).
+- **Create more actors** within a state machine using `spawn` in an [`assign`](/docs/actions/#assign-action), or using the `spawnChild` action creator. For details, see [Spawn](spawn).
+- **Send more messages** as events using `self.send` in their own logic, or [action creators](actions) like [`sendTo`](/docs/actions/#send-to-action) or [`raise`](/docs/actions/#raise-action) in a state machine.
+
+Actors in XState have their own [actor logic](/docs/actors/#actor-logic) which they use to:
+
+- **Make local decisions**
+- **Determine how to respond to the next message received**
+- **Modify their own private state** (but only affect each other via messaging)
+
+Actors in XState exist in [systems](system) and can communicate with each other within and across those systems.
+
+## Reference
+
+- [What is the actor model and when should I use it?](https://stately.ai/blog/what-is-the-actor-model)
+- [The Actor Model Explained in 5 Minutes](https://www.youtube.com/watch?v=ELwEdb_pD0k)
+- [Wikipedia: Actor model](https://en.wikipedia.org/wiki/Actor_model)
diff --git a/fumadocs/content/docs/actors.mdx b/fumadocs/content/docs/actors.mdx
new file mode 100644
index 000000000..0d1488601
--- /dev/null
+++ b/fumadocs/content/docs/actors.mdx
@@ -0,0 +1,915 @@
+---
+title: 'Actors'
+---
+
+import { VideoIcon } from 'lucide-react';
+
+When you run a state machine, it becomes an actor: a running process that can receive events, send events and change its behavior based on the events it receives, which can cause effects outside of the actor.
+
+In state machines, actors can be **invoked** or **spawned**. These are essentially the same, with the only difference being how the actor’s lifecycle is controlled.
+
+- An **invoked actor** is started when its parent machine enters the [state](states) it is invoked in, and stopped when that state is exited.
+- A **spawned actor** is started in a [transition](transitions) and stopped either with a [`stop(...)` action](/docs/actions/#stop-action) or when its parent machine is stopped.
+
+
+
+You can visualize your state machines and easily invoke actors in our drag-and-drop Stately editor.
+
+[Read more about actors in Stately’s editor](editor-actions-and-actors).
+
+
+
+,
+);
+
+const canvasMachine = setup({
+ actors: {
+ mouseClickLogic,
+ },
+}).createMachine({
+ invoke: {
+ // Will send mouse click events to the canvas actor
+ src: 'mouseClickLogic',
+ },
+});
+
+const canvasActor = createActor(canvasMachine);
+canvasActor.start();
+```
+
+Learn more about [observable actors.](observable-actors)
+
+### Callback logic (`fromCallback(...)`) [#fromcallback]
+
+Callback actor logic is described by a callback function that receives a single object argument that includes a `sendBack(event)` function and a `receive(event => ...)` function. Actors created from callback logic (“callback actors”) can:
+
+- Receive events via the `receive` function
+- Send events to the parent actor via the `sendBack` function
+
+```ts
+const callbackLogic = fromCallback(({ sendBack, receive }) => {
+ let lockStatus = 'unlocked';
+
+ const handler = (event) => {
+ if (lockStatus === 'locked') {
+ return;
+ }
+ sendBack(event);
+ };
+
+ receive((event) => {
+ if (event.type === 'lock') {
+ lockStatus = 'locked';
+ } else if (event.type === 'unlock') {
+ lockStatus = 'unlocked';
+ }
+ });
+
+ document.body.addEventListener('click', handler);
+
+ return () => {
+ document.body.removeEventListener('click', handler);
+ };
+});
+```
+
+Callback actors are a bit different from other actors in that they do not do the following:
+
+- Do not work with `onDone`
+- Do not produce a snapshot using `.getSnapshot()`
+- Do not emit values when used with `.subscribe()`
+
+You may choose to use `sendBack` to report caught errors to the parent actor. This is especially helpful for handling promise rejections within a callback function, which will not be caught by [`onError`](invoke.mdx#onerror).
+
+Callback functions cannot be `async` functions. But it is possible to execute a Promise within a callback function.
+
+```ts
+import { setup, fromCallback } from 'xstate';
+
+const someCallback = fromCallback(({ sendBack }) => {
+ // [!code highlight:3]
+ somePromise()
+ .then((data) => sendBack({ type: 'done', data }))
+ .catch((error) => sendBack({ type: 'error', data: error }));
+
+ return () => {
+ /* cleanup function */
+ };
+});
+
+const machine = setup({
+ actors: {
+ someCallback,
+ },
+}).createMachine({
+ initial: 'running',
+ states: {
+ running: {
+ invoke: {
+ src: 'someCallback',
+ },
+ // [!code highlight:4]
+ on: {
+ error: {
+ actions: ({ event }) => console.error(event.data),
+ },
+ },
+ },
+ },
+});
+```
+
+Learn more about [callback actors.](callback-actors)
+
+## Actors as promises
+
+You can create a promise from any actor by using the `toPromise(actor)` function. The promise will resolve with the actor snapshot's `.output` when the actor is done (`snapshot.status === 'done'`) or reject with the actor snapshot's `.error` when the actor is errored (`snapshot.status === 'error'`).
+
+```ts
+import { createMachine, createActor, toPromise } from 'xstate';
+
+const machine = createMachine({
+ // ...
+ states: {
+ // ...
+ done: { type: 'final' },
+ },
+ output: {
+ count: 42,
+ },
+});
+
+const actor = createActor(machine);
+actor.start();
+
+// [!code highlight:3]
+// Creates a promise that resolves with the actor's output
+// or rejects with the actor's error
+const output = await toPromise(actor);
+
+console.log(output);
+// => { count: 42 }
+```
+
+If the actor is already done, the promise will resolve with the actor's `snapshot.output` immediately. If the actor is already errored, the promise will reject with the actor's `snapshot.error` immediately.
+
+## Higher-level actor logic
+
+Higher-level actor logic enhances existing actor logic with additional functionality. For example, you can create actor logic that logs or persists actor state:
+
+```ts
+import { fromTransition, type AnyActorLogic } from 'xstate';
+
+const toggleLogic = fromTransition((state, event) => {
+ if (event.type === 'toggle') {
+ return state === 'paused' ? 'playing' : 'paused';
+ }
+
+ return state;
+}, 'paused');
+
+// [!code highlight:13]
+function withLogging(actorLogic: T) {
+ const enhancedLogic = {
+ ...actorLogic,
+ transition: (state, event, actorCtx) => {
+ console.log('State:', state);
+ return actorLogic.transition(state, event, actorCtx);
+ },
+ } satisfies T;
+
+ return enhancedLogic;
+}
+
+const loggingToggleLogic = withLogging(toggleLogic);
+```
+
+## Custom actor logic
+
+Custom actor logic can be defined with an object that implements the `ActorLogic` interface.
+
+For example, here is a custom actor logic object with a `transition` function that operates as a simple reducer:
+
+```ts
+import { createActor, EventObject, ActorLogic, Snapshot } from 'xstate';
+
+const countLogic: ActorLogic<
+ Snapshot & { context: number },
+ EventObject
+> = {
+ transition: (state, event) => {
+ if (event.type === 'INC') {
+ return {
+ ...state,
+ context: state.context + 1,
+ };
+ } else if (event.type === 'DEC') {
+ return {
+ ...state,
+ context: state.context - 1,
+ };
+ }
+ return state;
+ },
+ getInitialSnapshot: () => ({
+ status: 'active',
+ output: undefined,
+ error: undefined,
+ context: 0,
+ }),
+ getPersistedSnapshot: (s) => s,
+};
+
+const actor = createActor(countLogic);
+actor.subscribe((state) => {
+ console.log(state.context);
+});
+actor.start(); // => 0
+actor.send({ type: 'INC' }); // => 1
+actor.send({ type: 'INC' }); // => 2
+```
+
+For further examples, see implementations of `ActorLogic` in the source code, like the `fromTransition` actor logic creator, or the examples in the tests.
+
+## Empty actors
+
+Actor that does nothing and only has a single emitted snapshot: `undefined`
+
+In XState, an empty actor is an actor that does nothing and only has a single emitted snapshot: `undefined`.
+
+This is useful for testing, such as stubbing out an actor that is not yet implemented. It can also be useful in framework integrations, such as `@xstate/react`, where an actor may not be available yet:
+
+```ts
+import { createEmptyActor, AnyActorRef } from 'xstate';
+import { useSelector } from '@xstate/react';
+const emptyActor = createEmptyActor();
+
+function Component(props: { actor?: AnyActorRef }) {
+ const data = useSelector(
+ props.actor ?? emptyActor,
+ (snapshot) => snapshot.context.data,
+ );
+
+ // data is `undefined` if `props.actor` is undefined
+ // Otherwise, it is the data from the actor
+
+ // ...
+}
+```
+
+## Actors and TypeScript
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+You can strongly type the `actors` of your machine in the `types.actors` property of the machine config.
+
+```ts
+const fetcher = fromPromise(
+ async ({ input }: { input: { userId: string } }) => {
+ const user = await fetchUser(input.userId);
+
+ return user;
+ },
+);
+
+const machine = setup({
+ types: {
+ children: {} as {
+ fetch1: 'fetcher';
+ fetch2: 'fetcher';
+ }
+ }
+ // [!code highlight:1]
+ actors: { fetcher }
+}).createMachine({
+ invoke: {
+ // [!code highlight:8]
+ src: 'fetchData', // strongly typed
+ id: 'fetch2', // strongly typed
+ onDone: {
+ actions: ({ event }) => {
+ event.output; // strongly typed as { result: string }
+ },
+ },
+ input: { userId: '42' }, // strongly typed
+ },
+});
+```
+
+## Testing
+
+The general strategy for testing actors is to send events and assert that the actor reaches an expected state, which can be observed either by:
+
+- Subscribing to its emitted snapshots via `actor.subscribe(...)`
+- Or reading the latest snapshot via `actor.getSnapshot()`.
+
+```ts
+test('some actor', async () => {
+ const actor = createActor(
+ fromTransition(
+ (state, event) => {
+ if (event.type === 'inc') {
+ return { count: state.count + 1 };
+ }
+ return state;
+ },
+ { count: 0 },
+ ),
+ );
+
+ // Start the actor
+ actor.start();
+
+ // Send event(s)
+ actor.send({ type: 'inc' });
+ actor.send({ type: 'inc' });
+ actor.send({ type: 'inc' });
+
+ // Assert the expected result
+ expect(actor.getSnapshot().context).toEqual({ count: 3 });
+});
+```
+
+## Actors cheatsheet
+
+### Cheatsheet: create an actor
+
+```ts
+import { createActor } from 'xstate';
+import { someActorLogic } from './someActorLogic.ts';
+
+// Create an actor from the actor logic
+const actor = createActor(someActorLogic);
+
+// Subscribe to an actor’s snapshot values and log them
+actor.subscribe((snapshot) => {
+ console.log(snapshot);
+});
+
+// Start the actor system
+actor.start();
+
+// Now the actor can receive events
+actor.send({ type: 'someEvent' });
+
+// Stops the root actor, actor system, and actors in the system
+actor.stop();
+```
+
+### Cheatsheet: state machine logic
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const toggleMachine = createMachine({
+ id: 'toggle',
+ initial: 'inactive',
+ states: {
+ inactive: {},
+ active: {},
+ },
+});
+
+const toggleActor = createActor(toggleMachine);
+
+toggleActor.subscribe((snapshot) => {
+ // snapshot is the machine’s state
+ console.log('state', snapshot.value);
+ console.log('context', snapshot.context);
+});
+toggleActor.start();
+// Logs 'inactive'
+toggleActor.send({ type: 'toggle' });
+// Logs 'active'
+```
+
+### Cheatsheet: promise logic
+
+```ts
+import { fromPromise, createActor } from 'xstate';
+
+const promiseLogic = fromPromise(() => {
+ return fetch('https://example.com/...').then((data) => data.json());
+});
+
+const promiseActor = createActor(promiseLogic);
+promiseActor.subscribe((snapshot) => {
+ console.log(snapshot);
+});
+promiseActor.start();
+```
+
+### Cheatsheet: transition function logic
+
+```ts
+import { fromTransition, createActor } from 'xstate';
+
+const transitionLogic = fromTransition(
+ (state, event) => {
+ if (event.type === 'increment') {
+ return {
+ ...state,
+ count: state.count + 1,
+ };
+ }
+ return state;
+ },
+ { count: 0 },
+);
+
+const transitionActor = createActor(transitionLogic);
+transitionActor.subscribe((snapshot) => {
+ console.log(snapshot);
+});
+transitionActor.start();
+// => {
+// status: 'active',
+// context: { count: 0 },
+// ...
+// }
+
+transitionActor.send({ type: 'increment' });
+// => {
+// status: 'active',
+// context: { count: 1 },
+// ...
+// }
+```
+
+### Cheatsheet: observable logic
+
+```ts
+import { fromObservable, createActor } from 'xstate';
+import { interval } from 'rxjs';
+
+const secondLogic = fromObservable(() => interval(1000));
+
+const secondActor = createActor(secondLogic);
+
+secondActor.subscribe((snapshot) => {
+ console.log(snapshot.context);
+});
+
+secondActor.start();
+// At every second:
+// Logs 0
+// Logs 1
+// Logs 2
+// ...
+```
+
+### Cheatsheet: event observable logic
+
+```ts
+import { setup, fromEventObservable, createActor } from 'xstate';
+import { fromEvent } from 'rxjs';
+
+const mouseClickLogic = fromEventObservable(
+ () => fromEvent(document.body, 'click') as Subscribable,
+);
+
+const canvasMachine = setup({
+ actors: {
+ mouseClickLogic,
+ },
+}).createMachine({
+ invoke: {
+ // Will send mouse click events to the canvas actor
+ src: 'mouseClickLogic',
+ },
+});
+
+const canvasActor = createActor(canvasMachine);
+canvasActor.start();
+```
+
+### Cheatsheet: callback logic
+
+```ts
+import { fromCallback, createActor } from 'xstate';
+
+const callbackLogic = fromCallback(({ sendBack, receive }) => {
+ let lockStatus = 'unlocked';
+
+ const handler = (event) => {
+ if (lockStatus === 'locked') {
+ return;
+ }
+ sendBack(event);
+ };
+
+ receive((event) => {
+ if (event.type === 'lock') {
+ lockStatus = 'locked';
+ } else if (event.type === 'unlock') {
+ lockStatus = 'unlocked';
+ }
+ });
+
+ document.body.addEventListener('click', handler);
+
+ return () => {
+ document.body.removeEventListener('click', handler);
+ };
+});
+```
diff --git a/fumadocs/content/docs/actors/meta.json b/fumadocs/content/docs/actors/meta.json
new file mode 100644
index 000000000..38f214735
--- /dev/null
+++ b/fumadocs/content/docs/actors/meta.json
@@ -0,0 +1,15 @@
+{
+ "title": "Actors",
+ "pages": [
+ "actors",
+ "state-machine-actors",
+ "promise-actors",
+ "transition-actors",
+ "callback-actors",
+ "observable-actors",
+ "invoke",
+ "spawn",
+ "system",
+ "inspection"
+ ]
+}
diff --git a/fumadocs/content/docs/agents/agents.mdx b/fumadocs/content/docs/agents/agents.mdx
new file mode 100644
index 000000000..83e20eb84
--- /dev/null
+++ b/fumadocs/content/docs/agents/agents.mdx
@@ -0,0 +1,457 @@
+---
+title: 'AI Agents'
+---
+
+
+
+Stately Agent is still under development.
+
+
+
+An AI agent is an autonomous entity that observes an environment, decides what to do (based on its internal policy), and performs actions towards achieving its goals. In terms of the actor model, an agent can be considered an actor that can:
+
+- **Receive events**, such as an instruction on what to do next, which goal to accomplish, or an observation of the environment
+- **Send events**, which would cause actions to be performed on the environment
+- **Store state**, which can be used to remember contextual information about the environment
+- **Spawn other agents**, which can be used to create a hierarchy of agents that can work together and coordinate their actions to achieve a goal
+
+The [Stately Agent (`@statelyai/agent`)](https://github.com/statelyai/agent) package makes it simple to create agents and agent behavior based on the actor model and state machines. These agents can do much more than generate text and execute function calls; Stately Agent is a framework for:
+
+- **Storing message history** between the user and assistant when using the generative text features
+- **Making observations** of an environment, recording the transitions (previous state, event, next state) so it can understand the environment
+- **Receiving feedback** on decisions it makes, so it can retrieve and corrolate feedback so that it can make more informed decisions
+- **Making plans** in its decision-making progress, so that it not only predicts the very next decision to make, but a sequence of decisions that ideally reaches the goal
+- **Short-term and long-term memory** for remembering message history, observations, feedback, and plans that it makes.
+
+## Installation
+
+Install the following dependencies:
+
+- `@statelyai/agent@beta` – Stately.ai Agent, currently in beta
+- `@ai-sdk/openai` – The Vercel AI SDK for OpenAI, which provides access to the OpenAI API
+- `xstate` – Library for managing state machines and statecharts
+- `zod` – Library for type-safe schema validation
+
+
+
+
+```bash
+npm install @statelyai/agent @ai-sdk/openai xstate zod
+```
+
+
+
+
+
+```bash
+pnpm install @statelyai/agent @ai-sdk/openai xstate zod
+```
+
+
+
+
+
+```bash
+yarn add @statelyai/agent @ai-sdk/openai xstate zod
+```
+
+
+
+
+## Quick start
+
+1. Add your provider's API key to your `.env` file.
+
+```bash
+OPENAI_API_KEY="sk-abCDE..."
+```
+
+2. Create an agent.
+
+```ts
+import { openai } from '@ai-sdk/openai';
+import { createAgent } from '@statelyai/agent';
+
+const agent = createAgent({
+ name: 'todo',
+ model: openai('gpt-4-turbo'),
+ events: {},
+});
+```
+
+3. Add event schemas using Zod. These are the events that the agent is allowed to "cause" (i.e. send to the actor)
+
+```ts
+import { openai } from '@ai-sdk/openai';
+import { createAgent } from '@statelyai/agent';
+import { z } from 'zod';
+
+const agent = createAgent({
+ model: openai('gpt-4-turbo'),
+ name: 'todo',
+ // [!code highlight:18]
+ events: {
+ 'todo.add': z.object({
+ todo: z
+ .object({
+ title: z.string().describe('The title of the todo'),
+ content: z.string().describe('The content of the todo'),
+ completed: z
+ .boolean()
+ .describe('The completed value of the todo')
+ .optional(),
+ })
+ .describe('Adds a new todo'),
+ }),
+ 'todo.toggle': z.object({
+ todoId: z.string().describe('The ID of the todo to toggle'),
+ completed: z.boolean().describe('The new completed value').optional(),
+ }),
+ },
+});
+```
+
+3. Interact with a [state machine actor](./state-machine-actors) that accepts those events.
+
+```ts
+import { setup, createActor } from 'xstate';
+// [!code highlight:1]
+import { agent } from './agent';
+
+const todoMachine = setup({
+ types: {
+ // [!code highlight:2]
+ // Add the event types that the agent understands
+ events: agent.types.events,
+ },
+ // ...
+}).createMachine({
+ // ...
+});
+
+const todoActor = createActor(todoMachine);
+
+// [!code highlight:1]
+agent.interact(todoMachine);
+
+todoActor.start();
+```
+
+## Creating an agent
+
+You can create an agent using the `createAgent(settings)` function. There are required settings:
+
+- `name` - The name of the agent, used for logging and agent learning purposes
+- `model` - The [AI SDK language model](https://sdk.vercel.ai/docs/foundations/providers-and-models) to use for generating text and making tool calls
+- `events` - A mapping of event types to [Zod](https://zod.dev/) event schemas that the agent can trigger (i.e. events it can send to some live environment that it is interacting with)
+
+```ts
+import { createAgent } from '@statelyai/agent';
+import { openai } from '@ai-sdk/openai';
+import { z } from 'zod';
+
+const agent = createAgent({
+ name: 'barista',
+ model: openai('gpt-4-turbo'),
+ events: {
+ 'barista.makeDrink': z
+ .object({
+ drink: z.enum(['espresso', 'latte', 'cappuccino']),
+ })
+ .describe('Makes a drink'),
+ // ...
+ },
+});
+```
+
+You can specify additional settings to customize the agent's behavior:
+
+- `description` - A description of the agent, used for logging and agent learning purposes, as well as for agents that call other agents (multi-agent systems)
+- `planner` - An async function that takes the `agent` and planner `input` and resolves with an `AgentPlan` that potentially includes the `steps` and the `nextEvent` to execute to achieve the `input.goal`. This function is used to determine what the agent should do next when making a decision based on the current state (`input.state`) and goal (`input.goal`).
+- `logic` - The agent logic function that is used to determine what an agent does when it receives an agent event, such as `"agent.feedback"`, `"agent.observe"`, `"agent.message"`, or `"agent.plan"`.
+
+## Making decisions
+
+The most important feature of a Stately agent is the ability to make decisions based on the current state and goal. This is done using the `agent.decide(input)` async function, which takes an `input` object that contains the current state, state machine, and goal, and resolves with an `AgentPlan`.
+
+For example, suppose you have the following `baristaMachine` state machine:
+
+```ts
+import { createMachine } from 'xstate';
+
+export const baristaMachine = createMachine({
+ initial: 'idle',
+ states: {
+ idle: {
+ on: {
+ 'barista.makeDrink': 'makingDrink',
+ },
+ },
+ makingDrink: {
+ on: {
+ 'barista.drinkMade': 'idle',
+ },
+ },
+ },
+});
+```
+
+You can then use the `agent.decide(input)` function to determine what the agent should do next:
+
+```ts
+import { createAgent } from '@statelyai/agent';
+import { baristaMachine } from './baristaMachine';
+
+const agent = createAgent({
+ name: 'barista',
+ model: openai('gpt-4-turbo'),
+ events: {
+ 'barista.makeDrink': z
+ .object({
+ drink: z.enum(['espresso', 'latte', 'cappuccino']),
+ })
+ .describe('Makes a drink'),
+ },
+});
+
+async function handleOrder(order, state) {
+ const resolvedState = baristaMachine.resolveState(state);
+ // [!code highlight:5]
+ const plan = await agent.decide({
+ state: resolvedState,
+ machine: baristaMachine,
+ goal: `A customer made this order: ${order}`,
+ });
+
+ return plan;
+}
+
+handleOrder('I want a latte please', { value: 'idle' });
+// Resolves with an `AgentPlan` that includes:
+// {
+// // ...
+// nextEvent: { type: 'barista.makeDrink', drink: 'latte' },
+// }
+```
+
+## Agent memory
+
+Stately agents can have two types of memory: **short-term (local) memory** and **long-term memory**.
+
+- **Short-term (local) memory** is memory that can be synchronously retrieved, but might not be persisted.
+- **Long-term memory** is memory that is asynchronously retrieved from persistent storage, such as a database.
+
+Agents remember four kinds of things in their memory:
+
+- **Messages** between the user and the assistant
+- **Observations** of state transitions (previous state, event, current state) that occur in the environment that the agent is observing
+- **Feedback**
+- **Plans**
+
+## Messages
+
+### `agent.getMessages()`
+
+Returns chat messages that occur between the user and the assistant from short-term memory.
+
+### `agent.addMessage(message)`
+
+If you want to manually add a message between the assistant and user to agent memory, you can call `agent.addMessage(message)` to do so. This is automatically called when calling `agent.generateText(…)`, `agent.streamText(…)`, or the `fromText(…)` and `fromTextStream(…)` actor logic creators. You should avoid calling this manually.
+
+## Observations
+
+### `agent.getObservations()`
+
+Returns observations that the agent observes from short-term memory.
+
+### `agent.addObservation(observation)`
+
+You can add an observation (`{ prevState, event, state, … }`) to an agent's memory by calling `agent.addObservation(observation)`. This function returns an `AgentObservation` object that includes the provided observation details as well as an observation `id` so that the observation can be referenced in feedback, if applicable.
+
+```ts
+const observation = agent.addObservation({
+ prevState: { value: 'idle', context: {} },
+ event: { type: 'grindBeans' },
+ state: { value: 'grindingBeans', context: {} },
+});
+```
+
+## Feedback
+
+### `agent.getFeedback()`
+
+Returns feedback that is given to the agent from short-term memory.
+
+### `agent.addFeedback(feedback)`
+
+```ts
+const observation = agent.addObservation({
+ // ...
+});
+
+const feedback = agent.addFeedback({
+ observationId: observation.id,
+ goal: 'Make an iced coffee',
+ attributes: {
+ feedback: 'Water should not be boiled for an iced coffee',
+ score: -10,
+ },
+});
+```
+
+## Plans
+
+### `agent.getPlans()`
+
+Returns plans that the agent has made from short-term memory.
+
+### `agent.addPlan(plan)`
+
+TODO
+
+## Interacting with state machines
+
+An agent can interact with existing state machine actors to determine what to do next. While the state machine actor is running, the agent will do the following cycle:
+
+1. The agent **observes state changes**
+
+- The observation is remembered in the agent's state
+
+2. The agent **determines** if it needs to make a decision based on the current state
+3. If it does, the agent **makes a decision** in the form of an `AgentPlan`.
+4. If an `AgentPlan` is formed, the agent triggers the next event (`plan.nextEvent`) on the state machine actor.
+
+- The plan is remembered in the agent's state.
+
+4. The agent goes back to step 1, and the cycle continues.
+
+```ts
+import { createAgent } from '@statelyai/agent';
+import { createActor } from 'xstate';
+import { jokeMachine } from './jokeMachine';
+
+const agent = createAgent({
+ name: 'joke-teller',
+ model: openai('gpt-4'),
+ events: {
+ 'agent.tellJoke': z.object({
+ joke: z.string().describe('The joke text'),
+ }),
+ 'agent.rateJoke': z.object({
+ rating: z.number().min(1).max(10),
+ explanation: z.string(),
+ }),
+ // ...
+ },
+});
+
+const jokeActor = createActor(jokeMachine).start();
+
+agent.interact(jokeActor, (observed) => {
+ if (observed.state.matches('tellingJoke')) {
+ return { goal: `Tell a joke about ${observed.state.context.topic}` };
+ }
+ if (observed.state.matches('ratingJoke')) {
+ return { goal: `Rate this joke: ${observed.state.context.joke}` };
+ }
+});
+```
+
+## State machine agents
+
+You can invoke Stately agents as part of a state machine, ensuring that it will follow the state machine's transitions as specified and trigger the appropriate events. This is done by using any of the following [actor logic creators](./actors):
+
+### `fromDecision(agent)`
+
+Returns [promise actor logic](TODO) that resolves with the **agent plan** that should accomplish the goal (`input.goal`), if it is able to create one.
+
+When invoked/spawned, this actor will also add the user and assistant messages to agent memory, as well as the plan that it created.
+
+### `fromText(agent)`
+
+Returns [promise actor logic](TODO) that resolves with the generated text result from the [Vercel AI SDK](https://sdk.vercel.ai/docs/reference/ai-sdk-core/generate-text#generatetext).
+
+When invoked/spawned, this actor will also add the user and assistant messages to agent memory.
+
+```ts
+import { createAgent, fromText } from '@statelyai/agent';
+import { setup } from 'xstate';
+
+const agent = createAgent(/* ... */);
+
+const machine = setup({
+ actors: {
+ assistant: fromText(agent),
+ },
+}).createMachine({
+ initial: 'greeting',
+ context: (x) => ({
+ time: x.input.time,
+ }),
+ states: {
+ greeting: {
+ invoke: {
+ src: 'assistant',
+ input: ({ context }) => ({
+ context: {
+ time: context.time,
+ },
+ goal: 'Produce a greeting depending on the time of day.',
+ }),
+ onDone: {
+ target: 'greeted',
+ actions: ({ event }) => {
+ console.log(event.output.text);
+ },
+ },
+ },
+ },
+ greeted: {
+ type: 'final',
+ },
+ },
+});
+
+const actor = createActor(machine, {
+ input: { time: Date.now() },
+});
+
+actor.start();
+```
+
+### `fromTextStream(agent)`
+
+Returns [observable actor logic](TODO) that streams the text from the [Vercel AI SDK](https://sdk.vercel.ai/docs/reference/ai-sdk-core/stream-text).
+
+When invoked/spawned, this actor will also add the user and assistant messages to agent memory.
+
+TODO: example
+
+## Observability
+
+- Can observe observations, plans, messages, and feedback via `agent.on('message', (message) => {})`
+- Can manually add feedback observations via `agent.addFeedback(…)`
+
+## Generating text
+
+You can use the `agent.generateText(input)` method to generate text from an input. This extends the `generateText(…)` function from the [Vercel AI SDK](https://sdk.vercel.ai/docs/reference/ai-sdk-core/generate-text#generatetext) by:
+
+- Adding the user and assistant messages to agent memory
+- Providing the ability to retrieve previous observations, feedback, plans and messages from agent memory
+
+## Streaming text
+
+You can use the `agent.streamText(input)` method to stream text from an input. This extends the `streamText(…)` function from the [Vercel AI SDK](https://sdk.vercel.ai/docs/reference/ai-sdk-core/generate-text#generatetext) by:
+
+- Adding the user and assistant messages to agent memory
+- Providing the ability to retrieve previous observations, feedback, plans and messages from agent memory
+
+## Agent logic
+
+Agent logic is [actor logic](TODO) that has the specific purpose of performing LLM tasks for the agent. Agent logic goes beyond just being a wrapper and provides the ability to use the agent's state machine to intelligently determine which action to take next.
+
+Agent logic is most powerful when used with a state-machine-powered agent, but you can also create standalone actors from agent logic, which is useful for testing and simple tasks.
+
+## Examples
+
+See the current examples in the [examples directory](https://github.com/statelyai/agent/tree/main/examples).
diff --git a/fumadocs/content/docs/agents/meta.json b/fumadocs/content/docs/agents/meta.json
new file mode 100644
index 000000000..fcfbe3d79
--- /dev/null
+++ b/fumadocs/content/docs/agents/meta.json
@@ -0,0 +1,6 @@
+{
+ "title": "Agents",
+ "pages": [
+ "agents"
+ ]
+}
diff --git a/fumadocs/content/docs/annotations.mdx b/fumadocs/content/docs/annotations.mdx
new file mode 100644
index 000000000..6649678c4
--- /dev/null
+++ b/fumadocs/content/docs/annotations.mdx
@@ -0,0 +1,34 @@
+---
+title: Notes
+---
+
+import { PlusSquare } from 'lucide-react';
+
+You can use notes to annotate your machine, positioned anywhere inside your machine. Notes are useful for information or comments you want to add to your machine that are only visible inside Stately Studio and not included when you export as code.
+
+
+
+Unlike [**descriptions**](descriptions), notes don’t need to be connected to a state or transition and can be added or positioned anywhere inside your machine.
+
+
+
+## Add notes to your machine
+
+You can add notes anywhere on your machine from **Design** and **Simulate** mode, but you can only edit them in **Design** mode.
+
+Notes are unrelated to a state or transition. Still, their layout position is connected to the closest root or parent state when you create them, which helps give your notes enough space in the auto layout.
+
+- Use the Enter key to edit the contents of a note.
+- Use the Backspace key to delete the selected note.
diff --git a/fumadocs/content/docs/assets.mdx b/fumadocs/content/docs/assets.mdx
new file mode 100644
index 000000000..9ee070ab9
--- /dev/null
+++ b/fumadocs/content/docs/assets.mdx
@@ -0,0 +1,50 @@
+---
+title: Assets in Stately’s editor
+description: 'Learn how to use assets on your states in Stately’s editor.'
+---
+
+import { Plus, Paperclip, Star, Info } from 'lucide-react';
+
+# Assets
+
+You can drag and drop assets on any state or upload them using the **Asset** on any selected state.
+
+
+
+Assets are a premium feature of Stately Studio. You can try Stately Studio’s premium plans with a free trial. [Check out the features on our Pro plan](studio-pro-plan), [Team plan](studio-team-plan), [Enterprise plan](studio-enterprise-plan) or [upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+Assets are valuable when you want to include use cases, features, workflows, and more to your state machines. One of our most frequent requests is from teams who want to tie their logic to real-life user interfaces, and assets provide a way to connect user interface design to logic in a way your whole team can understand.
+
+
+
+You can now [embed Figma frames](figma) that stay in sync with your Figma files.
+
+
+
+ star icon, is the asset shown on the canvas.
+
+Further assets are accessible from the state **Details** panel, where you can also drag to reorder the assets and choose their [displayed size](#asset-sizes).
+
+## Asset sizes
+
+Once your asset is uploaded to your state, you can choose the display size from the **Size** menu that shows on hover over the asset, or from the dropdown menu in the state **Details** panel:
+
+- small **sm**
+- medium **md**
+- large **lg**
+- extra large **xl**
+
+
+
+You can also add images from any URL using markdown in [state and transition descriptions](descriptions).
+
+
diff --git a/fumadocs/content/docs/assets/apple-touch-icon.png b/fumadocs/content/docs/assets/apple-touch-icon.png
new file mode 100644
index 000000000..6c92e1690
Binary files /dev/null and b/fumadocs/content/docs/assets/apple-touch-icon.png differ
diff --git a/fumadocs/content/docs/assets/asleep-awake.svg b/fumadocs/content/docs/assets/asleep-awake.svg
new file mode 100644
index 000000000..7f076919c
--- /dev/null
+++ b/fumadocs/content/docs/assets/asleep-awake.svg
@@ -0,0 +1 @@
+awake asleep logged in logged out log in log out
+
diff --git a/fumadocs/content/docs/assets/blog/2023-12-07-tidefi-and-stately-case-study/logo-with-name.svg b/fumadocs/content/docs/assets/blog/2023-12-07-tidefi-and-stately-case-study/logo-with-name.svg
new file mode 100644
index 000000000..4c0fcd03c
--- /dev/null
+++ b/fumadocs/content/docs/assets/blog/2023-12-07-tidefi-and-stately-case-study/logo-with-name.svg
@@ -0,0 +1,5 @@
+
+
diff --git a/fumadocs/content/docs/assets/blog/2023-5-30-what-is-the-actor-model-and-when-should-i-use-it.png b/fumadocs/content/docs/assets/blog/2023-5-30-what-is-the-actor-model-and-when-should-i-use-it.png
new file mode 100644
index 000000000..cd0a0c79b
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2023-5-30-what-is-the-actor-model-and-when-should-i-use-it.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-02-office-hours.png b/fumadocs/content/docs/assets/blog/2024-01-02-office-hours.png
new file mode 100644
index 000000000..012c52ecb
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-02-office-hours.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-03-learn-stately.png b/fumadocs/content/docs/assets/blog/2024-01-03-learn-stately.png
new file mode 100644
index 000000000..4c9d4c737
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-03-learn-stately.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-04-office-hours.png b/fumadocs/content/docs/assets/blog/2024-01-04-office-hours.png
new file mode 100644
index 000000000..cf4bbe482
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-04-office-hours.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023.png b/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023.png
new file mode 100644
index 000000000..b7ca46ae4
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023/generate-react-app-dm.png b/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023/generate-react-app-dm.png
new file mode 100644
index 000000000..dc5f47f04
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023/generate-react-app-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023/generate-react-app.png b/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023/generate-react-app.png
new file mode 100644
index 000000000..11c352344
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-08-a-look-back-at-2023/generate-react-app.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync.png
new file mode 100644
index 000000000..e53b9c963
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/connect-github-button-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/connect-github-button-dm.png
new file mode 100644
index 000000000..37631e3df
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/connect-github-button-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/connect-github-button.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/connect-github-button.png
new file mode 100644
index 000000000..da2f1ec6f
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/connect-github-button.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-auto-sync-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-auto-sync-dm.png
new file mode 100644
index 000000000..51fcd7af4
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-auto-sync-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-auto-sync.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-auto-sync.png
new file mode 100644
index 000000000..cec509b87
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-auto-sync.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-manual-sync-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-manual-sync-dm.png
new file mode 100644
index 000000000..3d0e9c410
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-manual-sync-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-manual-sync.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-manual-sync.png
new file mode 100644
index 000000000..2066b509a
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-manual-sync.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-pull-request-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-pull-request-dm.png
new file mode 100644
index 000000000..7400ad8bf
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-pull-request-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-pull-request.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-pull-request.png
new file mode 100644
index 000000000..682f266be
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-pull-request.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-branch-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-branch-dm.png
new file mode 100644
index 000000000..2066c8e61
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-branch-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-branch.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-branch.png
new file mode 100644
index 000000000..c014f6dc8
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-branch.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-files-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-files-dm.png
new file mode 100644
index 000000000..41c00cf47
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-files-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-files.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-files.png
new file mode 100644
index 000000000..456206e5a
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-files.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-repo-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-repo-dm.png
new file mode 100644
index 000000000..72cdf1d33
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-repo-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-repo.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-repo.png
new file mode 100644
index 000000000..75819c122
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-select-repo.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-settings-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-settings-dm.png
new file mode 100644
index 000000000..172d373d5
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-settings-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-settings.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-settings.png
new file mode 100644
index 000000000..1f8bc51da
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/github-settings.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/premium-feature-version-history-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/premium-feature-version-history-dm.png
new file mode 100644
index 000000000..546895a84
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/premium-feature-version-history-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/premium-feature-version-history.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/premium-feature-version-history.png
new file mode 100644
index 000000000..caa6300df
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-bidirectional-github-sync/premium-feature-version-history.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources.png
new file mode 100644
index 000000000..880bad818
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/action-params-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/action-params-dm.png
new file mode 100644
index 000000000..bebcbf7e2
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/action-params-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/action-params.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/action-params.png
new file mode 100644
index 000000000..29d4e934b
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/action-params.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/sources-dm.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/sources-dm.png
new file mode 100644
index 000000000..fee3f7076
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/sources-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/sources.png b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/sources.png
new file mode 100644
index 000000000..0ed7aa965
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-09-introducing-sources/sources.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-11-building-backend-workflows.png b/fumadocs/content/docs/assets/blog/2024-01-11-building-backend-workflows.png
new file mode 100644
index 000000000..79744e156
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-11-building-backend-workflows.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-11-changelog.png b/fumadocs/content/docs/assets/blog/2024-01-11-changelog.png
new file mode 100644
index 000000000..b58a90d31
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-11-changelog.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-12-xstate-exploring-actors.png b/fumadocs/content/docs/assets/blog/2024-01-12-xstate-exploring-actors.png
new file mode 100644
index 000000000..695598790
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-12-xstate-exploring-actors.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector.png b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector.png
new file mode 100644
index 000000000..8823614ca
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/inspector-dm.png b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/inspector-dm.png
new file mode 100644
index 000000000..91e96aa53
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/inspector-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/inspector.png b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/inspector.png
new file mode 100644
index 000000000..fd92ad5c4
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/inspector.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/machine-and-sequence-diagram-dm.png b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/machine-and-sequence-diagram-dm.png
new file mode 100644
index 000000000..9a7288dfb
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/machine-and-sequence-diagram-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/machine-and-sequence-diagram.png b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/machine-and-sequence-diagram.png
new file mode 100644
index 000000000..fec24d73f
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-15-introducing-stately-inspector/machine-and-sequence-diagram.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-19-changelog.png b/fumadocs/content/docs/assets/blog/2024-01-19-changelog.png
new file mode 100644
index 000000000..12a447d7b
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-19-changelog.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-19-office-hours.png b/fumadocs/content/docs/assets/blog/2024-01-19-office-hours.png
new file mode 100644
index 000000000..50692b69a
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-19-office-hours.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name.png b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name.png
new file mode 100644
index 000000000..2247bd29f
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/cd-player-studio-dm.png b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/cd-player-studio-dm.png
new file mode 100644
index 000000000..0ce2409ae
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/cd-player-studio-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/cd-player-studio.png b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/cd-player-studio.png
new file mode 100644
index 000000000..7d756249a
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/cd-player-studio.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/horrocks-cd.png b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/horrocks-cd.png
new file mode 100644
index 000000000..e102543d5
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/horrocks-cd.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/orthogonality.png b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/orthogonality.png
new file mode 100644
index 000000000..5e7a838f2
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/orthogonality.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/watch-batteries.png b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/watch-batteries.png
new file mode 100644
index 000000000..4a26493ad
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-23-state-machines-whats-in-a-name/watch-batteries.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-24-building-backend-workflows-credit-checking.png b/fumadocs/content/docs/assets/blog/2024-01-24-building-backend-workflows-credit-checking.png
new file mode 100644
index 000000000..03a43e741
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-24-building-backend-workflows-credit-checking.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma.png b/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma.png
new file mode 100644
index 000000000..cf0966aab
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma/figma-dark.png b/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma/figma-dark.png
new file mode 100644
index 000000000..d5d6e59e9
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma/figma-dark.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma/figma-light.png b/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma/figma-light.png
new file mode 100644
index 000000000..572d04993
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-24-embed-figma/figma-light.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-01-30-changelog.png b/fumadocs/content/docs/assets/blog/2024-01-30-changelog.png
new file mode 100644
index 000000000..174bdc872
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-01-30-changelog.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-02-migrating-machines-to-xstate-v5.png b/fumadocs/content/docs/assets/blog/2024-02-02-migrating-machines-to-xstate-v5.png
new file mode 100644
index 000000000..b95b851e0
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-02-migrating-machines-to-xstate-v5.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-02-migrating-machines-to-xstate-v5/misleading-typescript-error.png b/fumadocs/content/docs/assets/blog/2024-02-02-migrating-machines-to-xstate-v5/misleading-typescript-error.png
new file mode 100644
index 000000000..26a11e57d
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-02-migrating-machines-to-xstate-v5/misleading-typescript-error.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-07-single-file-pr.png b/fumadocs/content/docs/assets/blog/2024-02-07-single-file-pr.png
new file mode 100644
index 000000000..f17831cb6
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-07-single-file-pr.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-07-single-file-prs/diff-dm.png b/fumadocs/content/docs/assets/blog/2024-02-07-single-file-prs/diff-dm.png
new file mode 100644
index 000000000..d5009e4f6
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-07-single-file-prs/diff-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-07-single-file-prs/diff.png b/fumadocs/content/docs/assets/blog/2024-02-07-single-file-prs/diff.png
new file mode 100644
index 000000000..3e4e7f946
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-07-single-file-prs/diff.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-12-xstate-react-global-state.png b/fumadocs/content/docs/assets/blog/2024-02-12-xstate-react-global-state.png
new file mode 100644
index 000000000..e9afbf11f
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-12-xstate-react-global-state.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-16-changelog.png b/fumadocs/content/docs/assets/blog/2024-02-16-changelog.png
new file mode 100644
index 000000000..c3777dd56
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-16-changelog.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-16-changelog/sort-dm.png b/fumadocs/content/docs/assets/blog/2024-02-16-changelog/sort-dm.png
new file mode 100644
index 000000000..ba96f6892
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-16-changelog/sort-dm.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-16-changelog/sort.png b/fumadocs/content/docs/assets/blog/2024-02-16-changelog/sort.png
new file mode 100644
index 000000000..ecb79df35
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-16-changelog/sort.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-02-16-office-hours.png b/fumadocs/content/docs/assets/blog/2024-02-16-office-hours.png
new file mode 100644
index 000000000..89fc5cfa7
Binary files /dev/null and b/fumadocs/content/docs/assets/blog/2024-02-16-office-hours.png differ
diff --git a/fumadocs/content/docs/assets/blog/2024-11-12-webinargeek-and-stately-case-study/Black-Logo-webinargeek.svg b/fumadocs/content/docs/assets/blog/2024-11-12-webinargeek-and-stately-case-study/Black-Logo-webinargeek.svg
new file mode 100644
index 000000000..29cc2ee1a
--- /dev/null
+++ b/fumadocs/content/docs/assets/blog/2024-11-12-webinargeek-and-stately-case-study/Black-Logo-webinargeek.svg
@@ -0,0 +1 @@
+logged out log in auto logged out idle active after 1 minute activity logged in log out after 3 minutes logged out log in auto logged out entry / warn user about auto logout idle active after 1 minute activity logged in log out after 3 minutes waiting walk complete on a walk leave home arrive home
+ Stately
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/initial-state-icon.png b/fumadocs/content/docs/assets/initial-state-icon.png
new file mode 100644
index 000000000..184828e24
Binary files /dev/null and b/fumadocs/content/docs/assets/initial-state-icon.png differ
diff --git a/fumadocs/content/docs/assets/initial-state.png b/fumadocs/content/docs/assets/initial-state.png
new file mode 100644
index 000000000..20aa6f0cf
Binary files /dev/null and b/fumadocs/content/docs/assets/initial-state.png differ
diff --git a/fumadocs/content/docs/assets/initial-state.svg b/fumadocs/content/docs/assets/initial-state.svg
new file mode 100644
index 000000000..19e54bb17
--- /dev/null
+++ b/fumadocs/content/docs/assets/initial-state.svg
@@ -0,0 +1 @@
+waiting
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/amy-100.png b/fumadocs/content/docs/assets/landing-page/assets/amy-100.png
new file mode 100644
index 000000000..b77736d30
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/amy-100.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/amy.png b/fumadocs/content/docs/assets/landing-page/assets/amy.png
new file mode 100644
index 000000000..ae024c5a5
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/amy.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/arrow-right.svg b/fumadocs/content/docs/assets/landing-page/assets/arrow-right.svg
new file mode 100644
index 000000000..c54ba73e5
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/arrow-right.svg
@@ -0,0 +1,7 @@
+
+
+ arrow-right
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing-page/assets/avatar-TEMP.jpg b/fumadocs/content/docs/assets/landing-page/assets/avatar-TEMP.jpg
new file mode 100644
index 000000000..fbfebde1a
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/avatar-TEMP.jpg differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/aws.svg b/fumadocs/content/docs/assets/landing-page/assets/aws.svg
new file mode 100644
index 000000000..1022dca9c
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/aws.svg
@@ -0,0 +1,7 @@
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/blizzard.svg b/fumadocs/content/docs/assets/landing-page/assets/blizzard.svg
new file mode 100644
index 000000000..43b66dc46
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/blizzard.svg
@@ -0,0 +1,7 @@
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans-1010.png b/fumadocs/content/docs/assets/landing-page/assets/booleans-1010.png
new file mode 100644
index 000000000..41e2522a7
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans-1010.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans-1280.png b/fumadocs/content/docs/assets/landing-page/assets/booleans-1280.png
new file mode 100644
index 000000000..5ff3e3725
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans-1280.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans-1480.png b/fumadocs/content/docs/assets/landing-page/assets/booleans-1480.png
new file mode 100644
index 000000000..acca64203
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans-1480.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans-1660.png b/fumadocs/content/docs/assets/landing-page/assets/booleans-1660.png
new file mode 100644
index 000000000..f6f3476c0
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans-1660.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans-256.png b/fumadocs/content/docs/assets/landing-page/assets/booleans-256.png
new file mode 100644
index 000000000..bd8200250
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans-256.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans-640.png b/fumadocs/content/docs/assets/landing-page/assets/booleans-640.png
new file mode 100644
index 000000000..f219693f3
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans-640.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans-TEMP.png b/fumadocs/content/docs/assets/landing-page/assets/booleans-TEMP.png
new file mode 100644
index 000000000..2efdbfbe4
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans-TEMP.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans.png b/fumadocs/content/docs/assets/landing-page/assets/booleans.png
new file mode 100644
index 000000000..48fbefa06
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/booleans.webp b/fumadocs/content/docs/assets/landing-page/assets/booleans.webp
new file mode 100644
index 000000000..88147af0d
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/booleans.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/centered.svg b/fumadocs/content/docs/assets/landing-page/assets/centered.svg
new file mode 100644
index 000000000..a07420adf
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/centered.svg
@@ -0,0 +1,21 @@
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing-page/assets/cigna.svg b/fumadocs/content/docs/assets/landing-page/assets/cigna.svg
new file mode 100644
index 000000000..7a724262a
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/cigna.svg
@@ -0,0 +1,6 @@
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/cisco.svg b/fumadocs/content/docs/assets/landing-page/assets/cisco.svg
new file mode 100644
index 000000000..c119fd4ef
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/cisco.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/code-editor.png b/fumadocs/content/docs/assets/landing-page/assets/code-editor.png
new file mode 100644
index 000000000..b84f0a451
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/code-editor.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/code-editor.webp b/fumadocs/content/docs/assets/landing-page/assets/code-editor.webp
new file mode 100644
index 000000000..5890dcca6
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/code-editor.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1032.png b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1032.png
new file mode 100644
index 000000000..39ccda6cc
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1032.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1232.png b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1232.png
new file mode 100644
index 000000000..d2c6f6978
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1232.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1370.png b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1370.png
new file mode 100644
index 000000000..172b6f2ee
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-1370.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-616.png b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-616.png
new file mode 100644
index 000000000..922d0359a
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-616.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-v1.png b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-v1.png
new file mode 100644
index 000000000..4493b32c3
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow-v1.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow.png b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow.png
new file mode 100644
index 000000000..5010228e1
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow.webp b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow.webp
new file mode 100644
index 000000000..91b7188f2
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/collaborate-narrow.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/discord.svg b/fumadocs/content/docs/assets/landing-page/assets/discord.svg
new file mode 100644
index 000000000..b15537e7f
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/discord.svg
@@ -0,0 +1,7 @@
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/editor-background-grid.svg b/fumadocs/content/docs/assets/landing-page/assets/editor-background-grid.svg
new file mode 100644
index 000000000..120873e25
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/editor-background-grid.svg
@@ -0,0 +1,13 @@
+
+
+ editor-background-grid
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing-page/assets/epic-games.svg b/fumadocs/content/docs/assets/landing-page/assets/epic-games.svg
new file mode 100644
index 000000000..d04232ea4
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/epic-games.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/gatsby.svg b/fumadocs/content/docs/assets/landing-page/assets/gatsby.svg
new file mode 100644
index 000000000..8c210beab
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/gatsby.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/github.svg b/fumadocs/content/docs/assets/landing-page/assets/github.svg
new file mode 100644
index 000000000..2bcb597b9
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/github.svg
@@ -0,0 +1,7 @@
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/grid-cell.svg b/fumadocs/content/docs/assets/landing-page/assets/grid-cell.svg
new file mode 100644
index 000000000..55387230b
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/grid-cell.svg
@@ -0,0 +1,10 @@
+
+
+ grid-cell
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing-page/assets/hammer.svg b/fumadocs/content/docs/assets/landing-page/assets/hammer.svg
new file mode 100644
index 000000000..b33842a07
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/hammer.svg
@@ -0,0 +1 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/james-100.png b/fumadocs/content/docs/assets/landing-page/assets/james-100.png
new file mode 100644
index 000000000..5c992499f
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/james-100.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/james.png b/fumadocs/content/docs/assets/landing-page/assets/james.png
new file mode 100644
index 000000000..1267bf057
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/james.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/jpmorgan.svg b/fumadocs/content/docs/assets/landing-page/assets/jpmorgan.svg
new file mode 100644
index 000000000..970199f1f
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/jpmorgan.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/js.svg b/fumadocs/content/docs/assets/landing-page/assets/js.svg
new file mode 100644
index 000000000..76444a1bd
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/js.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/kong.svg b/fumadocs/content/docs/assets/landing-page/assets/kong.svg
new file mode 100644
index 000000000..9304b59bb
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/kong.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/lego.svg b/fumadocs/content/docs/assets/landing-page/assets/lego.svg
new file mode 100644
index 000000000..ac5ebfe84
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/lego.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/lyft.svg b/fumadocs/content/docs/assets/landing-page/assets/lyft.svg
new file mode 100644
index 000000000..76f88e759
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/lyft.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/maya-100.png b/fumadocs/content/docs/assets/landing-page/assets/maya-100.png
new file mode 100644
index 000000000..541fa1d85
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/maya-100.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/maya.png b/fumadocs/content/docs/assets/landing-page/assets/maya.png
new file mode 100644
index 000000000..13e1e69c1
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/maya.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/maya.webp b/fumadocs/content/docs/assets/landing-page/assets/maya.webp
new file mode 100644
index 000000000..90eb63bea
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/maya.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/microsoft.svg b/fumadocs/content/docs/assets/landing-page/assets/microsoft.svg
new file mode 100644
index 000000000..2ea0075fc
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/microsoft.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/morgan-stanley.svg b/fumadocs/content/docs/assets/landing-page/assets/morgan-stanley.svg
new file mode 100644
index 000000000..1b2c0a605
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/morgan-stanley.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/natalie-100.png b/fumadocs/content/docs/assets/landing-page/assets/natalie-100.png
new file mode 100644
index 000000000..7bc1f34f1
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/natalie-100.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/natalie.png b/fumadocs/content/docs/assets/landing-page/assets/natalie.png
new file mode 100644
index 000000000..660027c75
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/natalie.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/natalie.webp b/fumadocs/content/docs/assets/landing-page/assets/natalie.webp
new file mode 100644
index 000000000..b54fef04f
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/natalie.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/netflix.svg b/fumadocs/content/docs/assets/landing-page/assets/netflix.svg
new file mode 100644
index 000000000..e405d41d0
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/netflix.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/packages.svg b/fumadocs/content/docs/assets/landing-page/assets/packages.svg
new file mode 100644
index 000000000..7aaf62a66
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/packages.svg
@@ -0,0 +1,8 @@
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/patrick-100.png b/fumadocs/content/docs/assets/landing-page/assets/patrick-100.png
new file mode 100644
index 000000000..c97a2656d
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/patrick-100.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/patrick.png b/fumadocs/content/docs/assets/landing-page/assets/patrick.png
new file mode 100644
index 000000000..3b79f1683
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/patrick.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/patrick.webp b/fumadocs/content/docs/assets/landing-page/assets/patrick.webp
new file mode 100644
index 000000000..12ab3127b
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/patrick.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/presley-100.png b/fumadocs/content/docs/assets/landing-page/assets/presley-100.png
new file mode 100644
index 000000000..a0d92d81f
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/presley-100.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/presley.png b/fumadocs/content/docs/assets/landing-page/assets/presley.png
new file mode 100644
index 000000000..0de7798c4
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/presley.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/presley.webp b/fumadocs/content/docs/assets/landing-page/assets/presley.webp
new file mode 100644
index 000000000..9987906bb
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/presley.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/registry-1110.png b/fumadocs/content/docs/assets/landing-page/assets/registry-1110.png
new file mode 100644
index 000000000..f0d970b90
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/registry-1110.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/registry-1348.png b/fumadocs/content/docs/assets/landing-page/assets/registry-1348.png
new file mode 100644
index 000000000..6a327de17
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/registry-1348.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/registry-1600.png b/fumadocs/content/docs/assets/landing-page/assets/registry-1600.png
new file mode 100644
index 000000000..1dcdc2e31
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/registry-1600.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/registry-265.png b/fumadocs/content/docs/assets/landing-page/assets/registry-265.png
new file mode 100644
index 000000000..05441adb4
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/registry-265.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/registry-800.png b/fumadocs/content/docs/assets/landing-page/assets/registry-800.png
new file mode 100644
index 000000000..f0be68012
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/registry-800.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/registry.png b/fumadocs/content/docs/assets/landing-page/assets/registry.png
new file mode 100644
index 000000000..6445d2d7c
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/registry.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/santi-100.png b/fumadocs/content/docs/assets/landing-page/assets/santi-100.png
new file mode 100644
index 000000000..5c8306203
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/santi-100.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/santi.png b/fumadocs/content/docs/assets/landing-page/assets/santi.png
new file mode 100644
index 000000000..10d630324
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/santi.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/share-image-pricing.png b/fumadocs/content/docs/assets/landing-page/assets/share-image-pricing.png
new file mode 100644
index 000000000..ada79354c
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/share-image-pricing.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/side-arrow.svg b/fumadocs/content/docs/assets/landing-page/assets/side-arrow.svg
new file mode 100644
index 000000000..a86a4f6ef
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/side-arrow.svg
@@ -0,0 +1,4 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/stack.svg b/fumadocs/content/docs/assets/landing-page/assets/stack.svg
new file mode 100644
index 000000000..1965cc2a2
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/stack.svg
@@ -0,0 +1 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart-1010.png b/fumadocs/content/docs/assets/landing-page/assets/statechart-1010.png
new file mode 100644
index 000000000..64baed8e0
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart-1010.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart-1280.png b/fumadocs/content/docs/assets/landing-page/assets/statechart-1280.png
new file mode 100644
index 000000000..7c7dea73d
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart-1280.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart-1480.png b/fumadocs/content/docs/assets/landing-page/assets/statechart-1480.png
new file mode 100644
index 000000000..fc872da82
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart-1480.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart-1660.png b/fumadocs/content/docs/assets/landing-page/assets/statechart-1660.png
new file mode 100644
index 000000000..38255841d
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart-1660.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart-256.png b/fumadocs/content/docs/assets/landing-page/assets/statechart-256.png
new file mode 100644
index 000000000..72d6750e3
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart-256.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart-640.png b/fumadocs/content/docs/assets/landing-page/assets/statechart-640.png
new file mode 100644
index 000000000..ed8dfe67a
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart-640.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart-v1.png b/fumadocs/content/docs/assets/landing-page/assets/statechart-v1.png
new file mode 100644
index 000000000..2e597eb73
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart-v1.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/statechart.png b/fumadocs/content/docs/assets/landing-page/assets/statechart.png
new file mode 100644
index 000000000..1a6c14992
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/statechart.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/stately-landing-page.png b/fumadocs/content/docs/assets/landing-page/assets/stately-landing-page.png
new file mode 100644
index 000000000..b14129657
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/stately-landing-page.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/t-mobile.svg b/fumadocs/content/docs/assets/landing-page/assets/t-mobile.svg
new file mode 100644
index 000000000..1da200b72
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/t-mobile.svg
@@ -0,0 +1,6 @@
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/ted.svg b/fumadocs/content/docs/assets/landing-page/assets/ted.svg
new file mode 100644
index 000000000..01ef4118c
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/ted.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/assets/ttcommons.woff2 b/fumadocs/content/docs/assets/landing-page/assets/ttcommons.woff2
new file mode 100644
index 000000000..996ea718f
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/ttcommons.woff2 differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/visual-editor-poster-image.png b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-poster-image.png
new file mode 100644
index 000000000..ae116ae97
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-poster-image.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v1-poster-image.png b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v1-poster-image.png
new file mode 100644
index 000000000..ac7b6ea21
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v1-poster-image.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v1.mp4 b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v1.mp4
new file mode 100644
index 000000000..0a0a8bc78
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v1.mp4 differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v2.mp4 b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v2.mp4
new file mode 100644
index 000000000..a9df5916f
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/visual-editor-v2.mp4 differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/visual-editor.gif b/fumadocs/content/docs/assets/landing-page/assets/visual-editor.gif
new file mode 100644
index 000000000..fedca76a7
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/visual-editor.gif differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/visualizer.png b/fumadocs/content/docs/assets/landing-page/assets/visualizer.png
new file mode 100644
index 000000000..8433eb0a2
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/visualizer.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/visualizer.webp b/fumadocs/content/docs/assets/landing-page/assets/visualizer.webp
new file mode 100644
index 000000000..f1574372f
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/visualizer.webp differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode-1370.png b/fumadocs/content/docs/assets/landing-page/assets/vscode-1370.png
new file mode 100644
index 000000000..c59e786f9
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode-1370.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode-1760.png b/fumadocs/content/docs/assets/landing-page/assets/vscode-1760.png
new file mode 100644
index 000000000..a88f17fa9
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode-1760.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode-2048.png b/fumadocs/content/docs/assets/landing-page/assets/vscode-2048.png
new file mode 100644
index 000000000..2a460c9c2
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode-2048.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode-265.png b/fumadocs/content/docs/assets/landing-page/assets/vscode-265.png
new file mode 100644
index 000000000..517eacf8f
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode-265.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode-700.png b/fumadocs/content/docs/assets/landing-page/assets/vscode-700.png
new file mode 100644
index 000000000..c29df8f68
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode-700.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode-960.png b/fumadocs/content/docs/assets/landing-page/assets/vscode-960.png
new file mode 100644
index 000000000..691c56ff3
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode-960.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode-v1.png b/fumadocs/content/docs/assets/landing-page/assets/vscode-v1.png
new file mode 100644
index 000000000..0aa883f84
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode-v1.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/vscode.png b/fumadocs/content/docs/assets/landing-page/assets/vscode.png
new file mode 100644
index 000000000..d49b2be31
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/assets/vscode.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/assets/zapier.svg b/fumadocs/content/docs/assets/landing-page/assets/zapier.svg
new file mode 100644
index 000000000..e92a34808
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/assets/zapier.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/favicon.ico b/fumadocs/content/docs/assets/landing-page/favicon.ico
new file mode 100644
index 000000000..ae3e1e6d0
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/favicon.ico differ
diff --git a/fumadocs/content/docs/assets/landing-page/favicon.png b/fumadocs/content/docs/assets/landing-page/favicon.png
new file mode 100644
index 000000000..9ce2fc9fa
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/favicon.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/google228ac6fed9b49e9c.html b/fumadocs/content/docs/assets/landing-page/google228ac6fed9b49e9c.html
new file mode 100644
index 000000000..d5fc0365b
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/google228ac6fed9b49e9c.html
@@ -0,0 +1 @@
+google-site-verification: google228ac6fed9b49e9c.html
diff --git a/fumadocs/content/docs/assets/landing-page/icon-192.png b/fumadocs/content/docs/assets/landing-page/icon-192.png
new file mode 100644
index 000000000..46eb746ed
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/icon-192.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/icon-512.png b/fumadocs/content/docs/assets/landing-page/icon-512.png
new file mode 100644
index 000000000..f0246e83c
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/icon-512.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/icon.svg b/fumadocs/content/docs/assets/landing-page/icon.svg
new file mode 100644
index 000000000..32b0bf07f
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/icon.svg
@@ -0,0 +1,17 @@
+
+
+ Stately
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing-page/index.html b/fumadocs/content/docs/assets/landing-page/index.html
new file mode 100644
index 000000000..03a4a6d84
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/index.html
@@ -0,0 +1,760 @@
+
+
+
+ Stately | Understand your app logic
+
+
+ Understand your app logic, visually
+
+
+
+ Build logic together as a team. Then run the flows using
+ XState , a best-in-class open source library
+ for handling complexity at scale.
+
+
+
+
+
+
+
+ Video is unavailable in your browser.
+
+
+
+
+ Visual editor: Visualize your application logic
+
+
+ Use our drag-and-drop visual editor to build your application logic,
+ then export it directly into your XState project.
+
+
+
+ Try the editor
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Statecharts: Collaborate with everyone on the team
+
+
+ Not just for developers. Statecharts are a visual language that
+ everyone on the team can understand. Our editor and visualizer make
+ it easy for anyone to create and edit application logic.
+
+
+
+ Learn more about statecharts
+
+
+
+
+
+
+
+
+
+
+
+ IDE Extension: Upgrade your workflow
+
+
+ Bring the power of Stately’s tools directly into your development
+ environment. Edit statecharts visually in JavaScript and TypeScript
+ with our VS Code extension.
+
+
+
+ Download the VS Code extension
+
+
+
+
+
+ Before
+
+
+
+ After
+
+
+
+
+
+ State management:
+ Make complexity manageable
+
+
+ Statecharts make state management simpler. Get an overview of how
+ your application works at a glance. Find states that are often
+ missed, including unwanted states, impossible states and unnecessary
+ error states. As well as eliminating bugs and other issues caused by
+ boolean-based state management.
+
+
+
+ Get started with our quickstart guide
+
+
+
+
+
+
+
+
+
+ Registry: Explore and share
+
+
+ Share your machines with the community, get feedback and kudos for
+ your work.
+
+
+
+ Discover the machine registry
+
+
+
+
+
+ Powered by XState
+
+ XState is a robust,
+ production-proven library for building application logic with state
+ machines.
+
+
+
+
+
+
+ Loved by teams
+ User’s testimonials
+
+
+
+
+
+
+
Amy Pellegrini
+
@ Thoughtworks
+
+ Every team where I introduced XState has been more effective at
+ handling state management with complex user interfaces. It fills a
+ gap in the JS ecosystem no other tool did before.
+
+
+
+
+
+
+
Natalie Cuthbert
+
@ Stitch
+
+ We've been using XState for our new payments product. Shout out to
+ the team that is making designing complex front-end flows a dream.
+
+
+
+
+
+
+
Patrick Cavit
+
@ Netflix
+
+ XState is a revelation. It makes complex tasks easier to build and
+ debug while also making the code more straightforward and
+ approachable
+
+
+
+
+
+
+
Santi Cros
+
@ Domestic Data Streamers
+
+ Thinking and building with XState has been a revolution in how I
+ develop robust business logic. But being able to visualize that in
+ real time, has been a game changer in how I model and communicate
+ any logic!
+
+
+
+
+
+
+
Presley Pizzo
+
@ Coder
+
+ XState naturally separates the logic and makes it simple to mock
+ out API calls, so it's easier to test the code and organize it!
+
+
+
+
+
+
+
Maya Shavin
+
@ Microsoft
+
+ Advantages of XState: Visually clear view of the code flow, code
+ reusability, test coverage, easy to debug/ spot bugs, code
+ scalability & maintenance, and better code design & planning
+
+
+
+
+
+
+
James Tharpe
+
@ T-Mobile
+
+ We use XState to implement business workflows as statecharts. The
+ visualizer helps us collaborate more closely with customers, the
+ ability to externalize workflows as JSON configuration makes
+ complex workflow changes surprisingly simple to roll out, and test
+ case generation makes it easier than ever to move forward with
+ confidence. XState makes it all possible!
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/manifest.webmanifest b/fumadocs/content/docs/assets/landing-page/manifest.webmanifest
new file mode 100644
index 000000000..5ff8ac9df
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/manifest.webmanifest
@@ -0,0 +1,6 @@
+{
+ "icons": [
+ { "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" },
+ { "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" }
+ ]
+}
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing-page/mockup.svg b/fumadocs/content/docs/assets/landing-page/mockup.svg
new file mode 100644
index 000000000..89ec286fc
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/mockup.svg
@@ -0,0 +1,544 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/fumadocs/content/docs/assets/landing-page/stately-landing-page.png b/fumadocs/content/docs/assets/landing-page/stately-landing-page.png
new file mode 100644
index 000000000..12ef090bc
Binary files /dev/null and b/fumadocs/content/docs/assets/landing-page/stately-landing-page.png differ
diff --git a/fumadocs/content/docs/assets/landing-page/stately.svg b/fumadocs/content/docs/assets/landing-page/stately.svg
new file mode 100644
index 000000000..d55b59bf4
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/stately.svg
@@ -0,0 +1,19 @@
+
+
+ Stately
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing-page/styles.css b/fumadocs/content/docs/assets/landing-page/styles.css
new file mode 100644
index 000000000..e6b42f324
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/styles.css
@@ -0,0 +1,2378 @@
+/* -- Import font
+-------------------------------------------------------------------- */
+@font-face {
+ font-family: 'TTCommons';
+ src: url('assets/ttcommons.woff2') format('woff2');
+ font-display: swap;
+ font-weight: '100 1000';
+}
+
+/* -- Variables
+-------------------------------------------------------------------- */
+
+/* Color variables from Figma doc */
+:root {
+ --white: #fff;
+ --offwhite: #e2e2e2;
+ --grey00: #acacb4;
+ --grey01: #9595a2;
+ --grey02: #50515a;
+ --grey03: #313238;
+ --grey04: #292b2f;
+ --grey05: #27282d;
+ --grey06: #1f2024;
+ --black: #000; /* not named in figma */
+ --blue00: #056dff;
+ --blue01: #1956dd;
+ --blue: #3489ff; /* not named in figma*/
+ --red00: #f44747;
+ --red01: #ef0f0f;
+ --green: #018458;
+ --orange00: #ff9044;
+ --orange01: #e26f22;
+ --orange02: #c75000;
+
+ /* Text variables */
+ --text-body: var(--grey01);
+ --text-link: var(--blue);
+ --text-link-hovered: var(--blue00);
+ --text-link-pressed: var(--blue01);
+ --text-heading: var(--white);
+ --text-footer: var(--grey00);
+
+ --font-xxsmall: 0.8rem;
+ --font-xsmall: 0.9rem;
+ --font-small: 0.95rem;
+ --font-medium: 1rem;
+ --font-2medium: 1.2rem;
+ --font-large: 1.5rem;
+ --font-xl: 1.9rem;
+ --font-xxl: 2rem;
+ --font-xxxl: 2rem;
+
+ --spacing-tight: 0;
+ --spacing-normal: 0.02rem;
+ --spacing-loose: 0.05rem;
+ --spacing-looser: 0.1rem;
+ --spacing-loosest: 0.2rem;
+
+ /* Button variables */
+ --button-white-bg: var(--white);
+ --button-white-bg-hovered: var(--offwhite);
+ --button-white-bg-pressed: var(--grey00);
+ --button-white-txt: var(--grey06);
+
+ --button-blue-bg: var(--blue00);
+ --button-blue-bg-hovered: var(--blue);
+ --button-blue-bg-pressed: var(--blue01);
+ --button-blue-txt: var(--white);
+
+ --button-orange-bg: var(--orange02);
+ --button-orange-bg-hovered: var(--orange01);
+ --button-orange-bg-pressed: var(--orange01);
+ --button-orange-txt: var(--white);
+
+ --border-line: var(--grey03) 0.05em solid;
+ --border-line-light: var(--grey02) 0.05em solid;
+ --border-line-white: var(--white) 0.05em solid;
+
+ --drop-shadow: 0px 5px 10px rgba(0, 0, 0, 0.15);
+ --fadeout-box: 0px 0px 20px rgba(0, 0, 0, 0.85),
+ 0px 0px 30px rgba(0, 0, 0, 0.85), 0px 0px 40px rgba(0, 0, 0, 0.85);
+ --text-shadow: 0 0 1em var(--black), 0 0 1.5em var(--black),
+ 0 0 2em var(--black);
+ --text-shadow-light: 0 0 1em #151818, 0 0 1.5em #151818, 0 0 2em #151818;
+
+ /* z-index layers */
+ --above-text-layer: 4;
+ --text-layer: 3;
+ --below-text-layer: 2;
+ --background-layer: 1;
+
+ /* grid variables */
+ --grid-16-equal-columns: repeat(16, 1fr);
+ /* subgrids to fit inside the grid above */
+ --grid-4-equal-columns: repeat(4, 1fr);
+ --grid-6-equal-columns: repeat(6, 1fr);
+ --grid-12-equal-columns: repeat(12, 1fr);
+ --grid-13-equal-columns: repeat(13, 1fr);
+ --grid-14-equal-columns: repeat(14, 1fr);
+ --grid-15-equal-columns: repeat(15, 1fr);
+
+ --grid-rows-auto: max-content;
+
+ --max-header-width: 70em;
+ --max-content-width: 50em;
+
+ /* copied from Chakra for Pricing page */
+ --chakra-colors-gray-25: #f7f8fa;
+ --chakra-colors-gray-50: #efeff1;
+ --chakra-colors-gray-100: #e1e2e5;
+ --chakra-colors-gray-200: #d4d5da;
+ --chakra-colors-gray-200: #abacb5;
+ --chakra-colors-gray-400: #8f919d;
+ --chakra-colors-gray-500: #757785;
+ --chakra-colors-gray-600: #5d5f6a;
+ --chakra-colors-gray-700: #45464f;
+ --chakra-colors-gray-800: #2d2e34;
+ --chakra-colors-gray-850: #212226;
+ --chakra-colors-gray-700: #151618;
+}
+
+/* when the viewport reaches X wide, scale up most of the font sizes */
+
+@media (min-width: 25em) {
+ :root {
+ --font-small: 1.1rem;
+ --font-medium: 1.3rem;
+ --font-large: 1.5rem;
+ --font-xl: 2rem;
+ --font-xxl: 3rem;
+ --font-xxxl: 3.6rem;
+ }
+}
+
+/* when the viewport reaches X wide, centre the layout columns with flexible first and last columns */
+
+@media (min-width: 60em) {
+ :root {
+ /* grid variables */
+ --grid-16-equal-columns: calc(50vw - 29.5rem) repeat(14, 1fr)
+ calc(50vw - 29.5rem);
+ /* subgrids to fit inside the grid above */
+ --grid-15-columns-lastauto: repeat(14, 1fr) calc(50vw - 29.5rem);
+ --grid-14-columns-firstauto: calc(50vw - 29.5rem) repeat(13, 1fr);
+ }
+} /* end @media (min-width: 60em) */
+
+@media (min-width: 80em) {
+ :root {
+ /* grid variables */
+ --grid-16-equal-columns: calc(50vw - 35rem) repeat(14, 1fr)
+ calc(50vw - 35rem);
+ /* subgrids to fit inside the grid above */
+ --grid-15-columns-lastauto: repeat(14, 1fr) calc(50vw - 35rem);
+ --grid-14-columns-firstauto: calc(50vw - 35rem) repeat(13, 1fr);
+ }
+} /* end @media (min-width: 80em) */
+
+/* -- CSS reset
+-------------------------------------------------------------------- */
+
+/* Box sizing rules */
+*,
+*::before,
+*::after {
+ box-sizing: border-box;
+ position: relative;
+}
+
+html {
+ font-size: 100%; /* all font sizes and rems scale from here */
+}
+
+/* Set core body defaults */
+body {
+ font-synthesis: none;
+ line-height: 1.35;
+ margin: 0;
+ min-height: 100vh;
+ padding: 1em;
+ scroll-behavior: smooth;
+ text-rendering: optimizeSpeed;
+}
+
+/* Natural flow and rhythm by default */
+main > * + * {
+ margin: 0;
+ margin-top: 2.7em;
+ margin-bottom: 1.35em;
+}
+
+body.privacy main > * + *,
+body.code-of-conduct main > * + * {
+ margin-top: 1em;
+ margin-bottom: 0.5em;
+}
+
+/* Remove list styles on ul, ol elements with a class attribute */
+ul[class],
+ol[class] {
+ list-style: none;
+ margin: 0;
+ padding: 0;
+}
+
+/* A elements that don't have a class get default styles */
+a {
+ text-decoration-skip-ink: auto;
+ text-underline-offset: 0.15em;
+ text-decoration-thickness: 0.06em;
+ font-variation-settings: 'wght' 600;
+}
+
+/* Make images easier to work with */
+img,
+picture {
+ display: block;
+ max-width: 100%;
+}
+
+/* Inherit fonts for inputs and buttons */
+input,
+button,
+textarea,
+select {
+ color: inherit;
+ font: inherit;
+ border: inherit;
+ padding: inherit;
+}
+
+/* Style focus for people using keyboard navigation */
+:focus {
+ outline: 0.1rem solid var(--orange00);
+ box-shadow: 0 0 0.2rem var(--orange00);
+}
+
+/* Remove all animations and transitions for people that prefer not to see them */
+@media (prefers-reduced-motion: reduce) {
+ * {
+ animation-duration: 0.01ms !important;
+ animation-iteration-count: 1 !important;
+ scroll-behavior: auto !important;
+ transition-duration: 0.01ms !important;
+ }
+}
+
+@media print {
+ /* hide everything that’s not in the main body of the site */
+ body > *:not(main) {
+ display: none;
+ }
+}
+
+.visually-hidden {
+ position: absolute !important;
+ clip: rect(1px, 1px, 1px, 1px) !important;
+ padding: 0 !important;
+ border: 0 !important;
+ height: 1px !important;
+ width: 1px !important;
+ overflow: hidden !important;
+}
+
+/* -- Typography defaults
+-------------------------------------------------------------------- */
+
+html {
+ background-color: var(--black);
+ /* root font size */
+ font-size: 1em;
+}
+
+body {
+ /* gradient on top, grid underneath */
+ background: linear-gradient(180deg, rgba(0, 0, 0, 0) 15em, var(--black) 30em),
+ url(assets/grid-cell.svg) 0 0 repeat; /* 15em = point where grid is completely visible, 30em = point where gradient transitions to solid colour */
+ background-size: 100% 100%, 40px 40px;
+ background-attachment: scroll, scroll;
+ color: var(--text-body);
+ font-family: 'TTCommons', Arial, sans-serif;
+ font-size: 1em;
+ font-variation-settings: 'wght' 400;
+ font-size: var(--font-medium);
+ letter-spacing: var(--spacing-normal);
+ margin: 0;
+ min-width: 300px;
+}
+
+/* shorten grid fadeout on wider views */
+@media (min-width: 60em) {
+ body {
+ background: linear-gradient(
+ 180deg,
+ rgba(0, 0, 0, 0) 10em,
+ var(--black) 20em
+ ),
+ url(assets/grid-cell.svg) 0 0 repeat; /* 10em = point where grid is completely visible, 20em = point where gradient transitions to solid colour */
+ background-size: 100% 100%, 2.3rem 2.3rem;
+ }
+} /* end @media (min-width: 60em) */
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6 {
+ color: var(--text-heading);
+ line-height: 1.15;
+ letter-spacing: var(--spacing-loose);
+}
+
+h1 {
+ font-size: var(--font-xxl);
+ font-variation-settings: 'wght' 700;
+ margin-bottom: 0.25em;
+ text-align: center;
+}
+
+h2 {
+ font-size: var(--font-large);
+ font-variation-settings: 'wght' 500;
+}
+
+body.privacy main h2,
+body.code-of-conduct main h2 {
+ margin-top: 2em;
+}
+
+/* overwrite Docusaurus styling */
+
+h1 {
+ font-family: 'TTCommons', Arial, sans-serif;
+ font-size: 2em;
+ font-weight: 750;
+ margin: 0.67em 0;
+}
+
+h2 {
+ font-family: 'TTCommons', Arial, sans-serif;
+ font-weight: 750;
+ margin: 0.83em 0;
+}
+
+p {
+ margin: 1em 0;
+}
+
+/* end overwrite Docusaurus styling */
+
+a {
+ color: var(--text-link);
+ -webkit-transition: all 300ms ease-out;
+ transition: all 300ms ease-out;
+}
+
+a:hover,
+a:focus {
+ color: var(--text-link-hovered);
+}
+
+a:active {
+ color: var(--text-link-pressed);
+}
+
+/* for videos and iframes with aspect ratios */
+
+[style*='--aspect-ratio'] > :first-child {
+ width: 100%;
+}
+
+[style*='--aspect-ratio'] > img {
+ height: auto;
+}
+
+@supports (--custom: property) {
+ [style*='--aspect-ratio'] {
+ position: relative;
+ }
+ [style*='--aspect-ratio']::before {
+ content: '';
+ display: block;
+ padding-bottom: calc(100% / (var(--aspect-ratio)));
+ }
+ [style*='--aspect-ratio'] > :first-child {
+ position: absolute;
+ top: 0;
+ left: 0;
+ height: 100%;
+ }
+}
+
+video {
+ border-radius: 0.4em;
+ height: auto;
+ width: 100%;
+ z-index: var(--text-layer);
+}
+
+iframe {
+ border: none;
+ border-radius: 0.5em;
+}
+
+label {
+ color: var(--white);
+ font-size: var(--font-small);
+}
+
+input[type='email'],
+input[type='text'] {
+ background: var(--grey05);
+ border: none;
+ color: var(--white);
+ font-size: var(--font-xsmall);
+ line-height: 1;
+ padding: 0.75em;
+}
+
+body.landing-page p:not(li p) {
+ text-shadow: var(--text-shadow);
+}
+
+/* -- Reusable styles (components)
+-------------------------------------------------------------------- */
+
+/* screenshot image */
+
+.screenshot,
+.screenshot picture,
+.screenshot img {
+ background: var(--grey06);
+ box-shadow: var(--drop-shadow);
+ border: none;
+ border-radius: 0.4em;
+ display: block;
+ position: relative;
+ height: auto;
+ width: 100%;
+}
+
+figure picture,
+figure img {
+ border: none;
+ border-radius: 0.4em;
+ display: block;
+ position: relative;
+ height: auto;
+ width: 100%;
+}
+
+/* fadeout effect */
+
+.fadeout {
+ position: relative;
+}
+
+.fadeout:after {
+ background: linear-gradient(0deg, rgba(0, 0, 0, 1) 0%, rgba(0, 0, 0, 0) 100%);
+ content: '';
+ height: 100%;
+ position: absolute;
+ top: 0;
+ left: 0;
+ width: 100%;
+ z-index: var(--text-layer);
+}
+
+.fadeout-box {
+ background-color: rgba(0, 0, 0, 0.9); /* so arrows don’t show through */
+ box-shadow: var(--fadeout-box);
+ z-index: var(--text-layer);
+}
+
+.description {
+ z-index: var(--text-layer);
+}
+
+.description > p {
+ max-width: 50ch; /* maximum characters per line */
+}
+
+/* grid background */
+.grid-background {
+ background: url(assets/grid-cell.svg) 0 0 repeat, rgba(0, 0, 0, 0.9);
+ background-size: 40px 40px; /* same as body bg */
+ background-attachment: scroll;
+ position: absolute; /* remove from layout flow */
+ height: 161px; /* 4 cells */
+ width: 281px; /* 7 cells */
+}
+/* arrow link */
+
+.arrow-link {
+ background: url(assets/arrow-right.svg) left center no-repeat;
+ background-size: 1.2em 1.2em;
+ font-size: var(--font-small);
+ padding-left: 1.8em;
+}
+
+.arrow-link-paragraph {
+ margin-bottom: 2.7em;
+}
+
+/* arrows */
+
+.arrow {
+ color: var(--white);
+}
+
+/* button link */
+
+input[type='submit'],
+.button-link {
+ background: var(--button-blue-bg);
+ border-radius: 0.2em;
+ color: var(--button-blue-txt);
+ display: inline-block;
+ font-size: var(--font-xsmall);
+ margin: 0.3em;
+ padding: 0.65em 0.8em;
+ text-align: center;
+ text-decoration: none;
+ -webkit-transition: all 300ms ease-out;
+ transition: all 300ms ease-out;
+ text-shadow: none;
+}
+
+.button-link.orange {
+ background: var(--button-orange-bg);
+ border-radius: 0.2em;
+ color: var(--button-orange-txt);
+}
+
+.button-link.ghost {
+ background: none;
+ border: 1px solid rgba(255, 255, 255, 0.24);
+}
+.button-link.ghost:hover,
+.button-link-cta-ghost:active {
+ background: rgba(255, 255, 255, 0.11);
+}
+
+.duo-buttons {
+ display: flex;
+ flex-wrap: wrap;
+ justify-content: center;
+ align-content: center;
+ align-items: flex-start;
+ gap: 1em;
+ padding: 1em;
+ width: max-content;
+ justify-self: center;
+}
+
+.button-link-cta,
+.button-link-cta-primary,
+.button-link-cta-secondary {
+ font-size: var(--font-2medium);
+}
+
+.button-link-cta-primary {
+ background: var(--button-orange-bg);
+}
+
+.button-link.button-link-cta-primary:hover,
+.button-link.button-link-cta-primary:active {
+ background: var(--button-orange-bg-hovered);
+}
+
+.button-link {
+ display: flex;
+ flex-direction: column;
+ flex-wrap: nowrap;
+ justify-content: center;
+ align-content: center;
+ align-items: center;
+}
+
+.button-link.pill {
+ border-radius: 1.5em;
+}
+
+.button-link:hover,
+.button-link:focus,
+input[type='submit']:hover,
+input[type='submit']:focus {
+ background: var(--button-blue-bg-hovered);
+ color: var(--button-blue-txt);
+}
+
+.button-link.orange:hover,
+.button-link.orange:focus {
+ background: var(--button-orange-bg-hovered);
+ color: var(--button-orange-txt);
+}
+
+.button-link:active,
+input[type='submit']:active {
+ background: var(--button-blue-bg-pressed);
+ color: var(--button-blue-txt);
+}
+
+@media (min-width: 25em) {
+ .button-link,
+ input[type='submit'] {
+ padding: 0.8em 1.6em;
+ }
+}
+
+.button-link.white,
+input[type='submit'].white {
+ background: var(--button-white-bg);
+ color: var(--button-white-txt);
+}
+
+.button-link.white:hover,
+.button-link.white:focus,
+input[type='submit'].white:hover,
+input[type='submit'].white:focus {
+ background: var(--button-white-bg-hovered);
+ color: var(--button-white-txt);
+}
+
+.button-link.white:active,
+input[type='submit'].white:active {
+ background: var(--button-white-bg-pressed);
+ color: var(--button-white-txt);
+}
+
+/* eyebrow */
+
+.eyebrow {
+ color: var(--text-body);
+ display: block;
+ font-size: var(--font-xxsmall);
+ letter-spacing: var(--spacing-loosest);
+ margin-top: 1em;
+ margin-bottom: 1em;
+ text-transform: uppercase;
+}
+
+/* -- General layout
+-------------------------------------------------------------------- */
+
+body {
+ padding: 0.675em 0;
+}
+
+@media (min-width: 23em) {
+ body {
+ padding: 0.675em 0;
+ }
+}
+
+#content {
+ margin-left: auto;
+ margin-right: auto;
+ padding: 0 1.35em;
+}
+
+@supports (display: grid) {
+ #content,
+ #newsletter,
+ .site-footer {
+ display: grid;
+ grid-template-columns: var(--grid-16-equal-columns);
+ padding-left: 0;
+ padding-right: 0;
+ }
+
+ #content > *,
+ #newsletter > *,
+ .site-footer > * {
+ grid-column: 2 / 16;
+ }
+
+ body.privacy #content > *,
+ body.code-of-conduct #content > * {
+ grid-column: 2 / 16;
+ }
+
+ @media (min-width: 45em) {
+ #content.landing-page {
+ display: grid;
+ grid-template-columns: var(--grid-16-equal-columns);
+ grid-template-rows: var(--grid-rows-auto);
+ /* make grid full-width */
+ padding-left: 0;
+ padding-right: 0;
+ }
+
+ body.privacy #content > *,
+ body.code-of-conduct #content > * {
+ grid-column: 4 / 14;
+ }
+ } /* end @media (min-width: 45em) */
+} /* end @supports (display: grid) */
+
+@supports (display: flex) {
+ .center-small {
+ box-sizing: content-box;
+ margin-inline: auto;
+ max-inline-size: 100%;
+ max-width: 52ch;
+ display: flex;
+ flex-direction: column;
+ align-items: center;
+ text-align: center;
+ }
+} /* end @supports (display:flex) */
+
+/* -- Header
+-------------------------------------------------------------------- */
+
+.site-header {
+ margin: 0.3em auto 4.6em;
+ max-width: var(--max-header-width);
+ padding: 0 1.35em;
+}
+
+.navigation-list a {
+ color: var(--white);
+ display: block;
+ padding: 0.5em 0.75em;
+ text-decoration: none;
+}
+
+.navigation-list li:nth-of-type(1) {
+ margin-top: 0.5em;
+}
+
+.navigation-list a:hover,
+.navigation-list a:active,
+.navigation-list a:focus {
+ text-decoration: underline;
+ text-underline-offset: 0.15em;
+ text-decoration-thickness: 0.06em;
+}
+
+@supports (display: flex) {
+ .site-header {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ justify-content: space-between;
+ align-content: flex-start;
+ align-items: flex-start;
+ }
+
+ @media (min-width: 45em) {
+ .site-header {
+ flex-wrap: nowrap;
+ }
+
+ .navigation {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ justify-content: flex-end;
+ align-content: stretch;
+ align-items: flex-start;
+ gap: 0.5em;
+ }
+
+ .navigation-list {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ justify-content: flex-end;
+ align-content: stretch;
+ align-items: flex-start;
+ }
+
+ .navigation-list li:nth-of-type(1) {
+ margin-top: 0;
+ }
+
+ .navigation-list a {
+ padding: 0.3em 0.5em;
+ }
+
+ .navigation .button-link {
+ /* move button link out of flow, to right */
+ order: 2;
+ }
+ } /* end @media (min-width: 45em) */
+} /* end @supports (display: flex) */
+
+.site-header .logo {
+ margin: 0.3em 0.2em 0.5em 0;
+}
+
+.site-header .logo img {
+ height: 1em;
+ width: auto;
+}
+
+@media (min-width: 20em) {
+ .site-header .logo {
+ margin: 0 0.5em 0.5em 0;
+ }
+
+ .site-header .logo img {
+ height: 1.5em;
+ }
+} /* end @media (min-width: 20em) */
+
+@media (min-width: 30em) {
+ .site-header .logo {
+ margin: 0 0.6em 0.5em 0;
+ }
+
+ .site-header .logo img {
+ height: 1.68em;
+ }
+}
+
+@supports (display: flex) {
+ .button-list {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ justify-content: flex-end;
+ align-content: flex-start;
+ align-items: flex-start;
+ gap: 0.6em;
+ }
+
+ .button-link {
+ margin: 0 0 0.75rem 0;
+ }
+} /* end @supports (display: flex) */
+
+/* -- Intro
+-------------------------------------------------------------------- */
+
+.intro-title {
+ font-size: var(--font-xxxl);
+ font-variation-settings: 'wght' 700;
+}
+
+[data-edge-source='first-heading'] {
+ padding: 0 0 0.5em;
+}
+
+.subtitle {
+ margin-left: auto;
+ margin-right: auto;
+ max-width: 52ch;
+ text-align: center;
+}
+
+@supports (display: grid) {
+ @media (min-width: 45em) {
+ /* position each item on the grid */
+ .intro-title {
+ grid-column: 6 / 12; /* 6 cols */
+ }
+
+ .initial-state {
+ grid-column: 7 / 11; /* 4 cols */
+ }
+ } /* end @media (min-width: 45em) */
+} /* end @supports (display: grid) */
+
+.feature {
+ margin-top: 4.05em;
+}
+
+/* -- Feature #1: Editor
+-------------------------------------------------------------------- */
+
+.feature.editor .grid-background {
+ grid-row: 2 / span 2;
+ left: -1.1em;
+}
+
+@supports (display: grid) {
+ #content > .feature.editor {
+ grid-column: 1 / span 16; /* 16 cols */
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-16-equal-columns);
+ grid-template-rows: auto auto auto;
+ }
+
+ #content > .feature.editor > * {
+ grid-column: 2 / span 14;
+ }
+
+ @media (min-width: 45em) {
+ #content > .feature.editor .video-wrap {
+ grid-column: 8 / span 8;
+ z-index: var(--above-text-layer);
+ }
+
+ #content > .feature.editor .description {
+ grid-column: 2 / span 6;
+ grid-row: 1 / span 2;
+ padding-right: 1em;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ #content > .feature.editor {
+ grid-column: 1 / span 14; /* 14 cols */
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-14-columns-firstauto);
+ grid-template-rows: var(--grid-rows-auto);
+ }
+
+ #content > .feature.editor .grid-background {
+ height: 241px;
+ width: 681px;
+ }
+ } /* end @media (min-width: 60em) */
+} /* end @supports (display: grid) */
+
+/* -- Feature #2: Statecharts
+-------------------------------------------------------------------- */
+
+@supports (display: grid) {
+ .feature.statecharts .grid-background {
+ grid-row: 2 / span 2;
+ right: -1.2em;
+ }
+
+ #content > .feature.statecharts {
+ grid-column: 2 / span 14; /* 14 cols */
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-14-equal-columns);
+ grid-template-rows: auto auto;
+ }
+
+ #content > .feature.statecharts > * {
+ grid-column: 1 / span 14;
+ }
+
+ #content > .feature.statecharts > .screenshot {
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-14-equal-columns);
+ grid-template-rows: auto;
+ }
+
+ #content > .feature.statecharts > .screenshot > picture {
+ grid-column: 1 / span 14;
+ grid-row: 1 / span 1; /* overlap */
+ }
+
+ /* comments */
+
+ .comment {
+ background: var(--blue01);
+ border-color: var(--blue01) transparent;
+ border-radius: 1.5em;
+ color: var(--white);
+ font-size: var(--font-xxsmall);
+ max-width: 26ch;
+ padding: 0.75em 1em;
+ position: relative;
+ text-align: center;
+ width: auto;
+ z-index: var(--above-text-layer);
+ }
+
+ .comment-1 {
+ position: absolute;
+ top: 0;
+ margin-left: 50%;
+ }
+
+ .comment-2 {
+ background: var(--orange02);
+ position: absolute;
+ margin-top: 50%;
+ right: 0;
+ }
+
+ .comment-3 {
+ background: var(--green);
+ position: absolute;
+ margin-top: 95%;
+ right: 0;
+ }
+
+ .comment:after {
+ content: '';
+ border-color: var(--blue01) transparent;
+ position: absolute;
+ display: block;
+ width: 0;
+ z-index: 1;
+ border-style: solid;
+ /* arrow at top */
+ border-width: 0 0.65em 1em;
+ top: -0.95em;
+ left: 50%;
+ margin-left: -1em;
+ }
+
+ .comment-2:after {
+ border-color: transparent var(--orange02);
+ /* arrow on right */
+ border-width: 0.65em 0 0.65em 1em;
+ top: 50%;
+ left: auto;
+ right: -0.95em;
+ margin-top: -0.65em;
+ }
+
+ .comment-3:after {
+ border-color: var(--green) transparent;
+ /* arrow at bottom */
+ border-width: 1em 0.65em 0;
+ bottom: -0.99em;
+ top: auto;
+ }
+
+ @media (min-width: 50em) {
+ #content > .feature.statecharts > .grid-background {
+ display: none;
+ }
+
+ #content > .feature.statecharts > .screenshot {
+ grid-template-rows: repeat(4, auto);
+ }
+
+ #content > .feature.statecharts > .description {
+ grid-column: 9 / span 6;
+ grid-row: 1 / span 2;
+ padding: 34px 1.5em 0 2em; /* px helps line up with background grid */
+ text-shadow: var(--text-shadow-light);
+ }
+
+ #content > .feature.statecharts > .description p {
+ background: none;
+ box-shadow: none;
+ }
+
+ #content > .feature.statecharts > .screenshot {
+ background: url(./assets/editor-background-grid.svg) repeat;
+ grid-column: 1 / span 14;
+ grid-row: 1 / span 5;
+ padding: 1em; /* shows the grid background behind */
+ }
+
+ #content > .feature.statecharts > .screenshot > picture {
+ grid-column: 1 / span 8;
+ }
+
+ .comment {
+ font-size: var(--font-small);
+ }
+
+ #content > .feature.statecharts > .comment-1 {
+ grid-column: 4 / span 4;
+ grid-row: 1 / span 1;
+ position: relative;
+ margin: 0;
+ margin-top: -0.5em; /* pull slightly off grid */
+ }
+
+ #content > .feature.statecharts > .comment-2 {
+ justify-self: flex-end;
+ grid-column: 9 / span 6;
+ grid-row: 4 / span 1;
+ position: relative;
+ margin: 0;
+ }
+
+ #content > .feature.statecharts > .comment-3 {
+ grid-column: 2 / span 4;
+ grid-row: 5 / span 1;
+ position: relative;
+ margin: 0;
+ margin-bottom: -0.5em; /* pull slightly off grid */
+ }
+ } /* end @media (min-width: 50em) */
+
+ @media (min-width: 70em) {
+ #content > .feature.statecharts > .comment-2 {
+ margin-right: -0.5em; /* pull slightly off grid */
+ }
+ } /* end @media (min-width: 70em) */
+} /* end @supports (display: grid) */
+
+/* -- Feature #3: VS Code extension
+-------------------------------------------------------------------- */
+
+.feature.vscode .screenshot {
+ margin-bottom: -2em; /* pull under following content */
+}
+
+@supports (display: grid) {
+ #content > .feature.vscode {
+ grid-column: 1 / span 14; /* 14 cols */
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-14-equal-columns);
+ grid-template-rows: auto auto;
+ }
+
+ #content > .feature.vscode > * {
+ grid-column: 2 / span 13;
+ }
+
+ #content > .feature.vscode .grid-background {
+ grid-row: 2 / span 1;
+ }
+
+ #content > .feature.vscode .screenshot {
+ grid-column: 1 / span 14;
+ }
+
+ @media (min-width: 60em) {
+ #content > .feature.vscode {
+ grid-column: 2 / span 14;
+ grid-template-columns: var(--grid-14-equal-columns);
+ }
+
+ #content > .feature.vscode .grid-background {
+ grid-column: 5 / span 9;
+ height: 241px;
+ width: 681px;
+ justify-self: center;
+ }
+
+ #content > .feature.vscode .description {
+ grid-column: 6 / span 7;
+ }
+
+ #content > .feature.vscode .screenshot {
+ grid-column: 1 / span 14;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 95em) {
+ #content > .feature.vscode .description {
+ margin-top: -7em;
+ }
+
+ #content > .feature.vscode .screenshot {
+ grid-column: 2 / span 12;
+ }
+ } /* end @media (min-width: 95em) */
+} /* end @supports (display: grid) */
+
+/* -- Feature #4: State management
+-------------------------------------------------------------------- */
+
+.feature.state-management .grid-background {
+ /* narrower */
+ width: 161px;
+}
+
+#content > .feature.state-management > figure {
+ z-index: var(--below-text-layer);
+}
+
+@supports (display: grid) {
+ #content > .feature.feature.state-management {
+ grid-column: 1 / span 16; /* 16 cols */
+ }
+
+ #content > .feature.feature.state-management {
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-16-equal-columns);
+ grid-template-rows: auto auto auto;
+ }
+
+ #content > .feature.state-management > * {
+ grid-column: 2 / span 14;
+ }
+
+ .feature.state-management figure {
+ margin: 0;
+ }
+
+ .feature.state-management .grid-background {
+ grid-row: 2 / span 2;
+ margin-left: -1em;
+ }
+
+ #content > .feature.state-management > figure:nth-of-type(1) {
+ grid-column: 1 / span 8;
+ grid-row: 1 / span 1;
+ }
+
+ #content > .feature.state-management > figure:nth-of-type(2) {
+ grid-column: 9 / span 8;
+ grid-row: 1 / span 1;
+ }
+
+ #content > .feature.state-management .before,
+ #content > .feature.state-management .after {
+ color: var(--white);
+ z-index: var(--above-text-layer);
+ margin: 0;
+ padding: 0 1em;
+ position: absolute;
+ text-shadow: var(--text-shadow);
+ width: 100%;
+ }
+
+ #content > .feature.state-management .after {
+ text-align: right;
+ }
+
+ @media (min-width: 45em) {
+ #content > .feature.state-management {
+ grid-column: 3 / span 12; /* 12 cols */
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ #content > .feature.state-management .description {
+ grid-column: 3 / span 5;
+ grid-row: 2 / span 1;
+ margin-top: 3em;
+ padding-right: 1em;
+ }
+
+ #content > .feature.state-management .grid-background {
+ height: 241px;
+ width: 521px;
+ margin-top: 2em;
+ }
+
+ #content > .feature.state-management .description p.fadeout-box {
+ background: none;
+ box-shadow: none;
+ text-shadow: var(--text-shadow);
+ }
+
+ #content > .feature.state-management > figure:nth-of-type(1) {
+ grid-column: 1 / span 9;
+ grid-row: 1 / span 1;
+ }
+
+ #content > .feature.state-management > figure:nth-of-type(2) {
+ grid-column: 8 / span 9;
+ grid-row: 2 / span 1;
+ margin-top: -10em; /* pull into row above slightly */
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 95em) {
+ #content > .feature.feature.state-management {
+ grid-column: 2 / 16; /* 14 cols */
+ }
+
+ #content > .feature.feature.state-management {
+ /* subgrid */
+ grid-template-columns: var(--grid-14-equal-columns);
+ }
+
+ #content > .feature.state-management .description {
+ grid-column: 2 / 7;
+ }
+
+ #content > .feature.state-management > figure:nth-of-type(1) {
+ grid-column: 1 / 9;
+ }
+
+ #content > .feature.state-management > figure:nth-of-type(2) {
+ grid-column: 7 / 16;
+ }
+ } /* end @media (min-width: 90em) */
+} /* end @supports (display: grid) */
+
+/* -- Feature #5: Registry
+-------------------------------------------------------------------- */
+
+.feature.registry .screenshot {
+ margin-bottom: -4em; /* pull under following content */
+}
+
+.feature.registry .grid-background {
+ display: none;
+}
+
+@supports (display: grid) {
+ @media (min-width: 45em) {
+ #content > .feature.registry {
+ grid-column: 3 / span 13; /* 13 cols */
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ #content > .feature.registry {
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-13-equal-columns);
+ grid-template-rows: var(--grid-rows-auto);
+ }
+
+ #content > .feature.registry .description {
+ grid-column: 1 / 9;
+ margin-top: -3em;
+ }
+
+ .feature.registry .grid-background {
+ display: block;
+ grid-column: 1 / 9;
+ grid-row: 2 / span 1;
+ height: 241px;
+ width: 521px;
+ margin-left: -38px;
+ margin-top: -3.75em;
+ }
+
+ #content > .feature.registry .description .fadeout-box {
+ background: none;
+ box-shadow: none;
+ text-shadow: var(--text-shadow);
+ }
+
+ #content > .feature.registry .screenshot {
+ grid-column: 4 / span 11;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 95em) {
+ #content > .feature.registry .description {
+ margin-top: -10em;
+ margin-bottom: 8em;
+ }
+
+ #content > .feature.registry .screenshot {
+ grid-column: 4 / span 10;
+ }
+ } /* end @media (min-width: 95em) */
+} /* end @supports (display: grid) */
+
+/* -- Further features: Powered by XState list
+-------------------------------------------------------------------- */
+
+.powered-by-xstate .grid-background {
+ width: 241px;
+}
+
+[data-edge-source='powered-by-xstate'] {
+ padding-top: 0.5em;
+}
+
+[data-edge-source='powered-by-xstate-subhead'] {
+ padding: 0.5em 1em;
+ margin-top: 0;
+}
+
+@supports (display: grid) {
+ #content > .powered-by-xstate {
+ grid-column: 3 / span 12; /* 12 cols */
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-12-equal-columns);
+ grid-template-rows: auto auto auto;
+ }
+
+ #content > .powered-by-xstate > * {
+ grid-column: 1 / span 12;
+ }
+
+ #content > .powered-by-xstate > .grid-background {
+ grid-column: 1 / span 12;
+ grid-row: 1 / span 2;
+ justify-self: center;
+ }
+
+ @media (min-width: 45em) {
+ #content > .powered-by-xstate > p {
+ grid-column: 3 / span 8;
+ }
+
+ #content > .powered-by-xstate > .powered-by-xstate-list {
+ grid-column: 2 / span 10;
+ }
+ }
+
+ @media (min-width: 35em) {
+ #content > .powered-by-xstate > .grid-background {
+ width: 521px;
+ }
+ } /* end @media (min-width: 30em) */
+
+ @media (min-width: 60em) {
+ .powered-by-xstate-list {
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-12-equal-columns);
+ grid-template-rows: var(--grid-rows-auto);
+ }
+
+ .powered-by-xstate-list li {
+ grid-column: 1 / span 5;
+ }
+
+ .powered-by-xstate-list li:nth-of-type(2n) {
+ grid-column: 8 / span 5;
+ }
+ } /* end @media (min-width: 60em) */
+} /* end @supports (display: grid) */
+
+.powered-by-xstate {
+ text-align: center;
+}
+
+.powered-by-xstate-heading {
+ font-size: var(--font-xxl);
+ margin-bottom: 0.5em;
+}
+
+.powered-by-xstate-list .extra-feature {
+ background: url(assets/starburst.svg) top center no-repeat;
+ background-size: 5em 5em;
+ margin-top: 3em;
+ padding-top: 5.3em; /* leave space for starburst */
+ position: relative;
+ z-index: var(--text-layer);
+}
+
+.powered-by-xstate-list .extra-feature:before {
+ background: top center no-repeat;
+ background-size: 2.5em 5em;
+ content: '';
+ display: block;
+ height: 5em;
+ position: absolute;
+ width: 5em;
+ top: 0;
+ left: 50%;
+ margin-left: -2.5em;
+}
+
+.powered-by-xstate-list .js:before {
+ background-image: url(assets/js.svg);
+}
+
+.powered-by-xstate-list .packages:before {
+ background-image: url(assets/packages.svg);
+}
+
+.powered-by-xstate-list .github:before {
+ background-image: url(assets/github.svg);
+}
+
+.powered-by-xstate-list .stack:before {
+ background-image: url(assets/stack.svg);
+}
+
+.powered-by-xstate-list .robust:before {
+ background-image: url(assets/hammer.svg);
+}
+
+.powered-by-xstate-list .discord:before {
+ background-image: url(assets/discord.svg);
+}
+
+/* -- Testimonials
+-------------------------------------------------------------------- */
+
+.loved-by-teams > h2 {
+ font-size: var(--font-xl);
+ text-align: center;
+}
+
+.testimonial {
+ background: var(--grey04);
+ box-shadow: var(--drop-shadow);
+ border-radius: 1em;
+ margin-bottom: 1em;
+ padding: 2em 1.35em 0.75em 1.35em;
+}
+
+.grid-background-two {
+ display: none;
+}
+
+@supports (display: grid) {
+ #content > .loved-by-teams {
+ grid-column: 1 / span 16;
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-16-equal-columns);
+ grid-template-rows: auto auto auto;
+ }
+
+ #content > .loved-by-teams .grid-background {
+ grid-row: 1 / span 2;
+ grid-column: 1 / span 15;
+ justify-self: center;
+ }
+
+ .loved-by-teams > * {
+ grid-column: 1 / span 15;
+ }
+
+ @media (min-width: 45em) {
+ #content > .loved-by-teams {
+ grid-column: 2 / span 15; /* 15 cols */
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ #content > .loved-by-teams {
+ grid-template-columns: var(--grid-15-columns-lastauto);
+ }
+
+ #content > .loved-by-teams h2 {
+ text-align: left;
+ grid-column: 1 / span 4;
+ }
+
+ #content > .loved-by-teams .grid-background {
+ grid-column: 1 / span 6;
+ justify-self: baseline;
+ margin-left: -38px;
+ margin-top: -24px;
+ }
+
+ #content > .loved-by-teams .grid-background-two {
+ display: block;
+ height: 521px;
+ width: 521px;
+ margin-left: 0;
+ margin-top: 0;
+ align-self: center;
+ grid-row: 2 / span 1;
+ grid-column: 7 / span 6;
+ }
+ } /* end @media (min-width: 60em) */
+
+ /* give testimonials the offset layout */
+ .testimonials {
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-16-equal-columns);
+ grid-template-rows: var(--grid-rows-auto);
+ }
+
+ @media (min-width: 60em) {
+ .testimonials {
+ grid-template-columns: var(--grid-15-columns-lastauto);
+ }
+ } /* end @media (min-width: 45em) */
+
+ .testimonials > * {
+ grid-column: 2 / span 14;
+ margin-bottom: -0.75em; /* pull under testimonial above */
+ }
+ /* -- Testimonial 1
+--------------------------- */
+
+ .testimonials li:nth-of-type(1) {
+ grid-column: 2 / span 14;
+ margin-top: 3em; /* space for heading */
+ position: relative;
+ z-index: 10;
+ }
+
+ @media (min-width: 45em) {
+ .testimonials li:nth-of-type(1) {
+ grid-column: 3 / span 12;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ .testimonials li:nth-of-type(1) {
+ grid-column: 6 / span 7;
+ grid-row: -2;
+ }
+ } /* end @media (min-width: 60em) */
+
+ /* User’s testimonials heading */
+
+ .testimonials li:nth-of-type(1):before,
+ .testimonials li:nth-of-type(1):after {
+ content: '';
+ display: block;
+ position: absolute;
+ }
+
+ .testimonials li:nth-of-type(1):before {
+ background-color: var(--grey04);
+ background-image: url('assets/side-arrow.svg');
+ background-repeat: no-repeat;
+ background-position: 1.5em 1.25em;
+ border-top-left-radius: 1em;
+ border-top-right-radius: 1em;
+ border-bottom: var(--border-line-light);
+ height: 3em;
+ padding: 0 1.5em;
+ margin-bottom: 0;
+ top: -3em;
+ left: 0;
+ width: 100%;
+ }
+
+ .testimonials li:nth-of-type(1):after {
+ border-bottom: var(--border-line-white);
+ color: var(--white);
+ font-size: var(--font-xsmall);
+ content: 'User’s testimonials';
+ height: 4em;
+ padding: 1.5em 0;
+ letter-spacing: 0.1em;
+ right: 1.5em;
+ text-transform: uppercase;
+ text-align: right;
+ top: -4em;
+ width: auto;
+ }
+
+ /* -- Testimonial 2
+--------------------------- */
+
+ .testimonials li:nth-of-type(2) {
+ grid-column: 4 / span 13;
+ z-index: 9;
+ }
+
+ @media (min-width: 45em) {
+ .testimonials li:nth-of-type(2) {
+ grid-column: 5 / span 12;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ .testimonials li:nth-of-type(2) {
+ grid-column: 8 / span 7;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 90em) {
+ .testimonials li:nth-of-type(2) {
+ grid-column: 7 / span 7;
+ }
+ } /* end @media (min-width: 90em) */
+
+ /* -- Testimonial 3
+--------------------------- */
+
+ .testimonials li:nth-of-type(3) {
+ grid-column: 1 / span 13;
+ z-index: 8;
+ }
+
+ @media (min-width: 45em) {
+ .testimonials li:nth-of-type(3) {
+ grid-column: 2 / span 11;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ .testimonials li:nth-of-type(3) {
+ grid-column: 3 / span 7;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 90em) {
+ .testimonials li:nth-of-type(3) {
+ grid-column: 4 / span 6;
+ }
+ } /* end @media (min-width: 90em) */
+
+ /* -- Testimonial 4
+--------------------------- */
+
+ .testimonials li:nth-of-type(4) {
+ grid-column: 2 / span 14;
+ z-index: 7;
+ }
+
+ @media (min-width: 45em) {
+ .testimonials li:nth-of-type(4) {
+ grid-column: 4 / span 11;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ .testimonials li:nth-of-type(4) {
+ grid-column: 5 / span 8;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 90em) {
+ .testimonials li:nth-of-type(4) {
+ grid-column: 5 / span 7;
+ }
+ } /* end @media (min-width: 90em) */
+
+ /* -- Testimonial 5
+--------------------------- */
+
+ .testimonials li:nth-of-type(5) {
+ grid-column: 4 / span 13;
+ z-index: 6;
+ }
+
+ @media (min-width: 45em) {
+ .testimonials li:nth-of-type(5) {
+ grid-column: 7 / span 9;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ .testimonials li:nth-of-type(5) {
+ grid-column: 8 / span 7;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 90em) {
+ .testimonials li:nth-of-type(5) {
+ grid-column: 7 / span 6;
+ }
+ } /* end @media (min-width: 90em) */
+
+ /* -- Testimonial 6
+--------------------------- */
+
+ .testimonials li:nth-of-type(6) {
+ grid-column: 1 / span 13;
+ z-index: 5;
+ }
+
+ @media (min-width: 45em) {
+ .testimonials li:nth-of-type(6) {
+ grid-column: 1 / span 11;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ .testimonials li:nth-of-type(6) {
+ grid-column: 5 / span 7;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 90em) {
+ .testimonials li:nth-of-type(6) {
+ grid-column: 4 / span 7;
+ }
+ } /* end @media (min-width: 90em) */
+
+ /* -- Testimonial 7
+--------------------------- */
+
+ .testimonials li:nth-of-type(7) {
+ grid-column: 3 / span 14;
+ z-index: 4;
+ }
+
+ @media (min-width: 45em) {
+ .testimonials li:nth-of-type(7) {
+ grid-column: 4 / span 10;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ .testimonials li:nth-of-type(7) {
+ grid-column: 7 / span 8;
+ }
+ } /* end @media (min-width: 60em) */
+
+ @media (min-width: 90em) {
+ .testimonials li:nth-of-type(7) {
+ grid-column: 6 / span 6;
+ }
+ } /* end @media (min-width: 90em) */
+
+ .testimonial-about {
+ display: grid;
+ grid-template-columns: 3em auto;
+ grid-template-rows: auto auto;
+ }
+
+ .testimonial-about picture {
+ grid-column: 1 / 2;
+ grid-row: 1 / 3;
+ }
+
+ .testimonial-about .name {
+ grid-column: 2 / 3;
+ grid-row: 1 / 2;
+ margin: 0;
+ }
+
+ .testimonial-about .works-with {
+ grid-column: 2 / 3;
+ grid-row: 2 / 2;
+ margin: 0;
+ }
+}
+
+@supports (display: flex) {
+ .testimonial {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ justify-content: flex-start;
+ align-content: flex-start;
+ align-items: flex-start;
+ }
+}
+
+.testimonial:first-of-type {
+ border-top-left-radius: 0;
+ border-top-right-radius: 0;
+ padding-top: 1em;
+}
+
+.testimonial .avatar {
+ border-radius: 50%;
+ height: 3em;
+ width: 3em;
+}
+
+.testimonial .name {
+ color: var(--grey00);
+ padding-left: 1rem;
+ margin-bottom: 0.2em;
+}
+
+.testimonial .works-with {
+ color: var(--grey01);
+ font-size: var(--font-xsmall);
+ line-height: 1;
+ padding-left: 1rem;
+}
+
+.testimonial-text {
+ color: var(--white);
+}
+
+/* -- Company logos
+-------------------------------------------------------------------- */
+
+.used-in-production > h2 {
+ margin-bottom: 2em;
+ padding: 0.5em 0;
+}
+
+.used-in-production .grid-background {
+ height: 81px;
+ justify-self: center;
+}
+
+@supports (display: grid) {
+ @media (min-width: 45em) {
+ #content > .used-in-production {
+ grid-column: 2 / 15;
+ max-width: 100%;
+ } /* 13 cols */
+
+ .used-in-production > h2 {
+ align-items: flex-start;
+ }
+ } /* end @media (min-width: 45em) */
+
+ @media (min-width: 60em) {
+ #content > .used-in-production {
+ /* subgrid */
+ display: grid;
+ grid-template-columns: var(--grid-13-equal-columns);
+ grid-template-rows: var(--grid-rows-auto);
+ }
+
+ .used-in-production > h2 {
+ text-align: left;
+ justify-content: center;
+ grid-column: 1 / 5;
+ }
+
+ .used-in-production .grid-background {
+ height: 121px;
+ width: 321px;
+ grid-column: 1 / 5;
+ }
+
+ .used-in-production .logo-list {
+ grid-column: 5 / 14;
+ }
+ } /* end @media (min-width: 60em) */
+} /* end @supports (display: grid) */
+
+.logo-list {
+ display: flex;
+ flex-wrap: wrap;
+ flex-direction: row;
+ justify-content: center;
+ align-items: center;
+ gap: 1em;
+}
+
+@media (max-width: 45em) {
+ .logo-list {
+ gap: 1.5em;
+ }
+}
+
+@media (max-width: 65em) {
+ .logo-list {
+ justify-content: space-around;
+ align-content: flex-start;
+ grid-column: 6 / 15;
+ }
+}
+
+.logo-list img {
+ opacity: 0.5;
+ height: 3em;
+ margin: 0 0.5em;
+}
+
+/* -- Tagline/CTA
+-------------------------------------------------------------------- */
+
+@supports (display: grid) {
+ @media (min-width: 45em) {
+ #content > .tagline {
+ grid-column: 6 / 12;
+ } /* 6 cols */
+ } /* end @media (min-width: 45em) */
+} /* end @supports (display: grid) */
+
+/* -- Email signup
+-------------------------------------------------------------------- */
+
+.email-signup form {
+ border-top: var(--border-line);
+}
+
+@supports (display: flex) {
+ .email-signup form {
+ display: flex;
+ flex-direction: column;
+ flex-wrap: wrap;
+ justify-content: center;
+ align-content: center;
+ align-items: center;
+ }
+
+ .email-signup h2,
+ .email-signup label {
+ text-align: center;
+ }
+
+ .email-signup label {
+ margin-bottom: 0.5em;
+ }
+
+ .email-signup .fields {
+ display: flex;
+ flex-direction: column;
+ flex-wrap: wrap;
+ justify-content: flex-start;
+ align-content: stretch;
+ align-items: center;
+ gap: 0.5em;
+ }
+
+ @media (min-width: 40em) {
+ .email-signup .fields {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ justify-content: center;
+ align-content: stretch;
+ align-items: center;
+ }
+
+ .email-signup .fields input[type='email'] {
+ flex: 1 1 auto;
+ }
+ }
+
+ @media (min-width: 60em) {
+ .email-signup form {
+ flex-direction: row;
+ align-items: stretch;
+ justify-content: flex-end;
+ padding: 1em 0;
+ }
+
+ .email-signup h2,
+ .email-signup label,
+ .email-signup .fields {
+ text-align: left;
+ flex: 0 1 50%;
+ }
+
+ .email-signup h2 {
+ margin-bottom: 0.5em;
+ }
+
+ .email-signup label {
+ margin-top: 1.2em;
+ }
+ }
+} /* end @supports (display: flex) */
+
+/* -- Footer
+-------------------------------------------------------------------- */
+
+[data-edge-source='make-your-code-do-more'] {
+ padding: 0.5em 1em;
+}
+
+.site-footer {
+ margin: 0 auto;
+ padding: 0 1.35em;
+}
+
+ul.footer-list {
+ /* requires ul for specificity */
+ border-top: var(--border-line);
+ margin: 1.35em 0;
+ padding-top: 1.5em;
+}
+
+.footer-list li {
+ border-bottom: var(--border-line);
+}
+
+.footer-list li:last-of-type {
+ border-bottom: none;
+}
+
+.footer-list a {
+ color: var(--text-footer);
+ display: block;
+ font-size: var(--font-xsmall);
+ padding: 1.3em;
+ text-align: center;
+ text-decoration: none;
+}
+
+.footer-list a:hover,
+.footer-list a:focus,
+.footer-list a:active {
+ text-decoration: underline;
+}
+
+@supports (display: flex) {
+ .site-footer {
+ padding: 0;
+ }
+
+ @media (min-width: 45em) {
+ ul.footer-list {
+ display: flex;
+ flex-direction: row;
+ flex-wrap: nowrap;
+ justify-content: center;
+ align-content: stretch;
+ align-items: flex-start;
+ margin-bottom: 2.7em;
+ padding-top: 0;
+ }
+
+ .footer-list li {
+ border-bottom: none;
+ }
+
+ .footer-list li a {
+ border-right: var(--border-line);
+ padding-bottom: 0;
+ }
+
+ .footer-list li:last-of-type a {
+ border-right: none;
+ }
+ } /* @media (min-width: 45em)*/
+} /* end @supports (display:flex) */
+
+.copyright {
+ font-size: var(--font-xsmall);
+ letter-spacing: var(--spacing-looser);
+ text-align: center;
+ text-transform: uppercase;
+}
+
+@media (min-width: 45em) {
+ .copyright {
+ margin-bottom: 2.7em;
+ }
+}
+
+/* -- Privacy page
+-------------------------------------------------------------------- */
+
+.last-updated {
+ margin: 0.8em 0 5em;
+ text-align: center;
+}
+
+.privacy-section {
+ border-bottom: var(--border-line);
+ padding: 2.7em 0 0.675em;
+ margin: 0 auto;
+ max-width: 34.5em;
+}
+
+.privacy-section:last-of-type {
+ border-bottom: none;
+}
+
+.privacy-section h2 {
+ margin-top: 0;
+}
+
+/* -- Edges
+-------------------------------------------------------------------- */
+path.edge {
+ stroke: #fff4;
+}
+
+/* -- Pricing page (copied from the React code Billing page)
+-------------------------------------------------------------------- */
+
+.pricing-arrow {
+ display: none;
+}
+
+@media (min-width: 1280px) {
+ .pricing-grid {
+ display: grid;
+ grid-gap: 0;
+ grid-template-columns: repeat(3, 33%);
+ margin-top: 3rem;
+ grid-template-areas:
+ 'community professional team '
+ 'enterprise enterprise enterprise'
+ 'services services services';
+ }
+
+ .pricing-arrow {
+ display: block;
+ }
+
+ .tier-wrapper.community {
+ grid-area: community;
+ }
+ .tier-wrapper.professional {
+ grid-area: professional;
+ }
+ .tier-wrapper.enterprise {
+ grid-area: enterprise;
+ }
+ .tier-wrapper.services {
+ grid-area: services;
+ }
+}
+
+.tier-header {
+ border-bottom: 1px solid rgba(255, 255, 255, 0.11);
+ margin-bottom: 1.5rem;
+ height: 15rem;
+ display: grid;
+ grid-template-rows: auto 1fr auto;
+}
+
+.badge {
+ background-color: #db4206;
+ border-radius: 0.3rem;
+ color: white;
+ font-size: 0.6em;
+ font-weight: 400;
+ margin-top: 0.1rem;
+ margin-left: 0.5rem;
+ padding: 0.35rem 0.4rem;
+ text-transform: uppercase;
+}
+
+.feature-list .pricing-text {
+ padding-top: 0.5rem;
+ padding-bottom: 0.5rem;
+ font-weight: 500;
+ font-variation-settings: 'wght' 500;
+ font-size: var(--font-small);
+ margin-left: 1.5rem;
+}
+
+.feature-list .small-text {
+ color: var(--chakra-colors-gray-200);
+ font-size: var(--font-xsmall);
+}
+
+.pricing-text a:hover .small-text,
+.pricing-text a:active .small-text,
+.pricing-text a:focus .small-text {
+ color: var(--text-link);
+}
+
+.feature-list > li::before {
+ content: '→';
+ display: block;
+ position: absolute;
+ right: 100%;
+ width: 1rem;
+ margin-right: 0.5rem;
+}
+
+.horizontal {
+ display: flex;
+ justify-content: start;
+ -webkit-box-align: center;
+ align-items: center;
+ flex-flow: row wrap;
+}
+
+.tier-wrapper {
+ display: flex;
+ position: relative;
+ margin-bottom: 1rem;
+}
+
+.tier {
+ border: 1px solid rgba(255, 255, 255, 0.08);
+ border-radius: 0.25rem;
+ width: 100%;
+ background: var(--chakra-colors-gray-850);
+ padding-inline-start: 1.5rem;
+ padding-inline-end: 1.5rem;
+ padding-bottom: 2rem;
+}
+
+.tier.professional {
+ background: var(--chakra-colors-gray-700);
+}
+
+.tier.professional .pricing-text, .tier.team .pricing-text {
+ color: white;
+}
+
+.pricing-text strong {
+ font-variation-settings: 'wght' 700;
+}
+
+.tier.enterprise {
+ /* padding copied from H2 */
+ padding-top: 0.83em;
+ padding-bottom: 0.83em;
+ border: 1px solid rgba(255, 255, 255, 0.08);
+ border-radius: 0.75rem;
+ width: 100%;
+ background: var(--chakra-colors-gray-800);
+ padding-inline-start: 2rem;
+ padding-inline-end: 2rem;
+}
+
+.enterprise h2 {
+ margin-top: 0;
+}
+
+.tier.services, .tier.enterprise {
+ margin-top: 1rem;
+}
+
+.sign-up-button {
+ font-size: 1rem;
+ margin-top: 1rem;
+ margin-bottom: 1rem;
+ max-width: 25rem;
+}
+
+.pricing-heading {
+ line-height: 1.2;
+ color: white;
+ font-variation-settings: 'wght' 700;
+}
+
+h1.pricing-heading {
+ font-size: var(--font-xxl);
+ margin-bottom: 1rem;
+ margin-left: 2rem;
+ text-align: left;
+}
+
+h2.pricing-heading {
+ font-size: var(--font-large);
+}
+
+.pricing-text,
+.pricing-text a {
+ color: var(--chakra-colors-gray-50);
+ font-variation-settings: 'wght' 450;
+}
+
+.pricing-text.details {
+ font-size: var(--font-xxsmall);
+ color: var(--chakra-colors-gray-200) !important;
+ margin-top: 0.5rem;
+ font-variation-settings: 'wght' 200;
+ margin-left: 1rem;
+ max-width: 19ch;
+}
+
+.pricing-text .details-bold {
+ font-size: var(--font-small);
+ color: white;
+ display: block;
+ font-variation-settings: 'wght' 500;
+}
+
+.pricing-text.description {
+ color: var(--chakra-colors-gray-200);
+ max-width: 768px;
+ margin-left: 2rem;
+ margin-bottom: 4rem;
+}
+
+.pricing-text a {
+ color: white;
+ text-decoration: none;
+}
+
+.pricing-text a:hover,
+.pricing-text a:active,
+.pricing-text a:focus {
+ color: var(--text-link);
+ text-decoration: underline;
+}
+
+.price-number {
+ font-weight: 700;
+ font-variation-settings: 'wght' 700;
+ font-size: var(--font-xxl);
+ margin: 0;
+ /* hack for now to make community same height as professional with the detail text
+ since they are just slightly off otherwise?
+ */
+ min-height: 71px;
+}
+
+@media (min-width: 1280px) {
+ .tier.services, .tier.enterprise {
+ display: flex;
+ flex-wrap: wrap;
+ padding-bottom: 0;
+ }
+
+ .tier.services .tier-header, .tier.enterprise .tier-header {
+ border-bottom: none;
+ flex-basis: calc(33% - 0.5rem);
+ padding-right: 1.5rem;
+ }
+
+ .tier.services .feature-list, .tier.enterprise .feature-list {
+ border-left: 1px solid rgba(255, 255, 255, 0.11);
+ padding: 1rem 1.5rem;
+ }
+}
+
+.details-wrapper {
+ margin-top: 0px;
+ margin-inline: 0.5rem 0px;
+ margin-bottom: 0px;
+}
+
+.pricing-arrow {
+ margin-top: 2rem;
+ color: var(--chakra-colors-gray-600);
+ width: 38px;
+}
+
+.pricing-section {
+ margin-bottom: 8rem;
+}
+
+.pink {
+ color: #cf249b;
+}
diff --git a/fumadocs/content/docs/assets/landing-page/xstate-logo.svg b/fumadocs/content/docs/assets/landing-page/xstate-logo.svg
new file mode 100644
index 000000000..f04d845a6
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing-page/xstate-logo.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/landing/ai-generation.png b/fumadocs/content/docs/assets/landing/ai-generation.png
new file mode 100644
index 000000000..185f72fbb
Binary files /dev/null and b/fumadocs/content/docs/assets/landing/ai-generation.png differ
diff --git a/fumadocs/content/docs/assets/landing/assets-colorpicker.png b/fumadocs/content/docs/assets/landing/assets-colorpicker.png
new file mode 100644
index 000000000..f2c8bc762
Binary files /dev/null and b/fumadocs/content/docs/assets/landing/assets-colorpicker.png differ
diff --git a/fumadocs/content/docs/assets/landing/deploy-to-sky-button.png b/fumadocs/content/docs/assets/landing/deploy-to-sky-button.png
new file mode 100644
index 000000000..13736fcf5
Binary files /dev/null and b/fumadocs/content/docs/assets/landing/deploy-to-sky-button.png differ
diff --git a/fumadocs/content/docs/assets/landing/deploy-to-sky.png b/fumadocs/content/docs/assets/landing/deploy-to-sky.png
new file mode 100644
index 000000000..1dc931890
Binary files /dev/null and b/fumadocs/content/docs/assets/landing/deploy-to-sky.png differ
diff --git a/fumadocs/content/docs/assets/landing/design-and-simulate.png b/fumadocs/content/docs/assets/landing/design-and-simulate.png
new file mode 100644
index 000000000..a832d6751
Binary files /dev/null and b/fumadocs/content/docs/assets/landing/design-and-simulate.png differ
diff --git a/fumadocs/content/docs/assets/landing/discord-mark-white.svg b/fumadocs/content/docs/assets/landing/discord-mark-white.svg
new file mode 100644
index 000000000..7f9a31f02
--- /dev/null
+++ b/fumadocs/content/docs/assets/landing/discord-mark-white.svg
@@ -0,0 +1 @@
+Stately logged out log in idle active logged in log out
+
diff --git a/fumadocs/content/docs/assets/logo-white-nobg.svg b/fumadocs/content/docs/assets/logo-white-nobg.svg
new file mode 100644
index 000000000..27e9b1192
--- /dev/null
+++ b/fumadocs/content/docs/assets/logo-white-nobg.svg
@@ -0,0 +1,3 @@
+
+
diff --git a/fumadocs/content/docs/assets/manifest.webmanifest b/fumadocs/content/docs/assets/manifest.webmanifest
new file mode 100644
index 000000000..5ff8ac9df
--- /dev/null
+++ b/fumadocs/content/docs/assets/manifest.webmanifest
@@ -0,0 +1,6 @@
+{
+ "icons": [
+ { "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" },
+ { "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" }
+ ]
+}
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/parallel-states.svg b/fumadocs/content/docs/assets/parallel-states.svg
new file mode 100644
index 000000000..49dbc4c3d
--- /dev/null
+++ b/fumadocs/content/docs/assets/parallel-states.svg
@@ -0,0 +1 @@
+waiting walk complete leave home arrive home on a walk activities tail walking running stopping to sniff good smells stop slow down sudden speed up speed up not wagging wagging wagging starts wagging stops sudden stop speed up waiting walk complete leave home arrive home on a walk walking running stopping to sniff good smells stop slow down sudden speed up speed up sudden stop speed up Stately | Pricing
+
+
+
Pricing
+
+ Create unlimited public projects for free. Upgrade to work privately
+ and unlock more features. Get a team to add users and enable
+ collaboration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Everything from the Community, Pro, and Team plans
+
+
+
+ Unlimited generated flows
+
+ Flexible hosting
+ Dedicated priority support
+ Custom server locations
+ Single sign-on (SSO)
+ Audit logs
+ Embed Stately into your own apps
+
+ Custom effect collections (actions, actors, and more)
+
+ Custom export formats
+ Prioritized feature requests
+
+ A custom plan tailored to the requirements of your
+ organization
+
+
+
+
+
+
+
+
+
+ Consultancy on state management and/or using XState in your
+ team
+
+ Workshops for XState
+
+ Custom solutions for state machine logic and model-based
+ testing
+
+ Priority support
+
+
+
+
+
+
+
+
+
+
+
diff --git a/fumadocs/content/docs/assets/projects-dm.png b/fumadocs/content/docs/assets/projects-dm.png
new file mode 100644
index 000000000..83dd63ec3
Binary files /dev/null and b/fumadocs/content/docs/assets/projects-dm.png differ
diff --git a/fumadocs/content/docs/assets/projects.png b/fumadocs/content/docs/assets/projects.png
new file mode 100644
index 000000000..6bd3f6d11
Binary files /dev/null and b/fumadocs/content/docs/assets/projects.png differ
diff --git a/fumadocs/content/docs/assets/projects/machines-list-dm.png b/fumadocs/content/docs/assets/projects/machines-list-dm.png
new file mode 100644
index 000000000..d64a21ae2
Binary files /dev/null and b/fumadocs/content/docs/assets/projects/machines-list-dm.png differ
diff --git a/fumadocs/content/docs/assets/projects/machines-list.png b/fumadocs/content/docs/assets/projects/machines-list.png
new file mode 100644
index 000000000..afda04e07
Binary files /dev/null and b/fumadocs/content/docs/assets/projects/machines-list.png differ
diff --git a/fumadocs/content/docs/assets/projects/my-projects-dm.png b/fumadocs/content/docs/assets/projects/my-projects-dm.png
new file mode 100644
index 000000000..2f7f4b2b7
Binary files /dev/null and b/fumadocs/content/docs/assets/projects/my-projects-dm.png differ
diff --git a/fumadocs/content/docs/assets/projects/my-projects.png b/fumadocs/content/docs/assets/projects/my-projects.png
new file mode 100644
index 000000000..b317f3a36
Binary files /dev/null and b/fumadocs/content/docs/assets/projects/my-projects.png differ
diff --git a/fumadocs/content/docs/assets/recovery_offline_error.gif b/fumadocs/content/docs/assets/recovery_offline_error.gif
new file mode 100644
index 000000000..e6a39e690
Binary files /dev/null and b/fumadocs/content/docs/assets/recovery_offline_error.gif differ
diff --git a/fumadocs/content/docs/assets/recovery_restore_machine.gif b/fumadocs/content/docs/assets/recovery_restore_machine.gif
new file mode 100644
index 000000000..5483a2668
Binary files /dev/null and b/fumadocs/content/docs/assets/recovery_restore_machine.gif differ
diff --git a/fumadocs/content/docs/assets/reset-canvas.png b/fumadocs/content/docs/assets/reset-canvas.png
new file mode 100644
index 000000000..a7190c598
Binary files /dev/null and b/fumadocs/content/docs/assets/reset-canvas.png differ
diff --git a/fumadocs/content/docs/assets/reset.png b/fumadocs/content/docs/assets/reset.png
new file mode 100644
index 000000000..f5e067c5a
Binary files /dev/null and b/fumadocs/content/docs/assets/reset.png differ
diff --git a/fumadocs/content/docs/assets/self-transition.svg b/fumadocs/content/docs/assets/self-transition.svg
new file mode 100644
index 000000000..3c8547a0c
--- /dev/null
+++ b/fumadocs/content/docs/assets/self-transition.svg
@@ -0,0 +1 @@
+begging gets treat
+ Stately
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/studio-dm.png b/fumadocs/content/docs/assets/studio-dm.png
new file mode 100644
index 000000000..203041b4f
Binary files /dev/null and b/fumadocs/content/docs/assets/studio-dm.png differ
diff --git a/fumadocs/content/docs/assets/studio.png b/fumadocs/content/docs/assets/studio.png
new file mode 100644
index 000000000..02d0fa60f
Binary files /dev/null and b/fumadocs/content/docs/assets/studio.png differ
diff --git a/fumadocs/content/docs/assets/studio_architecture_challenges.png b/fumadocs/content/docs/assets/studio_architecture_challenges.png
new file mode 100644
index 000000000..2f6568dba
Binary files /dev/null and b/fumadocs/content/docs/assets/studio_architecture_challenges.png differ
diff --git a/fumadocs/content/docs/assets/swagger-auth.gif b/fumadocs/content/docs/assets/swagger-auth.gif
new file mode 100644
index 000000000..ef60ce537
Binary files /dev/null and b/fumadocs/content/docs/assets/swagger-auth.gif differ
diff --git a/fumadocs/content/docs/assets/syntax-error.png b/fumadocs/content/docs/assets/syntax-error.png
new file mode 100644
index 000000000..d173ca9c5
Binary files /dev/null and b/fumadocs/content/docs/assets/syntax-error.png differ
diff --git a/fumadocs/content/docs/assets/teams-dm.png b/fumadocs/content/docs/assets/teams-dm.png
new file mode 100644
index 000000000..096332e56
Binary files /dev/null and b/fumadocs/content/docs/assets/teams-dm.png differ
diff --git a/fumadocs/content/docs/assets/teams.png b/fumadocs/content/docs/assets/teams.png
new file mode 100644
index 000000000..29244e31d
Binary files /dev/null and b/fumadocs/content/docs/assets/teams.png differ
diff --git a/fumadocs/content/docs/assets/theme-all-hallows-eve.png b/fumadocs/content/docs/assets/theme-all-hallows-eve.png
new file mode 100644
index 000000000..46f42ebd0
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-all-hallows-eve.png differ
diff --git a/fumadocs/content/docs/assets/theme-amy.png b/fumadocs/content/docs/assets/theme-amy.png
new file mode 100644
index 000000000..32dd08145
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-amy.png differ
diff --git a/fumadocs/content/docs/assets/theme-atom-one-dark.png b/fumadocs/content/docs/assets/theme-atom-one-dark.png
new file mode 100644
index 000000000..afae1dcef
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-atom-one-dark.png differ
diff --git a/fumadocs/content/docs/assets/theme-blackboard.png b/fumadocs/content/docs/assets/theme-blackboard.png
new file mode 100644
index 000000000..171d79f16
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-blackboard.png differ
diff --git a/fumadocs/content/docs/assets/theme-cobalt.png b/fumadocs/content/docs/assets/theme-cobalt.png
new file mode 100644
index 000000000..dddd13a1e
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-cobalt.png differ
diff --git a/fumadocs/content/docs/assets/theme-garden-of-atlantis.png b/fumadocs/content/docs/assets/theme-garden-of-atlantis.png
new file mode 100644
index 000000000..be5c54348
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-garden-of-atlantis.png differ
diff --git a/fumadocs/content/docs/assets/theme-martian-night.png b/fumadocs/content/docs/assets/theme-martian-night.png
new file mode 100644
index 000000000..038ec0e2d
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-martian-night.png differ
diff --git a/fumadocs/content/docs/assets/theme-merbivore-soft.png b/fumadocs/content/docs/assets/theme-merbivore-soft.png
new file mode 100644
index 000000000..df11d149f
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-merbivore-soft.png differ
diff --git a/fumadocs/content/docs/assets/theme-monokai.png b/fumadocs/content/docs/assets/theme-monokai.png
new file mode 100644
index 000000000..024f0a7f2
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-monokai.png differ
diff --git a/fumadocs/content/docs/assets/theme-night-owl.png b/fumadocs/content/docs/assets/theme-night-owl.png
new file mode 100644
index 000000000..4ebe6019b
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-night-owl.png differ
diff --git a/fumadocs/content/docs/assets/theme-poimandres.png b/fumadocs/content/docs/assets/theme-poimandres.png
new file mode 100644
index 000000000..51e51e775
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-poimandres.png differ
diff --git a/fumadocs/content/docs/assets/theme-tomorrow-night.png b/fumadocs/content/docs/assets/theme-tomorrow-night.png
new file mode 100644
index 000000000..7e42972e1
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-tomorrow-night.png differ
diff --git a/fumadocs/content/docs/assets/theme-xstate-viz.png b/fumadocs/content/docs/assets/theme-xstate-viz.png
new file mode 100644
index 000000000..d076d6c2a
Binary files /dev/null and b/fumadocs/content/docs/assets/theme-xstate-viz.png differ
diff --git a/fumadocs/content/docs/assets/tools/visualizer/visualizer.png b/fumadocs/content/docs/assets/tools/visualizer/visualizer.png
new file mode 100644
index 000000000..21b22d226
Binary files /dev/null and b/fumadocs/content/docs/assets/tools/visualizer/visualizer.png differ
diff --git a/fumadocs/content/docs/assets/transition-error.png b/fumadocs/content/docs/assets/transition-error.png
new file mode 100644
index 000000000..4eaef0107
Binary files /dev/null and b/fumadocs/content/docs/assets/transition-error.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/delayed-transitions/delayed-transitions-dm.png b/fumadocs/content/docs/assets/transitions-and-events/delayed-transitions/delayed-transitions-dm.png
new file mode 100644
index 000000000..f69ff2b08
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/delayed-transitions/delayed-transitions-dm.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/delayed-transitions/delayed-transitions.png b/fumadocs/content/docs/assets/transitions-and-events/delayed-transitions/delayed-transitions.png
new file mode 100644
index 000000000..1710d98df
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/delayed-transitions/delayed-transitions.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/guards/guards-dm.png b/fumadocs/content/docs/assets/transitions-and-events/guards/guards-dm.png
new file mode 100644
index 000000000..a58941c70
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/guards/guards-dm.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/guards/guards.png b/fumadocs/content/docs/assets/transitions-and-events/guards/guards.png
new file mode 100644
index 000000000..8b20e64e6
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/guards/guards.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/intro/transitions-and-events-dm.png b/fumadocs/content/docs/assets/transitions-and-events/intro/transitions-and-events-dm.png
new file mode 100644
index 000000000..4e0896318
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/intro/transitions-and-events-dm.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/intro/transitions-and-events.png b/fumadocs/content/docs/assets/transitions-and-events/intro/transitions-and-events.png
new file mode 100644
index 000000000..8cf4f9f37
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/intro/transitions-and-events.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/state-done-events/state-done-events-dm.png b/fumadocs/content/docs/assets/transitions-and-events/state-done-events/state-done-events-dm.png
new file mode 100644
index 000000000..933e7b083
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/state-done-events/state-done-events-dm.png differ
diff --git a/fumadocs/content/docs/assets/transitions-and-events/state-done-events/state-done-events.png b/fumadocs/content/docs/assets/transitions-and-events/state-done-events/state-done-events.png
new file mode 100644
index 000000000..740328736
Binary files /dev/null and b/fumadocs/content/docs/assets/transitions-and-events/state-done-events/state-done-events.png differ
diff --git a/fumadocs/content/docs/assets/transitions-events.svg b/fumadocs/content/docs/assets/transitions-events.svg
new file mode 100644
index 000000000..a030d784e
--- /dev/null
+++ b/fumadocs/content/docs/assets/transitions-events.svg
@@ -0,0 +1 @@
+awake asleep wakes up falls asleep
+ XState
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/xstate-logo-white-nobg.svg b/fumadocs/content/docs/assets/xstate-logo-white-nobg.svg
new file mode 100644
index 000000000..56179ad76
--- /dev/null
+++ b/fumadocs/content/docs/assets/xstate-logo-white-nobg.svg
@@ -0,0 +1,10 @@
+
+
+ XState
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/xstate-logo.svg b/fumadocs/content/docs/assets/xstate-logo.svg
new file mode 100644
index 000000000..f04d845a6
--- /dev/null
+++ b/fumadocs/content/docs/assets/xstate-logo.svg
@@ -0,0 +1,29 @@
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/fumadocs/content/docs/assets/zoom-in.png b/fumadocs/content/docs/assets/zoom-in.png
new file mode 100644
index 000000000..47c5753f3
Binary files /dev/null and b/fumadocs/content/docs/assets/zoom-in.png differ
diff --git a/fumadocs/content/docs/assets/zoom-out.png b/fumadocs/content/docs/assets/zoom-out.png
new file mode 100644
index 000000000..5a4b3c34f
Binary files /dev/null and b/fumadocs/content/docs/assets/zoom-out.png differ
diff --git a/fumadocs/content/docs/autolayout.mdx b/fumadocs/content/docs/autolayout.mdx
new file mode 100644
index 000000000..95152c568
--- /dev/null
+++ b/fumadocs/content/docs/autolayout.mdx
@@ -0,0 +1,22 @@
+---
+title: Autolayout
+---
+
+import { Wand } from 'lucide-react';
+
+Autolayout chooses an optimal layout for your machine to make it easier to read and understand. When you import a machine, autolayout will be applied automatically. Otherwise, you can autolayout your machine anytime using the (
+ ({
+ sendBack,
+ receive,
+ input, // Typed as { defaultSize: number }
+ }) => {
+ input.defaultSize; // 100
+ // ...
+ },
+);
+
+const machine = setup({
+ actors: {
+ resizeLogic,
+ },
+}).createMachine({
+ // ...
+ invoke: {
+ src: 'resizeLogic',
+ input: {
+ defaultSize: 100,
+ },
+ },
+});
+```
diff --git a/fumadocs/content/docs/canvas-view-controls.mdx b/fumadocs/content/docs/canvas-view-controls.mdx
new file mode 100644
index 000000000..2476955d6
--- /dev/null
+++ b/fumadocs/content/docs/canvas-view-controls.mdx
@@ -0,0 +1,92 @@
+---
+title: Canvas controls
+---
+
+import { Sparkles, MousePointer2, Hand, PlusSquare, Undo, Redo, Scan, Check, ListTree } from 'lucide-react';
+
+We’ve recently added a canvas tools panel to help you with common tasks while designing and simulating state machines.
+
+-
+
*/}
+
+
+
+## View controls
+
+You spend a lot of time on the canvas while designing and simulating state machines, so we’ve added view controls to help you navigate around your machines.
+
+## Show/hide UI (user interface)
+
+You can show and hide most of the editor’s user interface to help you focus on your machine.
+
+1. Open the editor menu from the Stately icon in the top left of Stately Studio.
+2. From the **View** submenu, toggle Command /Ctrl + . keyboard shortcut to show and hide the UI.
+
+
+
+We’ve got [keyboard shortcuts](keyboard-shortcuts) for many of the view controls.
+
+
+
+Below is a preview of a machine _with_ the UI hidden.
+
+{/*
+
*/}
+
+
+
+Below is a preview of a machine _without_ the UI hidden.
+
+{/*
+
*/}
+
+
+
+
+## View controls
+
+-
+
+[Find out more about light mode, dark mode, and translucency in user preferences](user-preferences).
+
+
+
+## Zoom to selection
+
+You can use **Zoom to selection** from right-click on any transition or state on the canvas or in the
+
+
+```bash
+npm install xstate
+```
+
+
+
+
+
+```bash
+pnpm install xstate
+```
+
+
+
+
+
+```bash
+yarn add xstate
+```
+
+
+
+
+[Read more on installing XState](installation).
+
+## Creating a state machine
+
+```ts
+import { setup, createActor, assign } from 'xstate';
+
+const machine = setup({
+ /* ... */
+}).createMachine({
+ id: 'toggle',
+ initial: 'active',
+ context: { count: 0 },
+ states: {
+ active: {
+ entry: assign({
+ count: ({ context }) => context.count + 1,
+ }),
+ on: {
+ toggle: { target: 'inactive' },
+ },
+ },
+ inactive: {
+ on: {
+ toggle: { target: 'active' },
+ },
+ },
+ },
+});
+
+const actor = createActor(machine);
+actor.subscribe((snapshot) => {
+ console.log(snapshot.value);
+});
+
+actor.start();
+// logs 'active' with context { count: 1 }
+
+actor.send({ type: 'toggle' });
+// logs 'inactive' with context { count: 1 }
+actor.send({ type: 'toggle' });
+// logs 'active' with context { count: 2 }
+actor.send({ type: 'toggle' });
+// logs 'inactive' with context { count: 2 }
+```
+
+[Read more about the actor model](actor-model).
+
+## Creating promise logic
+
+```ts
+import { fromPromise, createActor } from 'xstate';
+
+const promiseLogic = fromPromise(async () => {
+ const response = await fetch('https://dog.ceo/api/breeds/image/random');
+ const dog = await response.json();
+ return dog;
+});
+
+const actor = createActor(promiseLogic);
+
+actor.subscribe((snapshot) => {
+ console.log(snapshot);
+});
+
+actor.start();
+// logs: {
+// message: "https://images.dog.ceo/breeds/kuvasz/n02104029_110.jpg",
+// status: "success"
+// }
+```
+
+[Read more about promise actor logic](/docs/actors#actors-as-promises).
+
+## Creating transition logic
+
+A transition function is just like a reducer.
+
+```ts
+import { fromTransition, createActor } from 'xstate';
+
+const transitionLogic = fromTransition(
+ (state, event) => {
+ switch (event.type) {
+ case 'inc':
+ return {
+ ...state,
+ count: state.count + 1,
+ };
+ default:
+ return state;
+ }
+ },
+ { count: 0 }, // initial state
+);
+
+const actor = createActor(transitionLogic);
+
+actor.subscribe((snapshot) => {
+ console.log(snapshot);
+});
+
+actor.start();
+// logs { count: 0 }
+
+actor.send({ type: 'inc' });
+// logs { count: 1 }
+actor.send({ type: 'inc' });
+// logs { count: 2 }
+```
+
+[Read more about transition actors](/docs/actors#fromtransition).
+
+## Creating observable logic
+
+```ts
+import { fromObservable, createActor } from 'xstate';
+import { interval } from 'rxjs';
+
+const observableLogic = fromObservable(() => interval(1000));
+
+const actor = createActor(observableLogic);
+
+actor.subscribe((snapshot) => {
+ console.log(snapshot);
+});
+
+actor.start();
+// logs 0, 1, 2, 3, 4, 5, ...
+// every second
+```
+
+[Read more about observable actors](/docs/actors#fromobservable).
+
+## Creating callback logic
+
+```ts
+import { fromCallback, createActor } from 'xstate';
+
+const callbackLogic = fromCallback(({ sendBack, receive }) => {
+ const i = setTimeout(() => {
+ sendBack({ type: 'timeout' });
+ }, 1000);
+
+ receive((event) => {
+ if (event.type === 'cancel') {
+ console.log('canceled');
+ clearTimeout(i);
+ }
+ });
+
+ return () => {
+ clearTimeout(i);
+ };
+});
+
+const actor = createActor(callbackLogic);
+
+actor.start();
+
+actor.send({ type: 'cancel' });
+// logs 'canceled'
+```
+
+[Read more about callback actors](/docs/actors#fromcallback).
+
+## Parent states
+
+```ts
+import { setup, createActor } from 'xstate';
+
+const machine = setup({
+ /* ... */
+}).createMachine({
+ id: 'parent',
+ initial: 'active',
+ states: {
+ active: {
+ initial: 'one',
+ states: {
+ one: {
+ on: {
+ NEXT: { target: 'two' },
+ },
+ },
+ two: {},
+ },
+ on: {
+ NEXT: { target: 'inactive' },
+ },
+ },
+ inactive: {},
+ },
+});
+
+const actor = createActor(machine);
+
+actor.subscribe((snapshot) => {
+ console.log(snapshot.value);
+});
+
+actor.start();
+// logs { active: 'one' }
+
+actor.send({ type: 'NEXT' });
+// logs { active: 'two' }
+
+actor.send({ type: 'NEXT' });
+// logs 'inactive'
+```
+
+[Read more about parent states](parent-states).
+
+## Actions
+
+```ts
+import { setup, createActor } from 'xstate';
+
+const machine = setup({
+ actions: {
+ activate: () => {
+ /* ... */
+ },
+ deactivate: () => {
+ /* ... */
+ },
+ notify: (_, params: { message: string }) => {
+ /* ... */
+ },
+ },
+}).createMachine({
+ id: 'toggle',
+ initial: 'active',
+ states: {
+ active: {
+ // [!code highlight:1]
+ entry: { type: 'activate' },
+ // [!code highlight:1]
+ exit: { type: 'deactivate' },
+ on: {
+ toggle: {
+ target: 'inactive',
+ // [!code highlight:1]
+ actions: [{ type: 'notify' }],
+ },
+ },
+ },
+ inactive: {
+ on: {
+ toggle: {
+ target: 'active',
+ // [!code highlight:9]
+ actions: [
+ // action with params
+ {
+ type: 'notify',
+ params: {
+ message: 'Some notification',
+ },
+ },
+ ],
+ },
+ },
+ },
+ },
+});
+
+const actor = createActor(
+ machine.provide({
+ actions: {
+ notify: (_, params) => {
+ console.log(params.message ?? 'Default message');
+ },
+ activate: () => {
+ console.log('Activating');
+ },
+ deactivate: () => {
+ console.log('Deactivating');
+ },
+ },
+ }),
+);
+
+actor.start();
+// logs 'Activating'
+
+actor.send({ type: 'toggle' });
+// logs 'Deactivating'
+// logs 'Default message'
+
+actor.send({ type: 'toggle' });
+// logs 'Some notification'
+// logs 'Activating'
+```
+
+[Read more about actions](actions).
+
+## Guards
+
+```ts
+import { setup, createActor } from 'xstate';
+
+const machine = setup({
+ // [!code highlight:9]
+ guards: {
+ canBeToggled: ({ context }) => context.canActivate,
+ isAfterTime: (_, params) => {
+ const { time } = params;
+ const [hour, minute] = time.split(':');
+ const now = new Date();
+ return now.getHours() > hour && now.getMinutes() > minute;
+ },
+ },
+ actions: {
+ notifyNotAllowed: () => {
+ console.log('Cannot be toggled');
+ },
+ },
+}).createMachine({
+ id: 'toggle',
+ initial: 'active',
+ context: {
+ canActivate: false,
+ },
+ states: {
+ inactive: {
+ on: {
+ toggle: [
+ {
+ target: 'active',
+ // [!code highlight:1]
+ guard: 'canBeToggled',
+ },
+ {
+ actions: 'notifyNotAllowed',
+ },
+ ],
+ },
+ },
+ active: {
+ on: {
+ toggle: {
+ // Guard with params
+ // [!code highlight:1]
+ guard: { type: 'isAfterTime', params: { time: '16:00' } },
+ target: 'inactive',
+ },
+ },
+ // ...
+ },
+ },
+});
+
+const actor = createActor(machine);
+
+actor.start();
+// logs 'Cannot be toggled'
+```
+
+[Read more about guards](guards).
+
+## Invoking actors
+
+```ts
+import { setup, fromPromise, createActor, assign } from 'xstate';
+
+const loadUserLogic = fromPromise(async () => {
+ const response = await fetch('https://jsonplaceholder.typicode.com/users/1');
+ const user = await response.json();
+ return user;
+});
+
+const machine = setup({
+ // [!code highlight:1]
+ actors: { loadUserLogic },
+}).createMachine({
+ id: 'toggle',
+ initial: 'loading',
+ context: {
+ user: undefined,
+ },
+ states: {
+ loading: {
+ // [!code highlight:16]
+ invoke: {
+ id: 'loadUser',
+ src: 'loadUserLogic',
+ onDone: {
+ target: 'doSomethingWithUser',
+ actions: assign({
+ user: ({ event }) => event.output,
+ }),
+ },
+ onError: {
+ target: 'failure',
+ actions: ({ event }) => {
+ console.log(event.error);
+ },
+ },
+ },
+ },
+ doSomethingWithUser: {
+ // ...
+ },
+ failure: {
+ // ...
+ },
+ },
+});
+
+const actor = createActor(machine);
+
+actor.subscribe((snapshot) => {
+ console.log(snapshot.context.user);
+});
+
+actor.start();
+// eventually logs:
+// { id: 1, name: 'Leanne Graham', ... }
+```
+
+[Read more about invoking actors](invoke).
+
+## Spawning actors
+
+```ts
+import { setup, fromPromise, createActor, assign } from 'xstate';
+
+const loadUserLogic = fromPromise(async () => {
+ const response = await fetch('https://jsonplaceholder.typicode.com/users/1');
+ const user = await response.json();
+ return user;
+});
+
+const machine = setup({
+ actors: {
+ loadUserLogic,
+ },
+}).createMachine({
+ context: {
+ userRef: undefined,
+ },
+ on: {
+ loadUser: {
+ actions: assign({
+ // [!code highlight:1]
+ userRef: ({ spawn }) => spawn('loadUserLogic'),
+ }),
+ },
+ },
+});
+
+const actor = createActor(machine);
+actor.subscribe((snapshot) => {
+ const { userRef } = snapshot.context;
+ console.log(userRef?.getSnapshot());
+});
+actor.start();
+
+actor.send({ type: 'loadUser' });
+// eventually logs:
+// { id: 1, name: 'Leanne Graham', ... }
+```
+
+[Read more about spawning actors](spawn).
+
+## Input and output
+
+```ts
+import { setup, createActor } from 'xstate';
+
+const greetMachine = setup({
+ types: {
+ context: {} as { message: string },
+ input: {} as { name: string },
+ },
+}).createMachine({
+ // [!code highlight:3]
+ context: ({ input }) => ({
+ message: `Hello, ${input.name}`,
+ }),
+ entry: ({ context }) => {
+ console.log(context.message);
+ },
+});
+
+const actor = createActor(greetMachine, {
+ // [!code highlight:3]
+ input: {
+ name: 'David',
+ },
+});
+
+actor.start();
+// logs 'Hello, David'
+```
+
+[Read more about input](input).
+
+## Invoking actors with input
+
+```ts
+import { setup, createActor, fromPromise } from 'xstate';
+
+const loadUserLogic = fromPromise(async ({ input }) => {
+ const response = await fetch(
+ `https://jsonplaceholder.typicode.com/users/${input.id}`,
+ );
+ const user = await response.json();
+ return user;
+});
+
+const machine = setup({
+ actors: {
+ loadUserLogic,
+ },
+}).createMachine({
+ initial: 'loading user',
+ states: {
+ 'loading user': {
+ invoke: {
+ id: 'loadUser',
+ src: 'loadUserLogic',
+ // [!code highlight:3]
+ input: {
+ id: 3,
+ },
+ onDone: {
+ actions: ({ event }) => {
+ console.log(event.output);
+ },
+ },
+ },
+ },
+ },
+});
+
+const actor = createActor(machine);
+
+actor.start();
+// eventually logs:
+// { id: 3, name: 'Clementine Bauch', ... }
+```
+
+[Read more about invoking actors with input](input.mdx#invoking-actors-with-input).
+
+## Types
+
+```ts
+import { setup, fromPromise } from 'xstate';
+
+const promiseLogic = fromPromise(async () => {
+ /* ... */
+});
+
+const machine = setup({
+ types: {
+ context: {} as {
+ count: number;
+ };
+ events: {} as
+ | { type: 'inc'; }
+ | { type: 'dec' }
+ | { type: 'incBy'; amount: number };
+ actions: {} as
+ | { type: 'notify'; params: { message: string } }
+ | { type: 'handleChange' };
+ guards: {} as
+ | { type: 'canBeToggled' }
+ | { type: 'isAfterTime'; params: { time: string } };
+ children: {} as {
+ promise1: 'someSrc';
+ promise2: 'someSrc';
+ };
+ delays: 'shortTimeout' | 'longTimeout';
+ tags: 'tag1' | 'tag2';
+ input: number;
+ output: string;
+ },
+ actors: {
+ promiseLogic
+ }
+}).createMachine({
+ // ...
+});
+```
diff --git a/fumadocs/content/docs/colors.mdx b/fumadocs/content/docs/colors.mdx
new file mode 100644
index 000000000..efbdc6b79
--- /dev/null
+++ b/fumadocs/content/docs/colors.mdx
@@ -0,0 +1,65 @@
+---
+title: Colors
+---
+
+import { Info, Star } from 'lucide-react';
+
+You can highlight your machine’s state and event nodes with colors. You can use colors however you like; some ideas include:
+
+- Color coding groups or types of states or events
+- Emphasizing success or error states
+- Making your machines match your brand
+
+
+
+Colors are a premium feature of Stately Studio. [Check out the features on our Pro plan](studio-pro-plan), [Team plan](studio-team-plan), [Enterprise plan](studio-enterprise-plan) or [upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+
+
+A note on accessibility: not everyone perceives color the same way, and as many as 8% of men and 0.5% of women are [color blind](https://www.nei.nih.gov/learn-about-eye-health/eye-conditions-and-diseases/color-blindness). Ensure your statecharts are inclusive by using color to emphasize or decorate your machines and [do not use color as the only way to convey information](https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html).
+
+
+
+## Change the color of a state or event
+
+All states and events have a default color. In dark mode, the default color is grey. In light mode, the default color is white.
+
+When you hover over the color options, a preview of the color will be shown on the selected state or event.
+
+Colors are faded out in Simulate mode to make the current state and possible events easier to distinguish.
+
+### On the canvas
+
+1. Select the state or event whose color you want to change.
+2. Choose the circular color swatch in the center of the Edit menu to open the **Color state** or **Color event** options.
+3. Choose your desired color from the available color options.
+
+### Use the details panel
+
+1. Select the state or event whose color you want to change.
+2. Open the
+
+Do not mutate the `context` object. Instead, you should use the `assign(...)` action to update `context` immutably. If you mutate the `context` object, you may get unexpected behavior, such as mutating the `context` of other actors.
+
+
+
+### Lazy initial context
+
+Context can be initialized lazily by passing a function that returns the initial `context` value:
+
+```ts
+const feedbackMachine = createMachine({
+ context: () => ({
+ feedback: 'Some feedback',
+ createdAt: Date.now(),
+ }),
+});
+
+const feedbackActor = createActor(feedbackMachine).start();
+
+console.log(feedbackActor.getSnapshot().context.createdAt);
+// logs the current timestamp
+```
+
+Lazy initial context is evaluated per actor, so each actor will have its own `context` object.
+
+### Input
+
+You can provide input data to a machine’s initial `context` by passing an `input` property to the `createActor(machine, { input })` function and using the `input` property from the first argument in the `context` function:
+
+```ts
+import { setup, createActor } from 'xstate';
+
+const feedbackMachine = setup({
+ types: {
+ context: {} as {
+ feedback: string;
+ rating: number;
+ },
+ // [!code highlight:3]
+ input: {} as {
+ defaultRating: number;
+ },
+ },
+}).createMachine({
+ // [!code highlight:1]
+ context: ({ input }) => ({
+ feedback: '',
+ // [!code highlight:1]
+ rating: input.defaultRating,
+ }),
+});
+
+const feedbackActor = createActor(feedbackMachine, {
+ // [!code highlight:3]
+ input: {
+ defaultRating: 5,
+ },
+}).start();
+
+console.log(feedbackActor.getSnapshot().context.rating);
+// logs 5
+```
+
+Learn more about [input](input).
+
+## Updating context with `assign(...)`
+
+Use the `assign(...)` action in a transition to update context:
+
+```ts
+import { createMachine, assign, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ context: {
+ feedback: 'Some feedback',
+ },
+ on: {
+ 'feedback.update': {
+ actions: assign({
+ feedback: ({ event }) => event.feedback,
+ }),
+ },
+ },
+});
+
+const feedbackActor = createActor(feedbackMachine);
+
+feedbackActor.subscribe((state) => {
+ console.log(state.context.feedback);
+});
+
+feedbackActor.start();
+
+// logs 'Some feedback'
+
+feedbackActor.send({
+ type: 'feedback.update',
+ feedback: 'Some other feedback',
+});
+
+// logs 'Some other feedback'
+```
+
+## Context and TypeScript
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+You can strongly type the `context` of your machine in the `types.context` property of the actor setup..
+
+```ts
+import { setup } from 'xstate';
+
+const machine = setup({
+ types: {} as {
+ // [!code highlight:4]
+ context: {
+ feedback: string;
+ rating: number;
+ };
+ },
+}).createMachine({
+ // Initial context
+ context: {
+ feedback: '',
+ rating: 5,
+ },
+ entry: ({ context }) => {
+ context.feedback; // string
+ context.rating; // number
+ },
+});
+```
+
+## Context cheatsheet
+
+Use our XState context cheatsheet below to get started quickly.
+
+### Cheatsheet: initial context
+
+```ts
+const machine = createMachine({
+ context: {
+ feedback: '',
+ },
+});
+```
+
+### Cheatsheet: lazy initial context
+
+```ts
+const machine = createMachine({
+ context: () => ({
+ feedback: '',
+ createdAt: Date.now(),
+ }),
+});
+```
+
+### Cheatsheet: updating context with `assign(...)`
+
+```ts
+const machine = createMachine({
+ context: {
+ feedback: '',
+ },
+ on: {
+ 'feedback.update': {
+ actions: assign({
+ feedback: ({ event }) => event.feedback,
+ }),
+ },
+ },
+});
+```
+
+### Cheatsheet: input
+
+```ts
+import { setup, createActor } from 'xstate';
+
+const feedbackMachine = setup({
+ types: {
+ context: {} as {
+ feedback: string;
+ rating: number;
+ },
+ // [!code highlight:3]
+ input: {} as {
+ defaultRating: number;
+ },
+ },
+}).createMachine({
+ // [!code highlight:1]
+ context: ({ input }) => ({
+ feedback: '',
+ // [!code highlight:1]
+ rating: input.defaultRating,
+ }),
+});
+
+const feedbackActor = createActor(feedbackMachine, {
+ // [!code highlight:3]
+ input: {
+ defaultRating: 5,
+ },
+}).start();
+```
diff --git a/fumadocs/content/docs/core-concepts/meta.json b/fumadocs/content/docs/core-concepts/meta.json
new file mode 100644
index 000000000..f0fc3af19
--- /dev/null
+++ b/fumadocs/content/docs/core-concepts/meta.json
@@ -0,0 +1,8 @@
+{
+ "title": "Core concepts",
+ "pages": [
+ "state-machines-and-statecharts",
+ "actor-model",
+ "xstate"
+ ]
+}
diff --git a/fumadocs/content/docs/delayed-transitions.mdx b/fumadocs/content/docs/delayed-transitions.mdx
new file mode 100644
index 000000000..239e7904d
--- /dev/null
+++ b/fumadocs/content/docs/delayed-transitions.mdx
@@ -0,0 +1,197 @@
+---
+title: Delayed (after) transitions
+---
+
+
+**Delayed transitions** are transitions that are triggered after a set amount of time. Delayed transitions are useful for building timeouts and intervals into your application logic. If another event occurs before the end of the timer, the transition doesn’t complete.
+
+Delayed transitions are defined on the `after` property of a state node, either as a number (measured in milliseconds) or as a string that references a delay defined in the `delays` setup object.
+
+
+
+You can easily visualize and simulate delayed transitions in Stately’s editor. [Read more about delayed transitions in Stately’s editor](/docs/editor-states-and-transitions/#delayed-after-transitions).
+
+
+
+```ts
+import { createMachine } from 'xstate';
+
+const pushTheButtonGame = createMachine({
+ initial: 'waitingForButtonPush',
+ states: {
+ waitingForButtonPush: {
+ // [!code highlight:6]
+ after: {
+ 5000: {
+ target: 'timedOut',
+ actions: 'logThatYouGotTimedOut',
+ },
+ },
+ on: {
+ PUSH_BUTTON: {
+ actions: 'logSuccess',
+ target: 'success',
+ },
+ },
+ },
+ success: {},
+ timedOut: {},
+ },
+});
+```
+
+
+
+Watch our [“Delayed (after) transitions” video on YouTube](https://www.youtube.com/watch?v=5RE_eazRhrw&list=PLvWgkXBB3dd4I_l-djWVU2UGPyBgKfnTQ&index=12) (1m17s).
+
+
+
+## Delays
+
+You can define delays in a few ways: [inlined](#inlined-delays), [referenced](#referenced-delays), and as an expression.
+
+## Inlined delays
+
+You can define an inlined delay by specifying the delay time (in milliseconds) directly:
+
+```ts
+const machine = createMachine({
+ initial: 'idle',
+ states: {
+ idle: {
+ after: {
+ 1000: { target: 'nextState' },
+ },
+ },
+ nextState: {},
+ },
+});
+```
+
+This will transition to the `nextState` state after 1000ms.
+
+## Referenced delays
+
+You can also define referenced delays by specifying a string delay key, and providing the actual delay time separately.
+
+For example:
+
+```ts
+import { setup } from 'xstate';
+
+const machine = setup({
+ // [!code highlight:3]
+ delays: {
+ timeout: 1000,
+ },
+}).createMachine({
+ initial: 'idle',
+ states: {
+ idle: {
+ after: {
+ // [!code highlight:1]
+ timeout: { target: 'nextState' },
+ },
+ },
+ nextState: {},
+ },
+});
+```
+
+## Dynamic delays
+
+Delays can also be dynamically defined as a function that returns the delay time in milliseconds:
+
+```ts
+import { setup } from 'xstate';
+
+const machine = setup({
+ types: {
+ context: {} as {
+ attempts: number;
+ },
+ },
+ // [!code highlight:5]
+ delays: {
+ timeout: ({ context }) => {
+ return context.attempts * 1000;
+ },
+ },
+}).createMachine({
+ initial: 'attempting',
+ states: {
+ attempting: {
+ after: {
+ // [!code highlight:4]
+ timeout: {
+ actions: assign({ attempts: ({ context }) => context.attempts + 1 }),
+ target: 'attempting',
+ },
+ },
+ },
+ // ...
+ },
+});
+```
+
+## Lifecycle
+
+Delayed transition timers are canceled when the state is exited.
+
+## Testing
+
+- Simulated clock
+
+## Delayed transitions and TypeScript
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+You can strongly type the `delays` of your machine by setting up the the delays in the `setup()` function:
+
+```ts
+import { setup } from 'xstate';
+
+const machine = setup({
+ // [!code highlight:5]
+ delays: {
+ shortTimeout: 1000,
+ longTimeout: 5000,
+ eventually: 10_000,
+ },
+}).createMachine({
+ after: {
+ shortTimeout: {
+ /* ... */
+ },
+ },
+});
+```
+
+## Delayed transitions cheatsheet
+
+Use our XState delayed transitions cheatsheet below to get started quickly.
+
+```ts
+createMachine({
+ after: {
+ DELAY: {
+ /* ... */
+ },
+ },
+}).provide({
+ delays: {
+ DELAY: 1000, // or expression
+ },
+});
+```
diff --git a/fumadocs/content/docs/descriptions.mdx b/fumadocs/content/docs/descriptions.mdx
new file mode 100644
index 000000000..7e5e7dfb0
--- /dev/null
+++ b/fumadocs/content/docs/descriptions.mdx
@@ -0,0 +1,26 @@
+---
+title: Descriptions
+---
+
+import { AlignLeft, Info, Plus } from 'lucide-react';
+
+You can add descriptions to state and event nodes to describe their purpose and share related notes with your team. Descriptions support markdown formatting, including links and images.
+
+You can only add one description for each state or event. The machine object will include your descriptions in the state or event’s `description` when you export your statecharts to JSON.
+
+
+
*/}
+
+
+
+1. **Editor menu**: access common Stately shortcuts and view options.
+2. **Left drawer switch**: open and close the left drawer which contains the machines list.
+3. Current [project](projects).
+4. Current machine.
+5.
+
+The XState developer tools currently only work for XState version 4. Typegen is not supported in XState version 5.
+
+
+
+Find more about our [XState CLI (Command Line Interface)](#xstate-cli-command-line-interface) below. We plan to make extensions for more IDEs (Integrated Development Environments) in the future.
+
+
+
+[Read about our XState VS Code extension on its own page](xstate-vscode-extension).
+
+
+
+## XState CLI (Command Line Interface)
+
+The [@xstate/cli (Command Line Interface) package](https://github.com/statelyai/xstate-tools/tree/master/apps/cli) contains commands for running typegen. The package is small right now, but we plan to add more features.
+
+### Installation
+
+Run `npm install @xstate/cli`.
+
+### Commands
+
+#### `xstate typegen `
+
+Use the following command to run the typegen against a glob.
+
+`xstate typegen "src/**/*.ts?(x)"`
+
+Running typegen will scan every targeted file and generate a typegen file to accompany it. It will also import the typegen into your file, as described in [our typegen documentation](typegen).
+
+
+
+Ensure you wrap your glob in quotes for correct execution. If you don’t wrap the glob in quotes, it will be interpreted as a list of files, not a glob, which will give unexpected results.
+
+
+
+#### Options
+
+`xstate typegen "src/**/*.ts?(x)" --watch`
+
+Runs the task on a watch, monitoring for changed files and running the typegen script against them.
diff --git a/fumadocs/content/docs/developer-tools/meta.json b/fumadocs/content/docs/developer-tools/meta.json
new file mode 100644
index 000000000..d06238df4
--- /dev/null
+++ b/fumadocs/content/docs/developer-tools/meta.json
@@ -0,0 +1,9 @@
+{
+ "title": "Developer tools",
+ "pages": [
+ "xstate-vscode-extension",
+ "visualizer",
+ "inspector",
+ "developer-tools"
+ ]
+}
diff --git a/fumadocs/content/docs/discover.mdx b/fumadocs/content/docs/discover.mdx
new file mode 100644
index 000000000..d66581e5a
--- /dev/null
+++ b/fumadocs/content/docs/discover.mdx
@@ -0,0 +1,41 @@
+---
+title: Discover
+---
+
+import { GitFork, MoreHorizontal } from 'lucide-react';
+
+Are you seeking inspiration for your machine? Or do you want to learn how somebody else models their machines? The [Discover page](https://stately.ai/registry/discover) lists all the public machines created in Stately Studio.
+
+{/*
+
*/}
+
+
+
+With the search feature, you can quickly filter your results by the number of states in a machine and whether the machine’s creator used [Stately Studio’s editor](https://stately.ai/editor) or our older [Viz](https://stately.ai/viz) tool. Each machine listed details its creator, number of states, and a link to view and edit the machine in the editor.
+
+## Export and fork public machines
+
+When viewing somebody else’s machine, you can’t make changes. You can fork the machine to create an editable copy inside your **My Projects**.
+
+### Export a public machine
+
+Choose **Export code** from the
+
+You must be signed into the Stately Studio to fork a machine.
+
+
+
+Choose **Fork to project** from the Backspace key, _right-click_ and choose **Delete**, or use the **Sources** panel and enter the actor’s source logic.
+
+Provide your actor with an ID so it can be used with the [`sendTo` or `stop` actions](#xstate-built-in-actions) to stop and send events to the actor. You can add actor input by selecting the actor and using add Backspace key, _right-click_ and choose **Delete**, or use the **[Sources](sources)** panel, which will be formatted in your [exported code](export-as-code). The options are:
+
+- [assign](/docs/actions/#assign-action): assigns data to the state context.
+- [raise](/docs/actions/#raise-action): raises an event that is received by the same machine.
+- [log](/docs/actions/#log-action): an easy way to log messages to the console.
+- [sendTo](/docs/actions/#send-to-action): sends an event to a specific actor.
+- [stop](/docs/actions/#stop-action): stops a child actor.
+
+- [Read more about actions in XState](actions).
+- [Read more about actors in XState](actors).
+
+### Spawning actors in Stately’s editor
+
+_Coming soon_
diff --git a/fumadocs/content/docs/editor-context-and-meta.mdx b/fumadocs/content/docs/editor-context-and-meta.mdx
new file mode 100644
index 000000000..a181d7f8c
--- /dev/null
+++ b/fumadocs/content/docs/editor-context-and-meta.mdx
@@ -0,0 +1,8 @@
+---
+title: 'Context and meta in Stately’s editor'
+description: 'Learn how to use context and meta information for your state machines in Stately’s editor.'
+---
+
+- Coming soon… setting initial context values
+- Coming soon… updating context with assign
+- Coming soon… JS/TS export
diff --git a/fumadocs/content/docs/editor-states-and-transitions.mdx b/fumadocs/content/docs/editor-states-and-transitions.mdx
new file mode 100644
index 000000000..ae91bce89
--- /dev/null
+++ b/fumadocs/content/docs/editor-states-and-transitions.mdx
@@ -0,0 +1,205 @@
+---
+title: 'States and transitions in Stately’s editor'
+description: 'Learn how to use states and transitions, including parent states, parallel states, guards, delayed transitions and eventless transitions in Stately’s editor.'
+---
+
+import { MoreHorizontal, Plus, Info, AlertTriangle, Star, Code, PlayCircle } from 'lucide-react';
+
+# States and transitions
+
+State machines help us model how a process goes from state to state when an event occurs. At their most basic, state machines are made up of these states, events, and the transitions between them.
+
+
+
+Want to learn more about the concepts of state machines? [Check out our introduction to state machines and statecharts](state-machines-and-statecharts).
+
+
+
+## States
+
+In Stately’s editor, the rounded rectangle boxes are states. There are a few different types of states:
+
+- **Normal** states don’t have any special properties.
+- [**Initial states**](#initial-states) are the first states the machine enters when it starts.
+- [**Final states**](#final-states) are the last states the machine enters before it stops.
+- [**Parent states**](#parent-and-child-states) can contain more states, known as child states.
+- [**Parallel states**](#parallel-states) are parent states that have multiple child states that are all active at the same time.
+- [**History states**](#history-states) are parent states that remember which child state was active when the parent state was exited and re-enter that child state when the parent state is re-entered.
+
+Backspace key to delete the selected state.
+
+### Parent and child states
+
+States can contain more states, also known as child states. These child states are only active when the parent state is active. [Read more about parent and child states](parent-states).
+
+To add a child state:
+
+- Select an existing state and use warning icon indicates an unreachable state. The state is unreachable because it isn’t connected to the [initial state](#initial-states) by a [transition](#transitions-and-events).
+
+## Transitions and events
+
+A machine moves from state to state through transitions. Transitions are caused by events; when an event happens, the machine transitions to the next state.
+
+In Stately’s editor, the arrows are transitions, and the rounded rectangles on the arrow’s lines are events. Each transition has a _source_ state, which comes before the transition, and a _target_ state, which comes after the transition. The transition’s arrow starts from the source state and points to the target state.
+
+There are a few different types of transitions:
+
+- **Normal** transitions are triggered by an event.
+- [**Guarded transitions**](#add-guards) are triggered by an event, but only if a specified condition is met.
+- [**Delayed transitions**](#delayed-after-transitions) (also known as _after_ transitions) are triggered by an internal XState event, but only after a specified time interval.
+- [**Eventless transitions**](#eventless-always-transitions) (also known as _always_ transitions) are triggered by a timer or other condition, and don’t have an event.
+
+Backspace key to delete the selected transition.
+
+### Changing transition source and target
+
+- Use the **[Sources](sources)** panel.
diff --git a/fumadocs/content/docs/editor-tags.mdx b/fumadocs/content/docs/editor-tags.mdx
new file mode 100644
index 000000000..4e31d7aef
--- /dev/null
+++ b/fumadocs/content/docs/editor-tags.mdx
@@ -0,0 +1,14 @@
+---
+title: Tags in Stately’s editor
+description: 'Learn how to use tags on your states in Stately’s editor.'
+---
+
+import { Plus, Info, PlusSquare } from 'lucide-react';
+
+# Tags
+
+You can add tags to states in Stately’s editor:
+
+- Select the state you want to tag and use
+
+In the future, we plan to provide configurable embeds with copy-and-paste code.
+
+If you want us to prioritize improving embed mode, please [upvote it on our feedback page](https://github.com/statelyai/feedback/issues/94).
+
+
+
+## URL parameters, including color mode
+
+The embed URL has some of the same parameters as the [machine URL](url).
+
+- **machineId**: the unique ID for the machine. For example, `machineId=491a4c60-5300-4e22-92cf-8a32a8ffffca`
+- **mode**: the current machine mode. For example, `mode=Design` or `mode=Simulate`
+- **colorMode**: the color mode for the embedded machine. For example, `colorMode=light` or `colorMode=dark`
+
+By default, the color mode will be the same as your chosen Stately Studio color mode. Add `&colorMode=light` or `&colorMode=dark` to the URL to force that color mode.
diff --git a/fumadocs/content/docs/event-emitter.mdx b/fumadocs/content/docs/event-emitter.mdx
new file mode 100644
index 000000000..d0f9493d2
--- /dev/null
+++ b/fumadocs/content/docs/event-emitter.mdx
@@ -0,0 +1,235 @@
+---
+title: Event emitter
+---
+
+_Since XState version 5.9.0_
+
+State machines and other types of actor logic in XState have the ability to emit events. This allows external event handlers to be notified of specific events.
+
+With state machines, you can emit events using the `emit(event)` action creator.
+
+```ts
+import { setup, emit } from 'xstate';
+
+const machine = setup({
+ actions: {
+ // [!code highlight:1]
+ emitEvent: emit({ type: 'notification' }),
+ },
+}).createMachine({
+ // ...
+ on: {
+ someEvent: {
+ // [!code highlight:1]
+ actions: { type: 'emitEvent' },
+ },
+ },
+});
+
+const actor = createActor(machine);
+
+// [!code highlight:3]
+actor.on('notification', (event) => {
+ console.log('Notification received!', event);
+});
+
+actor.start();
+
+actor.send({ type: 'someEvent' });
+// Logs:
+// "Notification received!"
+// { type: "notification" }
+```
+
+## Emitting events from actor logic
+
+For promise actors, transition actors, observable actors, and callback actors, you can use the `emit` method from the arguments to emit events.
+
+**Promise actors**
+
+```ts
+import { fromPromise } from 'xstate';
+
+// [!code highlight:1]
+const logic = fromPromise(async ({ emit }) => {
+ // ...
+ // [!code highlight:4]
+ emit({
+ type: 'emitted',
+ msg: 'hello',
+ });
+ // ...
+});
+```
+
+**Transition actors**
+
+```ts
+import { fromTransition } from 'xstate';
+
+// [!code highlight:1]
+const logic = fromTransition((state, event, { emit }) => {
+ // ...
+ // [!code highlight:4]
+ emit({
+ type: 'emitted',
+ msg: 'hello',
+ });
+ // ...
+ return state;
+}, {});
+```
+
+**Observable actors**
+
+```ts
+import { fromObservable } from 'xstate';
+
+// [!code highlight:1]
+const logic = fromObservable(({ emit }) => {
+ // ...
+ // [!code highlight:4]
+ emit({
+ type: 'emitted',
+ msg: 'hello',
+ });
+ // ...
+});
+```
+
+**Callback actors**
+
+```ts
+import { fromCallback } from 'xstate';
+
+// [!code highlight:1]
+const logic = fromCallback(({ emit }) => {
+ // ...
+ // [!code highlight:4]
+ emit({
+ type: 'emitted',
+ msg: 'hello',
+ });
+ // ...
+});
+```
+
+## Emit action creator
+
+The emit action is a special action that _emits_ an event to any external event handlers from state machine logic. The emitted event can be statically or dynamically defined:
+
+```ts
+import { setup, emit } from 'xstate';
+
+const machine = setup({
+ actions: {
+ // [!code highlight:5]
+ // Emitting a statically-defined event
+ emitStaticEvent: emit({
+ type: 'someStaticEvent',
+ data: 42,
+ }),
+
+ // [!code highlight:5]
+ // Emitting a dynamically-defined event based on context
+ emitDynamicEvent: emit(({ context }) => ({
+ type: 'someDynamicEvent',
+ data: context.someData,
+ })),
+ },
+}).createMachine({
+ // ...
+ on: {
+ someEvent: {
+ actions: [{ type: 'emitStaticEvent' }, { type: 'emitDynamicEvent' }],
+ },
+ },
+});
+```
+
+## Event handlers
+
+You can attach event handlers to the actor to listen for emitted events by using `actor.on(event, handler)`:
+
+```ts
+const someActor = createActor(someMachine);
+
+// [!code highlight:4]
+someActor.on('someEvent', (emittedEvent) => {
+ // Handle the emitted event
+ console.log(emittedEvent);
+});
+
+someActor.start();
+```
+
+The `actor.on(…)` method returns a subscription object. You can call `.unsubscribe()` on it to remove the handler:
+
+```ts
+const someActor = createActor(someMachine);
+
+// [!code highlight:4]
+const subscription = someActor.on('someEvent', (emittedEvent) => {
+ // Handle the emitted event
+ console.log(emittedEvent);
+});
+
+someActor.start();
+
+// ...
+
+// [!code highlight:2]
+// Stop listening for events
+subscription.unsubscribe();
+```
+
+## Wildcard event handlers
+
+You can listen for _any_ emitted event by listening for the wildcard `'*'`:
+
+```ts
+const someActor = createActor(someMachine);
+
+actor.on('*', (emitted) => {
+ console.log(emitted); // Any emitted event
+});
+```
+
+The `emitted` event will be typed as the union of all possible events that can be emitted from the machine.
+
+## TypeScript
+
+You can strongly type emitted events by defining the emitted event types in the `types.emitted` property of the `setup(…)` function:
+
+```ts
+import { setup, emit, createActor } from 'xstate';
+
+const machine = setup({
+ types: {
+ // [!code highlight:3]
+ emitted: {} as
+ | { type: 'notification'; message: string }
+ | { type: 'error'; error: Error },
+ // ...
+ },
+}).createMachine({
+ // ...
+ on: {
+ someEvent: {
+ actions: [
+ // [!code highlight:2]
+ // Strongly typed emitted event
+ emit({ type: 'notification', message: 'Hello' }),
+ ],
+ },
+ },
+});
+
+const actor = createActor(machine);
+
+// [!code highlight:4]
+// Strongly typed event handler
+actor.on('notification', (event) => {
+ console.log(event.message); // string
+});
+```
diff --git a/fumadocs/content/docs/eventless-transitions.mdx b/fumadocs/content/docs/eventless-transitions.mdx
new file mode 100644
index 000000000..d542b0752
--- /dev/null
+++ b/fumadocs/content/docs/eventless-transitions.mdx
@@ -0,0 +1,167 @@
+---
+title: Eventless (always) transitions
+---
+
+**Eventless transitions** are transitions that happen without an explicit event. These transitions are *always* taken when the transition is enabled.
+
+Eventless transitions are specified on the `always` state property and often referred to as “always” transitions.
+
+
+
+You can easily visualize and simulated eventless transitions in Stately’s editor. [Read more about eventless transitions in Stately’s editor](/docs/editor-states-and-transitions/#eventless-always-transitions).
+
+
+
+```ts
+import { createMachine } from 'xstate';
+const machine = createMachine({
+ states: {
+ form: {
+ initial: 'valid',
+ states: {
+ valid: {},
+ invalid: {},
+ },
+ // [!code highlight:4]
+ always: {
+ guard: 'isValid',
+ target: 'valid',
+ },
+ },
+ },
+});
+```
+
+## Eventless transitions and guards
+
+Eventless transitions are taken immediately after normal transitions are taken. They are only taken if enabled, for example, if their [guards](guards) are true. This makes eventless transitions helpful in doing things when some condition is true.
+
+## Avoid infinite loops
+
+
+
+Since unguarded “always” transitions always run, you should be careful not to create an infinite loop. XState will help guard against most infinite loop scenarios.
+
+
+
+Eventless transitions with no `target` nor `guard` will cause an infinite loop. Transitions using `guard` and `actions` may run into an infinite loop if its `guard` keeps returning true.
+
+You should define eventless transitions either with:
+
+- `target`
+- `guard` + `target`
+- `guard` + `actions`
+- `guard` + `target` + `actions`
+
+If `target` is declared, the value should differ from the current state node.
+
+## When to use
+
+Eventless transitions can be helpful when a state change is necessary, but there is no specific trigger for that change.
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ id: 'kettle',
+ initial: 'lukewarm',
+ context: {
+ temperature: 80,
+ },
+ states: {
+ lukewarm: {
+ on: {
+ boil: { target: 'heating' },
+ },
+ },
+ heating: {
+ always: {
+ guard: ({ context }) => context.temperature > 100,
+ target: 'boiling',
+ },
+ },
+ boiling: {
+ entry: ['turnOffLight'],
+ always: {
+ guard: ({ context }) => context.temperature <= 100,
+ target: 'heating',
+ },
+ },
+ },
+ on: {
+ 'temp.update': {
+ actions: ['updateTemperature'],
+ },
+ },
+});
+```
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+Eventless transitions can potentially be enabled by any event, so the `event` type is the union of all possible events.
+
+```ts
+const machine = createMachine({
+ types: {} as {
+ events: { type: 'greet'; message: string } | { type: 'submit' };
+ },
+ // ...
+ always: {
+ actions: ({ event }) => {
+ event.type; // 'greet' | 'submit'
+ },
+ guard: ({ event }) => {
+ event.type; // 'greet' | 'submit'
+ return true;
+ },
+ },
+});
+```
+
+## Eventless transitions cheatsheet
+
+### Cheatsheet: root eventless (always) transition
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ always: {
+ guard: 'isValid',
+ actions: ['doSomething'],
+ },
+ // ...
+});
+```
+
+### Cheatsheet: state eventless (always) transition
+
+```ts
+const machine = createMachine({
+ initial: 'start',
+ states: {
+ start: {
+ always: {
+ guard: 'isValid',
+ target: 'otherState',
+ },
+ },
+ otherState: {
+ /* ... */
+ },
+ },
+});
+```
diff --git a/fumadocs/content/docs/examples.mdx b/fumadocs/content/docs/examples.mdx
new file mode 100644
index 000000000..2a7eb2ab2
--- /dev/null
+++ b/fumadocs/content/docs/examples.mdx
@@ -0,0 +1,315 @@
+---
+title: XState examples
+---
+
+XState v5 examples are also available in the [`/examples` directory](https://github.com/statelyai/xstate/tree/main/examples). Many of the examples have a CodeSandbox link where you can run the example in your browser.
+
+## Simple fetch example
+
+A simple fetch example built with:
+
+- XState v5
+- Parcel
+
+- [Simple fetch example on GitHub](https://github.com/statelyai/xstate/tree/main/examples/fetch)
+- [Simple fetch example on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/fetch)
+
+## 7GUIs counter (React)
+
+An implementation of the [7GUIs counter](https://eugenkiss.github.io/7guis/tasks/#counter) built with:
+
+- XState v5
+- React
+- TypeScript
+- Vite
+
+- [7GUIs counter (React) on GitHub](https://github.com/statelyai/xstate/tree/main/examples/7guis-counter-react)
+- [7GUIs counter (React) on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/react-7guis-counter)
+
+## 7GUIs temperature (React)
+
+This is an implementation of the [7GUIs temperature converter](https://eugenkiss.github.io/7guis/tasks#temp) built with:
+
+- XState v5
+- React
+- TypeScript
+- Vite
+
+- [7GUIs temperature (React) on GitHub](https://github.com/statelyai/xstate/tree/main/examples/7guis-temperature-react)
+- [7GUIs temperature (React) on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/react-7guis-temperature)
+
+## Simple list (React)
+
+A React list built with:
+
+- XState v5
+- React
+- TypeScript
+- Vite
+
+- [Simple list (React) on GitHub](https://github.com/statelyai/xstate/tree/main/examples/friends-list-react)
+- [Simple list (React) on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/react-list)
+
+## Stopwatch
+
+A simple stopwatch built with:
+
+- XState v5
+- TypeScript
+- Vite
+
+- [Stopwatch on GitHub](https://github.com/statelyai/xstate/tree/main/examples/stopwatch)
+- [Stopwatch on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/stopwatch)
+
+## Tic-tac-toe game (React)
+
+An implementation of tic-tac-toe built with:
+
+- XState v5
+- React
+- TypeScript
+- Vite
+
+- [Tic-tac-toe game (React) on GitHub](https://github.com/statelyai/xstate/tree/main/examples/tic-tac-toe-react)
+- [Tic-tac-toe game (React) on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/react-tic-tac-toe)
+
+## Tiles game (React)
+
+A simple tiles game built with:
+
+- XState v5
+- React
+- TypeScript
+- Vite
+
+- [Tiles game (React) on GitHub](https://github.com/statelyai/xstate/tree/main/examples/tiles)
+- [Tiles game (React) on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/tiles)
+
+## TodoMVC (React)
+
+An implementation of [TodoMVC](https://todomvc.com/) built with:
+
+- XState v5
+- React
+- TypeScript
+- Vite
+
+- [TodoMVC (React) on GitHub](https://github.com/statelyai/xstate/tree/main/examples/todomvc-react)
+- [TodoMVC (React) on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/todomvc-react)
+
+## Toggle
+
+A simple toggle built with:
+
+- XState v5
+- TypeScript
+- Vite
+
+- [Toggle on GitHub](https://github.com/statelyai/xstate/tree/main/examples/toggle)
+- [Toggle on CodeSandbox](https://codesandbox.io/p/sandbox/github/statelyai/xstate/tree/main/examples/toggle)
+
+## Hello world workflow
+
+Serverless hello world workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Hello-World-Example) built with:
+
+- XState v5
+
+[Hello world workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-hello)
+
+## Greeting workflow
+
+Serverless greeting workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Greeting-Example) built with:
+
+- XState v5
+
+[Greeting workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-greeting)
+
+## Event-based greeting workflow
+
+Serverless event-based greeting workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Event-Based-Greeting-Example) built with:
+
+- XState v5
+
+[Event-based greeting workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-event-greeting)
+
+## Solving math problems
+
+Serverless math solving problem workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Solving-Math-Problems-Example) built with:
+
+- XState v5
+
+[Solving math problems on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-math-problem)
+
+## Parallel execution workflow
+
+Serverless parallel execution workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Parallel-Execution-Example) built with:
+
+- XState v5
+
+[Parallel execution workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-parallel)
+
+## Async function invocation workflow
+
+Serverless async function invocation workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Async-Function-Invocation-Example) built with:
+
+- XState v5
+
+[Async function invocation workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-async-function)
+
+## Async subflow invocation workflow
+
+Serverless async subflow invocation workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Async-SubFlow-Invocation-Example) built with:
+
+- XState v5
+
+[Async subflow invocation workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-async-subflow)
+
+## Event-based transitions (event-based switch) workflow
+
+Serverless event-based transitions workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Event-Based-Transitions-Example) built with:
+
+- XState v5
+
+[Event-based transitions workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-event-based)
+
+## Applicant request decision workflow
+
+Serverless applicant request decision workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Applicant-Request-Decision-Example) built with:
+
+- XState v5
+
+[Applicant request decision workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-applicant-request)
+
+## Provision orders (error handling) workflow
+
+Serverless provision orders (error handling) workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Provision-Orders-Example) built with:
+
+- XState v5
+
+[Provision orders (error handling) workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-provision-orders)
+
+## Monitor job for completion (polling) workflow
+
+Serverless monitor job for completion (polling) workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Monitor-Job-Example) built with:
+
+- XState v5
+
+[Monitor job for completion (polling) workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-monitor-job)
+
+## Send CloudEvent on workflow completion
+
+Serverless send CloudEvent on workflow completion workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Send-CloudEvent-On-Workflow-Completion-Example) built with:
+
+- XState v5
+
+[Send CloudEvent on workflow completion on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-send-cloudevent)
+
+## Monitor patient vital signs workflow
+
+Serverless monitor patient vital signs workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Monitor-Patient-Vital-Signs-Example) built with:
+
+- XState v5
+
+[Monitor patient vital signs workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-monitor-patient)
+
+## Finalize college application workflow
+
+Serverless finalize college application workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Finalize-College-Application-Example) built with:
+
+- XState v5
+
+[Finalize college application workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-finalize-college-app)
+
+## Perform customer credit check workflow
+
+Serverless perform customer credit check workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Perform-Customer-Credit-Check-Example) built with:
+
+- XState v5
+
+[Perform customer credit check workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-credit-check)
+
+## Handle car auction bids (scheduled start) workflow
+
+Serverless handle car auction bids (scheduled start) workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Handle-Car-Auction-Bids-Example) built with:
+
+- XState v5
+
+[Handle car auction bids (scheduled start) workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-car-auction-bids)
+
+## Check inbox periodically (cron-based workflow start)
+
+Serverless check inbox periodically (cron-based workflow start) from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Check-Inbox-Periodically) built with:
+
+- XState v5
+
+[Check inbox periodically (cron-based workflow start) on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-check-inbox)
+
+## Event-based service workflow
+
+Serverless event-based service workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Event-Based-Service-Invocation) built with:
+
+- XState v5
+
+[Event-based service workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-event-based-service)
+
+## Reusing function and event definitions workflow
+
+Serverless reusing function and event definitions workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Reusing-Function-And-Event-Definitions) built with:
+
+- XState v5
+
+[Reusing function and event definitions workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-reusing-functions)
+
+## New patient onboarding (error checking and retries) workflow
+
+Serverless new patient onboarding (error checking and retries) workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#new-patient-onboarding).
+
+[New patient onboarding (error checking and retries) workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-new-patient-onboarding)
+
+## Purchase order deadline (ExecTimeout) workflow
+
+Serverless purchase order deadline (ExecTimeout) workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#purchase-order-deadline) built with:
+
+- XState v5
+
+[Purchase order deadline (ExecTimeout) workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-purchase-order-deadline)
+
+## Accumulate room readings and create timely reports (ExecTimeout and KeepActive) workflow
+
+Serverless accumulate room readings and create timely reports (ExecTimeout and KeepActive) workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#accumulate-room-readings) built with:
+
+- XState v5
+
+[Accumulate room readings and create timely reports (ExecTimeout and KeepActive) workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-accumulate-room-readings)
+
+## Car vitals checks (SubFlow Repeat) workflow
+
+Store a single bid when the car auction is active.
+
+Serverless car vitals checks (SubFlow Repeat) workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#handle-car-auction-bids-example) built with:
+
+- XState v5
+
+[Car vitals checks (SubFlow Repeat) workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-car-vitals)
+
+## Book lending workflow
+
+Serverless book lending workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#book-lending) built with:
+
+- XState v5
+
+[Book lending workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-book-lending)
+
+## Filling a glass of water workflow
+
+Serverless filling a glass of water workflow from the [CNCF Serverless Workflow examples](https://github.com/serverlessworkflow/specification/tree/main/examples#Filling-a-glass-of-water) built with:
+
+- XState v5
+
+[Filling a glass of water workflow on GitHub](https://github.com/statelyai/xstate/tree/main/examples/workflow-filling-water)
+
+## More examples coming soon
+
+If you have any examples you want us to make, please [add a request to our feedback board](https://feedback.stately.ai/examples) or upvote an existing suggestion.
+
+If you have an example you want to share, [contribute your example to the XState repository](https://github.com/statelyai/xstate/tree/main/examples#contributing-an-example).
diff --git a/fumadocs/content/docs/export-as-code.mdx b/fumadocs/content/docs/export-as-code.mdx
new file mode 100644
index 000000000..6aafb1f33
--- /dev/null
+++ b/fumadocs/content/docs/export-as-code.mdx
@@ -0,0 +1,44 @@
+---
+title: Export as code
+---
+
+import { Code, MoreHorizontal, Copy } from 'lucide-react';
+
+Exporting as code is useful if you want to use your machine with [XState](xstate) inside your codebase or if you want to duplicate your machine without using **Fork**.
+
+
+
+You can now [generate a React app from your machine](generate-react).
+
+
+
+Every feature of your state machine will be included in the code, except for [colors](colors) and [notes](annotations). Your last used export settings will be remembered next time you open the
+
+You can also [import from code](import-from-code) from
+
+### Export to CodeSandbox and StackBlitz
+
+You can export your machines to CodeSandbox and StackBlitz from the
+
+Wrap your Mermaid code in a fenced code block with the `mermaid` language identifier to [share your diagram on GitHub](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams#creating-mermaid-diagrams) and [share your diagram on GitLab](https://handbook.gitlab.com/handbook/tools-and-tips/mermaid/).
+
+
diff --git a/fumadocs/content/docs/figma.mdx b/fumadocs/content/docs/figma.mdx
new file mode 100644
index 000000000..60ee60296
--- /dev/null
+++ b/fumadocs/content/docs/figma.mdx
@@ -0,0 +1,59 @@
+---
+title: Embed Figma
+---
+
+import { Plus, Paperclip, Star, Info, Settings } from 'lucide-react';
+
+You can embed Figma frames in your states to keep your design and code in sync. Embedded Figma frames will stay up to date with the latest changes in your Figma files. Figma frames are a special type of [asset](assets).
+
+[In Nick’s blog post, read about how you can improve your team workflows with Stately and Figma](/blog/2024-01-24-embed-figma/).
+
+
+
+Embedding Figma frames is a premium feature of Stately Studio. You can try Stately Studio’s premium plans with a free trial. [Check out the features on our Pro plan](studio-pro-plan), [Team plan](studio-team-plan), [Enterprise plan](studio-enterprise-plan) or [upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+ **Embed Figma** on any selected state.
+4. Paste the Figma link into the **Figma URL** field and click **Add Figma Asset**.
+
+As Figma frames are a special type of [asset](assets), you can [change the display size of your Figma frame like any other asset](/docs/assets/#asset-sizes) and [change the order of your state’s assets](/docs/assets/#order-of-assets) to choose which asset is displayed on the state.
+
+### Syncing Figma frames
+
+Your embedded Figma frame will stay up to date with the latest changes in your Figma file unless:
+
+- [you lock your machine](#locked-machines-with-figma-frames)
+- [you revoke your Figma personal access token](#revoking-your-figma-personal-access-token)
+- [your Figma personal access token expires](#revoking-your-figma-personal-access-token)
+
+Refresh the page in the Stately Studio to see the latest changes from your embedded Figma frame.
+
+## Locked machines with Figma frames
+
+When your machine is [locked](lock-machines), updates to your Figma frames will not be synced to your machine. You can unlock your machine to sync your Figma frames again.
+
+## Figma personal access token
+
+You need a Figma [personal access token](https://help.figma.com/hc/en-us/articles/8085703771159-Manage-personal-access-tokens) to embed Figma frames. You can create a personal access token in [your Figma account settings](https://stately.ai/registry/user/my-settings?tab=Figma) under **Personal access tokens**.
+
+To ensure Embed Figma works correctly, you must grant the following permissions to your personal access token:
+
+- **File content**: Allow **Read-only** access so Stately Studio can sync your embedded Figma frames to your machines.
+
+You can update your Figma personal access token from your user **Settings** in Stately Studio anytime.
+
+### Revoking your Figma personal access token
+
+If you need to revoke your Figma personal access token, you can do so from your Figma account settings.
+
+When you revoke your Figma personal access token or your token expires, Stately Studio will no longer be able to sync your embedded Figma frames to your machines. The last synced version of your embedded Figma frames will remain in your machines for 14 days. After 14 days, Figma will entirely revoke access to the frame.
diff --git a/fumadocs/content/docs/final-states.mdx b/fumadocs/content/docs/final-states.mdx
new file mode 100644
index 000000000..da5570439
--- /dev/null
+++ b/fumadocs/content/docs/final-states.mdx
@@ -0,0 +1,281 @@
+---
+title: Final states
+---
+
+A final state is a state that represents the completion or successful termination of a machine. It is defined by the `type: 'final'` property on a state node:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ /* ... */
+ },
+ thanks: {
+ /* ... */
+ },
+ // [!code highlight:3]
+ closed: {
+ type: 'final',
+ },
+ // ...
+ },
+ on: {
+ 'feedback.close': {
+ target: '.closed',
+ },
+ },
+});
+```
+
+
+
+You can easily visualize and simulate intial and final states in Stately's editor. [Read more about states in Stately's editor](/docs/editor-states-and-transitions).
+
+
+
+```ts
+const feedbackMachine = createMachine({
+ id: 'feedback',
+
+ // Initial state
+ initial: 'prompt',
+
+ // Finite states
+ states: {
+ prompt: {
+ /* ... */
+ },
+ form: {
+ /* ... */
+ },
+ thanks: {
+ /* ... */
+ },
+ closed: {
+ /* ... */
+ },
+ },
+});
+```
+
+You can combine finite states with [context](context), which make up the overall state of a machine:
+
+```ts
+const feedbackMachine = createMachine({
+ id: 'feedback',
+ context: {
+ name: '',
+ email: '',
+ feedback: '',
+ },
+
+ initial: 'prompt',
+ states: {
+ prompt: {
+ /* ... */
+ },
+ },
+});
+
+const feedbackActor = createActor(feedbackMachine).start();
+
+// Finite state
+console.log(feedbackActor.getSnapshot().value);
+// logs 'prompt'
+
+// Context ("extended state")
+console.log(feedbackActor.getSnapshot().context);
+// logs { name: '', email: '', feedback: '' }
+```
+
+## Initial state
+
+The initial state is the state that the machine starts in. It is defined by the `initial` property on the machine config:
+
+```ts
+const feedbackMachine = createMachine({
+ id: 'feedback',
+
+ // [!code highlight:2]
+ // Initial state
+ initial: 'prompt',
+
+ // Finite states
+ states: {
+ // [!code highlight:1]
+ prompt: {
+ /* ... */
+ },
+ // ...
+ },
+});
+```
+
+[Read more about initial states](initial-states).
+
+## State nodes
+
+In XState, a **state node** is a finite state "nodes" that comprise the entire statechart tree. State nodes are defined on the `states` property of other state nodes, including the root machine config (which itself is a state node):
+
+```ts
+// The machine is the root state node
+const feedbackMachine = createMachine({
+ id: 'feedback',
+ initial: 'prompt',
+
+ // State nodes
+ states: {
+ // State node
+ prompt: {
+ /* ... */
+ },
+ // State node
+ form: {
+ /* ... */
+ },
+ // State node
+ thanks: {
+ /* ... */
+ },
+ // State node
+ closed: {
+ /* ... */
+ },
+ },
+});
+```
+
+## Tags
+
+State nodes can have **tags**, which are string terms that help group or categorize the state node. For example, you can signify which state nodes represent states in which data is being loaded by using a "loading" tag, and determine if a state contains those tagged state nodes with `state.hasTag(tag)`:
+
+```ts
+const feedbackMachine = createMachine({
+ id: 'feedback',
+ initial: 'prompt',
+ states: {
+ prompt: {
+ tags: ['visible'],
+ // ...
+ },
+ form: {
+ tags: ['visible'],
+ // ...
+ },
+ thanks: {
+ tags: ['visible', 'confetti'],
+ // ...
+ },
+ closed: {
+ tags: ['hidden'],
+ },
+ },
+});
+
+const feedbackActor = createActor(feedbackMachine).start();
+
+console.log(feedbackActor.getSnapshot().hasTag('visible'));
+// logs true
+```
+
+Read more about [tags](tags).
+
+## Meta
+
+Meta data is static data that describes relevant properties of a state node. You can specify meta data on the `.meta` property of any state node. This can be useful for displaying information about a state node in a UI, or for generating documentation.
+
+The `state.meta` property collects the `.meta` data from all active state nodes and places them in an object with the state node's ID as the key and the `.meta` data as the value:
+
+```ts
+const feedbackMachine = createMachine({
+ id: 'feedback',
+ initial: 'prompt',
+ meta: {
+ title: 'Feedback',
+ },
+ states: {
+ prompt: {
+ meta: {
+ content: 'How was your experience?',
+ },
+ },
+ form: {
+ meta: {
+ content: 'Please fill out the form below.',
+ },
+ },
+ thanks: {
+ meta: {
+ content: 'Thank you for your feedback!',
+ },
+ },
+ closed: {},
+ },
+});
+
+const feedbackActor = createActor(feedbackMachine).start();
+
+console.log(feedbackActor.getSnapshot().meta);
+// logs the object:
+// {
+// feedback: {
+// title: 'Feedback',
+// },
+// 'feedback.prompt': {
+// content: 'How was your experience?',
+// }
+// }
+```
+
+## Transitions
+
+Transitions are how you move from one finite state to another. They are defined by the `on` property on a state node:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ on: {
+ 'feedback.good': {
+ target: 'thanks',
+ },
+ },
+ },
+ thanks: {
+ /* ... */
+ },
+ // ...
+ },
+});
+
+const feedbackActor = createActor(feedbackMachine).start();
+
+console.log(feedbackActor.getSnapshot().value);
+// logs 'prompt'
+
+feedbackActor.send({ type: 'feedback.good' });
+
+console.log(feedbackActor.getSnapshot().value);
+// logs 'thanks'
+```
+
+Read more about [events and transitions](transitions).
+
+## Targets
+
+A transition's `target` property defines where the machine should go when the transition is taken. Normally, it targets a sibling state node:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ on: {
+ 'feedback.good': {
+ // [!code highlight:2]
+ // Targets the sibling `thanks` state node
+ target: 'thanks',
+ },
+ },
+ },
+ thanks: {
+ /* ... */
+ },
+ // ...
+ },
+});
+```
+
+The `target` can also target a descendant of a sibling state node:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ on: {
+ 'feedback.good': {
+ // [!code highlight:2]
+ // Targets the sibling `thanks.happy` state node
+ target: 'thanks.happy',
+ },
+ },
+ },
+ thanks: {
+ initial: 'normal',
+ states: {
+ normal: {},
+ // [!code highlight:1]
+ happy: {},
+ },
+ },
+ // ...
+ },
+});
+```
+
+When the target state node is a descendant of the source state node, the source state node key can be omitted:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ // ...
+ states: {
+ closed: {
+ initial: 'normal',
+ states: {
+ normal: {},
+ keypress: {},
+ },
+ },
+ },
+ on: {
+ 'feedback.close': {
+ // [!code highlight:2]
+ // Targets the descendant `closed` state node
+ target: '.closed',
+ },
+ 'key.escape': {
+ // [!code highlight:2]
+ // Targets the descendant `closed.keypress` state node
+ target: '.closed.keypress',
+ },
+ },
+});
+```
+
+When the state node doesn't change; i.e., the source and target state nodes are the same, the `target` property can be omitted:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ // ...
+ states: {
+ form: {
+ on: {
+ 'feedback.update': {
+ // [!code highlight:2]
+ // No target defined – stay on the `form` state node
+ // Equivalent to `target: '.form'` or `target: undefined`
+ actions: 'updateForm',
+ },
+ },
+ },
+ },
+});
+```
+
+State nodes can also be targeted by their `id` by prefixing the `target` with a `#` followed by the state node's `id`:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ initial: 'prompt',
+ states: {
+ // [!code highlight:3]
+ closed: {
+ id: 'finished',
+ },
+ // ...
+ },
+ on: {
+ 'feedback.close': {
+ // [!code highlight:1]
+ target: '#finished',
+ },
+ },
+});
+```
+
+## Identifying state nodes
+
+States can be identified with a unique ID: `id: 'myState'`. This is useful for targeting a state from any other state, even if they have different parent states:
+
+```ts
+import { createMachine, createActor } from 'xstate';
+
+const feedbackMachine = createMachine({
+ initial: 'prompt',
+ states: {
+ // ...
+ closed: {
+ // [!code highlight:1]
+ id: 'finished',
+ type: 'final',
+ },
+ // ...
+ },
+ on: {
+ 'feedback.close': {
+ // [!code highlight:2]
+ // Target the `.closed` state by its ID
+ target: '#finished',
+ },
+ },
+});
+```
+
+State IDs do not affect the `state.value`. In the above example, the `state.value` would still be `closed` even though the state node is identified as `#finished`.
+
+## Other state types
+
+In statecharts, there are other types of states:
+
+- [Parent states (also known as compound states)](parent-states)
+- [Parallel states](parallel-states)
+- [History states](history-states)
+- [Final states](final-states)
+
+## Modeling states
+
+When designing finite states for your state machine, follow these guidelines to create maintainable and effective state machines:
+
+### Start simple and shallow
+
+- **Begin with minimal states**: Don't create multiple finite states until it becomes apparent that the behavior of your logic differs depending on some finite state it can be in.
+- **Avoid premature optimization**: Start with basic states and add complexity only when necessary.
+- **Prefer flat structures initially**: Deep nesting can be added later when patterns emerge.
+
+### Identify distinct behaviors
+
+- **Different behavior = different state**: Create separate states when the application behaves differently in response to the same event.
+- **Same behavior = same state**: If multiple "states" handle events identically, they should probably be a single state.
+- **Question impossible states**: Ask "can this combination of conditions exist?" If not, model them as separate states.
+
+### Name states clearly
+
+- **Use descriptive names**: State names should clearly describe what the machine is doing or what mode it's in.
+- **Avoid technical jargon**: Use domain-specific language that stakeholders understand.
+- **Be consistent**: Use consistent naming conventions across your state machines.
+
+```ts
+// ❌ Poor naming
+const machine = createMachine({
+ initial: 'state1',
+ states: {
+ state1: {}, // What does this represent?
+ state2: {}, // What does this represent?
+ error: {}, // Too generic
+ },
+});
+
+// ✅ Good naming
+const authMachine = createMachine({
+ initial: 'signedOut',
+ states: {
+ signedOut: {},
+ signingIn: {},
+ signedIn: {},
+ authenticationFailed: {}, // Specific error state
+ },
+});
+```
+
+### Model user workflows
+
+- **Follow the user journey**: States should reflect the natural progression of user actions.
+- **Consider all paths**: Include happy paths, error states, and edge cases.
+- **Account for loading states**: Async operations often need intermediate states.
+
+```ts
+const checkoutMachine = createMachine({
+ initial: 'cart',
+ states: {
+ cart: {
+ on: {
+ PROCEED: { target: 'shippingInfo' },
+ },
+ },
+ shippingInfo: {
+ on: {
+ CONTINUE: { target: 'paymentInfo' },
+ BACK: { target: 'cart' },
+ },
+ },
+ paymentInfo: {
+ on: {
+ SUBMIT: { target: 'processing' },
+ BACK: { target: 'shippingInfo' },
+ },
+ },
+ processing: {
+ on: {
+ SUCCESS: { target: 'confirmed' },
+ FAILURE: { target: 'paymentFailed' },
+ },
+ },
+ paymentFailed: {
+ on: {
+ RETRY: { target: 'paymentInfo' },
+ },
+ },
+ confirmed: {
+ type: 'final',
+ },
+ },
+});
+```
+
+### Consider temporal aspects
+
+- **Time-sensitive states**: Model states that exist for specific durations.
+- **Expiration handling**: Include states for handling timeouts and expirations.
+- **Scheduled transitions**: Use delayed transitions for time-based state changes.
+
+### Group related functionality
+
+- **Use tags for categorization**: Group states by common characteristics.
+- **Consider parent states**: When multiple states share common transitions, consider grouping them under a parent state.
+- **Separate concerns**: Keep different domains or features in separate states.
+
+```ts
+const appMachine = createMachine({
+ initial: 'loading',
+ states: {
+ loading: {
+ tags: ['busy'],
+ on: {
+ LOADED: { target: 'idle' },
+ ERROR: { target: 'error' },
+ },
+ },
+ idle: {
+ tags: ['interactive'],
+ on: {
+ START_WORK: { target: 'working' },
+ },
+ },
+ working: {
+ tags: ['busy', 'interactive'],
+ on: {
+ COMPLETE: { target: 'idle' },
+ CANCEL: { target: 'idle' },
+ },
+ },
+ error: {
+ tags: ['error'],
+ on: {
+ RETRY: { target: 'loading' },
+ },
+ },
+ },
+});
+```
+
+### Handle edge cases
+
+- **Invalid states**: Model states for handling invalid or unexpected conditions.
+- **Recovery states**: Provide ways to recover from error states.
+- **Fallback behavior**: Include default states for unhandled scenarios.
+
+### Validate state transitions
+
+- **Ensure all transitions make sense**: Every state transition should represent a valid business logic change.
+- **Avoid circular dependencies**: Be careful of states that can endlessly transition between each other without purpose.
+- **Consider guards**: Use guards to prevent invalid transitions even when events are received.
+
+### Document state purpose
+
+- **Use descriptions**: Add `.description` properties to explain complex states.
+- **Include meta data**: Store relevant information about what each state represents.
+- **Comment complex logic**: Explain why certain states exist and what they accomplish.
+
+```ts
+const feedbackMachine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ description: 'Waiting for user to indicate their satisfaction level',
+ meta: {
+ analytics: 'feedback_prompt_shown',
+ },
+ },
+ collectingDetails: {
+ description:
+ 'User provided negative feedback, collecting detailed information',
+ meta: {
+ analytics: 'detailed_feedback_form_shown',
+ },
+ },
+ },
+});
+```
+
+## Finite states and TypeScript
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+You can strongly type the finite states of your machine using the `setup(...)` function, which provides excellent TypeScript inference and autocompletion:
+
+```ts
+import { setup, createActor } from 'xstate';
+
+const feedbackMachine = setup({
+ types: {
+ context: {} as { feedback: string; rating: number },
+ events: {} as
+ | { type: 'feedback.good' }
+ | { type: 'feedback.bad' }
+ | { type: 'feedback.submit' },
+ },
+}).createMachine({
+ id: 'feedback',
+ initial: 'prompt',
+ context: {
+ feedback: '',
+ rating: 0,
+ },
+ states: {
+ prompt: {
+ on: {
+ 'feedback.good': { target: 'thanks' },
+ 'feedback.bad': { target: 'form' },
+ },
+ },
+ form: {
+ on: {
+ 'feedback.submit': { target: 'thanks' },
+ },
+ },
+ thanks: {
+ type: 'final',
+ },
+ },
+});
+
+const feedbackActor = createActor(feedbackMachine).start();
+
+// ✅ Type-safe and autocompletes
+const currentState = feedbackActor.getSnapshot();
+
+// ✅ `state.matches(...)` is type-safe with autocompletion
+if (currentState.matches('prompt')) {
+ // TypeScript knows we're in the 'prompt' state
+}
+
+// ✅ All state values have autocompletion
+const isFormState = currentState.matches('form');
+const isThanksState = currentState.matches('thanks');
+
+// ✅ `state.value` is also strongly typed
+const stateValue = currentState.value; // 'prompt' | 'form' | 'thanks'
+```
+
+When using `setup(...).createMachine(...)`, TypeScript provides:
+
+- **Type-safe state matching**: `state.matches(...)` with autocompletion for all possible state values
+- **Strongly-typed state values**: `state.value` is typed as a union of all possible state names
+- **Type-safe context**: Full type inference for `state.context`
+- **Type-safe events**: `actor.send(...)` only accepts defined event types
+
+## Finite states cheatsheet
+
+### Cheatsheet: create finite states
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ id: 'feedback',
+ initial: 'prompt',
+ states: {
+ prompt: {},
+ form: {},
+ thanks: {},
+ closed: {},
+ },
+});
+```
+
+### Cheatsheet: finite states with transitions
+
+```ts
+import { createMachine } from 'xstate';
+
+const machine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ on: {
+ 'feedback.good': { target: 'thanks' },
+ 'feedback.bad': { target: 'form' },
+ },
+ },
+ form: {
+ on: {
+ 'feedback.submit': { target: 'thanks' },
+ },
+ },
+ thanks: {},
+ },
+});
+```
+
+### Cheatsheet: read current state
+
+```ts
+const actor = createActor(machine).start();
+const state = actor.getSnapshot();
+
+// Read state value
+console.log(state.value); // e.g., 'prompt'
+
+// Check if in specific state
+const isPromptState = state.matches('prompt');
+
+// Check multiple states
+const isFormOrThanks = state.matches('form') || state.matches('thanks');
+```
+
+### Cheatsheet: states with tags
+
+```ts
+const machine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ tags: ['visible', 'interactive'],
+ },
+ form: {
+ tags: ['visible', 'interactive'],
+ },
+ thanks: {
+ tags: ['visible', 'success'],
+ },
+ closed: {
+ tags: ['hidden'],
+ },
+ },
+});
+
+// Check tags
+const state = actor.getSnapshot();
+const isVisible = state.hasTag('visible');
+const isInteractive = state.hasTag('interactive');
+```
+
+### Cheatsheet: states with meta data
+
+```ts
+const machine = createMachine({
+ initial: 'prompt',
+ states: {
+ prompt: {
+ meta: {
+ title: 'How was your experience?',
+ component: 'PromptView',
+ },
+ },
+ form: {
+ meta: {
+ title: 'Tell us more',
+ component: 'FormView',
+ },
+ },
+ },
+});
+
+// Read meta data
+const state = actor.getSnapshot();
+console.log(state.getMeta());
+```
+
+### Cheatsheet: target states by ID
+
+```ts
+const machine = createMachine({
+ initial: 'start',
+ states: {
+ start: {
+ on: {
+ FINISH: { target: '#completed' },
+ },
+ },
+ process: {
+ states: {
+ step1: {},
+ step2: {},
+ },
+ },
+ done: {
+ id: 'completed',
+ type: 'final',
+ },
+ },
+});
+```
+
+### Cheatsheet: strongly-typed finite states
+
+```ts
+import { setup } from 'xstate';
+
+const machine = setup({
+ types: {
+ context: {} as { count: number },
+ events: {} as { type: 'increment' } | { type: 'decrement' },
+ },
+}).createMachine({
+ initial: 'idle',
+ context: { count: 0 },
+ states: {
+ idle: {
+ on: {
+ increment: { target: 'active' },
+ },
+ },
+ active: {
+ on: {
+ decrement: { target: 'idle' },
+ },
+ },
+ },
+});
+
+// Type-safe state matching
+const state = actor.getSnapshot();
+const isIdle = state.matches('idle'); // ✅ Autocompletes
+const stateValue = state.value; // ✅ 'idle' | 'active'
+```
diff --git a/fumadocs/content/docs/function-actors.mdx b/fumadocs/content/docs/function-actors.mdx
new file mode 100644
index 000000000..0ad6c508a
--- /dev/null
+++ b/fumadocs/content/docs/function-actors.mdx
@@ -0,0 +1,3 @@
+---
+title: Function Actors
+---
diff --git a/fumadocs/content/docs/generate-flow.mdx b/fumadocs/content/docs/generate-flow.mdx
new file mode 100644
index 000000000..cca6fb189
--- /dev/null
+++ b/fumadocs/content/docs/generate-flow.mdx
@@ -0,0 +1,55 @@
+---
+title: Generate with AI
+---
+
+import { Sparkles, History } from 'lucide-react';
+
+**Generate with AI** is an experimental feature that helps you auto-create machines from text descriptions. You can generate a flow for a new machine or use the flow description to describe how you want to modify your current flow.
+
+
+
+Community users can try generate flow with a limited number of generations each month. [Upgrade your existing plan](https://stately.ai/registry/billing) to get many more generations.
+
+
+
+
+
+**Generate with AI** is a premium feature of Stately Studio. You can try Stately Studio’s premium plans with a free trial. [Check out the features on our Pro plan](studio-pro-plan), [Team plan](studio-team-plan), [Enterprise plan](studio-enterprise-plan) or [upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+You have a limited number of generations available to use each month. The number of available generations is reset at the beginning of each calendar month.
+
+There are many reasons you might want to generate your flows, including:
+
+- You have a complex machine in mind and want to get started quickly
+- You want an example of a state machine for a particular flow
+- You’re new and want to get an idea of how you can model state machines
+
+
+
+Community users can try **Generate React app** with a limited number of generations each month. [Upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+
+
+**Generate React app** is a premium feature of Stately Studio. You can try Stately Studio’s premium plans with a free trial. [Check out the features on our Pro plan](studio-pro-plan), [Team plan](studio-team-plan), [Enterprise plan](studio-enterprise-plan) or [upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+You have a limited number of generations available to use each month. The number of available generations is reset at the beginning of each calendar month.
+
+## Enhance app
+
+Use the **Enhance app** button to generate an enhanced user interface after generating your React app. Once generated, the dropdown menu in the top right of the modal gives you options to preview three different versions of your enhanced app, as well as the default app generated before the enhancement.
+
+
+
+When you use **Enhance app**, your state machine and generated React app are sent to OpenAI to generate the enhanced app.
+
+
diff --git a/fumadocs/content/docs/generate-test-paths.mdx b/fumadocs/content/docs/generate-test-paths.mdx
new file mode 100644
index 000000000..c232aa62d
--- /dev/null
+++ b/fumadocs/content/docs/generate-test-paths.mdx
@@ -0,0 +1,33 @@
+---
+title: Generate test paths
+---
+
+import { ClipboardCheck } from 'lucide-react';
+
+You can generate test path code for your state machines from the **Tests** panel, which you can use to implement tests in your code. Both setup code and test code for each path are generated.
+
+This feature is in beta and [we’d love your feedback](https://feedback.stately.ai).
+
+
+
+**Generate test paths** is a premium feature of Stately Studio. You can try Stately Studio’s premium plans with a free trial. [Check out the features on our Pro plan](studio-pro-plan), [Team plan](studio-team-plan), [Enterprise plan](studio-enterprise-plan) or [upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+## Path generation strategy
+
+You can choose between two path generation strategies:
+
+- **Shortest path**: Generate paths that cover the shortest possible paths through your state machine and minimize the number of actions required to test functionality.
+- **Simplest path**: Generate paths that cover the simple paths, without repeated states, through your state machine and help verify that basic functionality is working as expected.
+
+## Testing frameworks
+
+Generate test paths currently supports [Playwright](https://playwright.dev/) and custom testing framework formats. We plan to add more testing frameworks (including Puppeteer, Cypress, and even other languages) in the future.
+
+## Options
+
+- **Reduce duplicate paths** generates fewer paths that also cover other paths.
+- **Prefer transition coverage** generates paths that cover all transitions in your state machine.
+- **Highlight paths** enables highlighting the paths on the canvas when you hover over its test path description.
+- **AI-generated test titles** (experimental) generates more readable test titles based on your state machine. AI-generated test titles send your state machine to OpenAI to generate the titles.
diff --git a/fumadocs/content/docs/get-started/meta.json b/fumadocs/content/docs/get-started/meta.json
new file mode 100644
index 000000000..d131b4d38
--- /dev/null
+++ b/fumadocs/content/docs/get-started/meta.json
@@ -0,0 +1,12 @@
+{
+ "title": "Get started",
+ "pages": [
+ "quick-start",
+ "installation",
+ "migration",
+ "examples",
+ "templates",
+ "cheatsheet",
+ "typescript"
+ ]
+}
diff --git a/fumadocs/content/docs/glossary.mdx b/fumadocs/content/docs/glossary.mdx
new file mode 100644
index 000000000..b21883e90
--- /dev/null
+++ b/fumadocs/content/docs/glossary.mdx
@@ -0,0 +1,87 @@
+---
+title: Glossary
+---
+
+This glossary is an alphabetical guide to the most common terms in statecharts and state machines.
+
+
+
+Looking for more detailed information on these concepts? [Read the introduction to state machines and statecharts](state-machines-and-statecharts).
+
+
+
+## Actions
+
+An [action](actions) is an effect that is executed during a state transition. Actions are “fire-and-forget effects”; once the machine has fired the action, it moves on and forgets the action.
+
+## Actors
+
+When you run a state machine, it becomes an [actor](actors), which is a running process that can receive events, send events, and change its behavior based on the events it receives, which can cause effects outside of the actor.
+
+## After transitions
+
+See [delayed transitions](#delayed-transitions).
+
+## Always transitions
+
+See [eventless transitions](#eventless-transitions).
+
+## Compound states
+
+See [parent and child states](#parent-and-child-states).
+
+## Context
+
+[Context](context) is the place that contextual data is stored in a state machine actor.
+
+## Delayed transitions
+
+[Delayed transitions](delayed-transitions) are transitions that only happen after a specified interval of time. If another event happens before the end of the timer, the transition doesn’t complete. Delayed transitions are labeled “after” and often referred to as “after” transitions.
+
+## Eventless transitions
+
+[Eventless transitions](eventless-transitions) are transitions without events. These transitions are *always* taken after any transition in their state is enabled. No event is necessary to trigger the transition. Eventless transitions are labeled “always” and often referred to as “always” transitions.
+
+## Final state
+
+When a machine reaches the [final state](final-states), it can no longer receive any events, and anything running inside it is canceled and cleaned up. A machine can have multiple final states or no final states.
+
+## Guards
+
+A [guard](guards) is a condition that the machine checks when it goes through an event. If the condition is true, the machine follows the transition to the next state. If the condition is false, the machine follows the rest of the conditions to the next state. Any transition can be a guarded transition.
+
+## History state
+
+A [history state](history-states) returns the parent state to its most recently active child state.
+
+## Initial state
+
+When a state machine starts, it enters the [**initial state**](initial-states) first. A machine can only have one top-level initial state.
+
+## Invoked actors
+
+An [invoked actor](actors) is an actor that can execute its own actions and communicate with the machine. These invoked actors are started in a state and stopped when the state is exited.
+
+## Parallel states
+
+A [parallel state](parallel-states) is a state separated into multiple regions of child states, where each region is active simultaneously.
+
+## Parent and child states
+
+States can contain more states, also known as [child states](parent-states). These child states are only active when the parent state is active. Child states are nested inside their parent states. Parent states are also known as compound states.
+
+## States
+
+A [state](states) describes the status of the machine. A state can be as simple as _active_ and _inactive_. These states are finite; the machine can only move through the pre-defined states. A state machine can only be in one state at a time.
+
+## Statecharts
+
+[Statecharts](state-machines-and-statecharts) are a visual extension to state machines enabling you to model more complex logic, including hierarchy, concurrency, and communication.
+
+## State machines
+
+A [state machine](state-machines-and-statecharts) is a model that describes how the state of a process transitions to another state when an event occurs. State machines make building reliable software easier because they prevent impossible states and undesired transitions. When you run a state machine, it becomes an [actor](actors).
+
+## Transitions and events
+
+A machine moves from state to state through [transitions](transitions). Transitions are caused by events; when an event happens, the machine transitions to the next state. Transitions are “deterministic”; each combination of state and event always points to the same next state.
diff --git a/fumadocs/content/docs/guards.mdx b/fumadocs/content/docs/guards.mdx
new file mode 100644
index 000000000..7a87e41d1
--- /dev/null
+++ b/fumadocs/content/docs/guards.mdx
@@ -0,0 +1,340 @@
+---
+title: Guards
+---
+
+A **guard** is a condition function that the machine checks when it goes through an event. If the condition is `true`, the machine follows the transition to the next state. If the condition is `false`, the machine follows the rest of the conditions to the next state.
+
+A **guarded transition** is a transition that is enabled only if its `guard` evaluates to `true`. The guard determines whether or not the transition can be enabled. Any transition can be a guarded transition.
+
+
+
+You can easily visualize and simulate guarded transitions in Stately’s editor. [Read more about guards in Stately’s editor](/docs/editor-states-and-transitions/#add-guards).
+
+
+
+Guards should be pure, synchronous functions that return either `true` or `false`.
+
+```ts
+const feedbackMachine = createMachine(
+ {
+ // ...
+ states: {
+ form: {
+ on: {
+ 'feedback.submit': {
+ // [!code highlight:1]
+ guard: 'isValid',
+ target: 'submitting',
+ },
+ },
+ },
+ submitting: {
+ // ...
+ },
+ },
+ },
+ {
+ // [!code highlight:5]
+ guards: {
+ isValid: ({ context }) => {
+ return context.feedback.length > 0;
+ },
+ },
+ },
+);
+```
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+You can strongly type the `guards` of your machine by setting up their implementations in `setup({ guards: { … } })`. You can provide the `params` type in the 2nd argument of the guard function:
+
+```ts
+import { setup } from 'xstate';
+
+const machine = setup({
+ // [!code highlight:5]
+ guards: {
+ isGreaterThan: (_, params: { count: number; min: number }) => {
+ return params.count > params.min;
+ },
+ },
+}).createMachine({
+ // ...
+ on: {
+ someEvent: {
+ guard: {
+ type: 'isGreaterThan',
+ // Strongly-typed params
+ params: ({ event }) => ({
+ count: event.count,
+ min: 10,
+ }),
+ },
+ // ...
+ },
+ },
+});
+```
+
+## Guards cheatsheet
+
+```ts
+import { createMachine } from 'xstate';
+
+const feedbackMachine = createMachine(
+ {
+ // ...
+ states: {
+ form: {
+ on: {
+ 'feedback.submit': {
+ // [!code highlight:1]
+ guard: 'isValid',
+ target: 'submitting',
+ },
+ },
+ },
+ submitting: {
+ // ...
+ },
+ },
+ },
+ {
+ // [!code highlight:5]
+ guards: {
+ isValid: ({ context }) => {
+ return context.feedback.length > 0;
+ },
+ },
+ },
+);
+```
+
+### Cheatsheet: multiple guarded transitions
+
+```ts
+import { createMachine } from 'xstate';
+
+const feedbackMachine = createMachine({
+ // ...
+ prompt: {
+ on: {
+ // [!code highlight:15]
+ 'feedback.provide': [
+ // Taken if 'sentimentGood' guard evaluates to `true`
+ {
+ guard: 'sentimentGood',
+ target: 'thanks',
+ },
+ // Taken if none of the above guarded transitions are taken
+ // and if 'sentimentBad' guard evaluates to `true`
+ {
+ guard: 'sentimentBad',
+ target: 'form',
+ },
+ // Default transition
+ { target: 'form' },
+ ],
+ },
+ },
+});
+```
+
+### Cheatsheet: Higher-level guards
+
+```ts
+import { createMachine, and } from 'xstate';
+
+const loginMachine = createMachine({
+ on: {
+ event: {
+ guard: and(['isValid', 'isAuthorized']);
+ }
+ }
+});
+```
+
+### Cheatsheet: Combined higher-level guards
+
+```ts
+import { createMachine, and, or } from 'xstate';
+
+const loginMachine = createMachine({
+ on: {
+ event: {
+ guard: and(['isValid', or(['isAuthorized', 'isGuest'])]);
+ }
+ }
+});
+```
diff --git a/fumadocs/content/docs/guides/meta.json b/fumadocs/content/docs/guides/meta.json
new file mode 100644
index 000000000..34b303afd
--- /dev/null
+++ b/fumadocs/content/docs/guides/meta.json
@@ -0,0 +1,7 @@
+{
+ "title": "Guides",
+ "pages": [
+ "testing",
+ "immer"
+ ]
+}
diff --git a/fumadocs/content/docs/history-states.mdx b/fumadocs/content/docs/history-states.mdx
new file mode 100644
index 000000000..a18db5fa0
--- /dev/null
+++ b/fumadocs/content/docs/history-states.mdx
@@ -0,0 +1,103 @@
+---
+title: History states
+---
+
+A history state is a special type of state (a _pseudostate_) that remembers the last [child state](parent-states) that was active before its parent state is exited. When a transition from outside the parent state targets a history state, the remembered child state is entered.
+
+This allows machines to "remember" where they left off when exiting and reentering a parent state.
+
+- If no child state remembered, history goes to `.target` state, if it is specified
+- Otherwise, go to [initial state](initial-states)
+
+A history state returns the parent state to its most recently active child state. The box with an **H** inside represents the history state.
+
+The history state can be deep or shallow:
+
+- A shallow history state remembers the immediate child’s state.
+- A deep history state remembers the deepest active state or states inside its child states.
+
+```ts
+const checkoutMachine = createMachine({
+ // ...
+ states: {
+ payment: {
+ initial: 'card',
+ states: {
+ card: {},
+ paypal: {},
+ // [!code highlight:1]
+ hist: { type: 'history' },
+ },
+ },
+ address: {
+ on: {
+ back: {
+ target: 'payment.hist',
+ },
+ },
+ },
+ },
+});
+```
+
+## Shallow vs. deep history
+
+- Shallow history states only remember the last active direct child state.
+- Deep history states remember all active descendant states.
+
+## History target
+
+- Normally, history states target the most recent child state of its parent state
+- If the history state is entered but the parent state was never visited, the parent's initial state is entered.
+- However, you can add a `target: 'childKey'` to specify the default child state that should be entered
+
+## History states cheatsheet
+
+### Cheatsheet: create a history state (shallow by default)
+
+```ts
+const machine = createMachine({
+ // ...
+ states: {
+ hist: { type: 'history' },
+ firstState: {},
+ someState: {},
+ anotherState: {},
+ },
+});
+```
+
+### Cheatsheet: create a deep history state
+
+```ts
+const machine = createMachine({
+ // ...
+ states: {
+ hist: {
+ type: 'history',
+ history: 'deep',
+ },
+ firstState: {},
+ someState: {},
+ anotherState: {},
+ },
+});
+```
+
+### Cheatsheet: create a history state with a target
+
+```ts
+const machine = createMachine({
+ // ...
+ initialState: 'firstState',
+ states: {
+ hist: {
+ type: 'history',
+ target: 'someState',
+ },
+ firstState: {},
+ someState: {},
+ anotherState: {},
+ },
+});
+```
diff --git a/fumadocs/content/docs/image.mdx b/fumadocs/content/docs/image.mdx
new file mode 100644
index 000000000..14d67fd9d
--- /dev/null
+++ b/fumadocs/content/docs/image.mdx
@@ -0,0 +1,63 @@
+---
+title: Share machine images using their image URL
+---
+
+import { LinkIcon, MoreHorizontal } from 'lucide-react';
+
+You can share an image of your machine anywhere that supports images. You can use the image URL for live-updating images where the machine is always updated with your latest changes. Machine images can be helpful in documentation, including GitHub pull requests.
+
+The image below is embedded using the copy image URL. Try switching between light and dark mode in the docs top bar; the image will change color mode too.
+
+{/*
+
*/}
+
+
+
+Your machine image will only be available if:
+
+- the project visibility is **public** or **unlisted**
+
+Machine images are not available for private machines.
+
+Read [how to change a project’s visibility settings](projects.mdx#change-a-projects-visibility).
+
+
+
+You can also [embed your machine](embed) for a focused non-editable view of your machine in Stately Studio’s editor.
+
+
+
+## Copy the image URL
+
+Use the
+
+It is recommended to use Immer directly with XState instead of the `@xstate/immer` package, which is deprecated.
+
+
+
+## Installation
+
+Install the latest versions of `xstate` and `immer` from npm:
+
+
+
+
+```bash
+npm install xstate immer
+```
+
+
+
+
+
+```bash
+pnpm install xstate immer
+```
+
+
+
+
+
+```bash
+yarn add xstate immer
+```
+
+
+
+
+See [the Immer installation docs](https://immerjs.github.io/immer/installation) for more information.
+
+## Immer usage
+
+XState already allows you to immutably update `context` partially or completely in [assign actions](/docs/actions#assign-action). However, for more complex scenarios, you may want to use Immer to update `context` in a less verbose way.
+
+```ts
+import { createMachine, assign } from 'xstate';
+// [!code highlight:1]
+import { produce } from 'immer';
+
+const machine = createMachine({
+ id: 'todos',
+ context: {
+ todos: [],
+ filter: 'all',
+ },
+ // ...
+ on: {
+ 'todo.complete': {
+ // [!code highlight:8]
+ // Using Immer to update a single context property
+ actions: assign({
+ todos: ({ context, event }) =>
+ produce(context.todos, (draftTodos) => {
+ const todo = draftTodos.find((t) => t.id === event.todo.id);
+ todo.completed = true;
+ }),
+ }),
+ },
+ 'todos.add': {
+ // [!code highlight:14]
+ // Using Immer to update multiple context properties
+ actions: assign(({ context, event }) =>
+ produce(context, (draftContext) => {
+ draftContext.todos.push({
+ id: event.todo.id,
+ description: event.todo.description,
+ completed: false,
+ });
+
+ if (draftContext.filter === 'all') {
+ draftContext.filter = 'active';
+ }
+ }),
+ ),
+ },
+ },
+});
+```
diff --git a/fumadocs/content/docs/import-from-code.mdx b/fumadocs/content/docs/import-from-code.mdx
new file mode 100644
index 000000000..248341ad6
--- /dev/null
+++ b/fumadocs/content/docs/import-from-code.mdx
@@ -0,0 +1,101 @@
+---
+title: Import from code
+---
+
+import { Code, FilePlus2, Import } from 'lucide-react';
+
+Importing from code is helpful if you’ve already built machines while working with [XState](xstate), or have created a machine using our older [Stately Viz](https://stately.ai/viz) but haven’t yet tried Stately Studio’s editor.
+
+
+
+Watch our [“Import from code” video on YouTube](https://www.youtube.com/watch?v=DAoIFaugDLo) (2m24s).
+
+
+
+## Import state machines
+
+Your state machine code should be formatted as a [`createMachine()` factory function](/docs/actors#createmachine) before import. The importer has basic validation in case your machine has basic errors, including reminding you if the `createMachine` definition is missing.
+
+[Check out an importable machine code example at the end of this page](#machine-code-example).
+
+
+
+**Caution**: importing code will overwrite your current or selected machine unless you create a new machine from the machines list inside a project.
+
+
+
+
+
+The Stately editor now supports importing multiple machines from code.
+
+
+
+### Create a new machine inside a project using imported code
+
+Create a **Import** button to import code into the new machine.
+
+### Import code to overwrite your machine
+
+Use **Import** button in the **Code** panel, or **Machine** > **Import** from the editor menu to overwrite your current machine.
+
+## Machine code example
+
+Below is an example of a `createMachine()` factory function which you can import as a machine without any errors:
+
+```js
+createMachine({
+ id: 'Video',
+ initial: 'Closed',
+ description: 'Video player',
+ states: {
+ Closed: {
+ on: {
+ PLAY: {
+ target: 'Opened',
+ },
+ },
+ },
+ Opened: {
+ invoke: {
+ src: 'startVideo',
+ },
+ initial: 'Playing',
+ description: 'Fullscreen mode',
+ states: {
+ Playing: {
+ on: {
+ PAUSE: {
+ target: 'Paused',
+ },
+ },
+ },
+ Paused: {
+ on: {
+ PLAY: {
+ target: 'Playing',
+ },
+ },
+ },
+ Stopped: {
+ type: 'final',
+ after: {
+ 5000: {
+ target: '#Video.Closed',
+ actions: [],
+ internal: false,
+ },
+ },
+ },
+ },
+ on: {
+ STOP: {
+ target: '.Stopped',
+ },
+ },
+ },
+ },
+ context: {},
+ predictableActionArguments: true,
+ preserveActionOrder: true,
+});
+```
diff --git a/fumadocs/content/docs/import-from-github.mdx b/fumadocs/content/docs/import-from-github.mdx
new file mode 100644
index 000000000..3490bbfd8
--- /dev/null
+++ b/fumadocs/content/docs/import-from-github.mdx
@@ -0,0 +1,133 @@
+---
+title: Connect GitHub repo
+description: 'Sync your machines from GitHub with Stately Studio.'
+---
+
+import { Code, Github, Settings } from 'lucide-react';
+
+You can connect a GitHub repo to a new project in Stately Studio, keeping updates between GitHub and Stately Studio in sync. Connecting a GitHub repo allows you to import your existing machines from GitHub and push changes to your machines back to your repo as pull requests.
+
+
+
+Connect GitHub repo is a premium feature of Stately Studio. You can try Stately Studio’s premium plans with a free trial. [Check out the features on our Pro plan](studio-pro-plan), [Team plan](studio-team-plan), [Enterprise plan](studio-enterprise-plan) or [upgrade your existing plan](https://stately.ai/registry/billing).
+
+
+
+
+ While this feature is in beta, it works best when connecting less than 100
+ files. For larger repos, we recommend creating single-file PRs. Read about
+ that feature
+ [here](/blog/2024-02-16-changelog#make-github-pull-requests-for-single-files-from-inside-stately-studio).
+
+
+## Connect GitHub repo
+
+Use the **Connect GitHub repo** button found in the Projects dashboard to start connecting a GitHub repo. There are three steps to setting up your GitHub repo as a connected project:
+
+1. Select the repo. You can choose the repos based on your GitHub permissions.
+2. Select the branch. You can choose any branch in your repo.
+3. Choose the files you want to sync. You can sync any JavaScript or TypeScript files, but only XState machines will be imported.
+
+
+
+Choose the XState version for your synced machines from the dropdown menu in the **Code** panel.
+
+
+
+### Auto-sync
+
+Enabling **auto-sync** will automatically fetch the latest changes from your connected repository every time you open or refresh the project in the Studio.
+
+Disable auto-sync from the GitHub options from the repository name in the footer of the left drawer.
+
+### Path for new files
+
+You can choose a **Path for new files** for when you create new machines in this connected project. These machines will be added at this relative path from the root of your repo. The default path is **src/stately-studio** and will be created in your repo the first time you add new machines to a pull request.
+
+### Create pull request
+
+Open the GitHub options from the repository name in the footer of the left drawer. You can create pull requests from the GitHub options for any changes made to your machine.
+
+#### Update pull request
+
+If you have already created a pull request for your machine, you can update the pull request with any changes you have made in the Studio. Open the GitHub options from the repository name in the footer of the left drawer and choose **Update pull request**.
+
+### Sync multiple branches
+
+You can sync multiple branches in your GitHub repo to the same project in Stately Studio. Open the GitHub branch options from the branch name in the footer of the left drawer to choose additional branches.
+
+### Sync new machines created in Stately Studio
+
+Creating a new machine in Stately Studio in a connected project will flag the machine in your Machines list as **Not synced with GitHub**. You can sync the machine with your GitHub repo by [creating a pull request from the GitHub options](#create-pull-request) from the repository name in the footer of the left drawer.
+
+Your new machine will be added to your repo at the [**Path for new files**](#path-for-new-files) you have chosen.
+
+### Sync changes to machines from GitHub
+
+If you have [auto-sync enabled](#auto-sync), any changes made to your GitHub repo will be synced to your project in Stately Studio when you open or refresh the project in the Studio.
+
+If you don’t have auto-sync enabled, you can sync any changes made to your GitHub repo using **Sync now** in the GitHub options from the repository name in the footer of the left drawer.
+
+## GitHub permissions
+
+Importing your GitHub repos with **Connect GitHub repo** or importing a machine with a GitHub URL will prompt you to give our GitHub integration access to your GitHub repositories. You can choose from **Automatic setup** or **Personal access token**.
+
+### Automatic setup
+
+Automatic setup will enable access to all the repositories your GitHub user can access. You can [provide your own personal access token](#personal-access-token) if you need more granular control.
+
+### GitHub personal access token
+
+For more granular control, you can provide a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). You can create a personal access token in your GitHub account settings under [Developer Settings](https://github.com/settings/tokens).
+
+To ensure GitHub Sync works correctly, you must grant the following permissions to your personal access token:
+
+- **Contents**: Allow **Read and write** access so Stately Studio can import your machines and create files for machines added in the Studio.
+- **Pull requests**: Allow **Read and write** access so Stately Studio can create pull requests for you (optional).
+
+You can update your personal access token from your user **Settings** in Stately Studio anytime.
+
+## Import machine from a GitHub URL
+
+If you want to quickly import a machine, or multiple machines, from a GitHub file without syncing, you can import from a GitHub URL.
+
+1. Open a file containing one or more machines on GitHub.
+2. Modify the URL in the browser’s address bar to replace the `.com` with `.stately.ai`.
+3. The editor will then display your imported machine.
+4. **Save** the machine to enable editing and easily find your machine in your projects later.
+
+Importing from a GitHub URL works with files in any branch in your private repositories, public repositories, and files in pull requests.
+
+### Pull requests
+
+Once you’ve made changes to your imported machine, you can use the **Create pull request** button to create a PR back to the source GitHub repository. If you want to make a pull request from your imported machine, you’ll need to provide a [GitHub personal access token](#github-personal-access-token).
+
+### Bookmarklet
+
+Use the bookmarklet below to import single file machines from GitHub with one click.
+
+1. Add a new bookmark to your browser
+2. Set the bookmark’s web address to the following:
+ `javascript:(function(){ location.href = 'https://github.stately.ai/' + window.location.pathname;})();`
+3. Click the bookmarklet when viewing a GitHub file containing one or more machines to import that machine to Stately Studio.
+
+Or drag the following bookmarklet link to your bookmarks:
+
+
+ GitHub → Stately
+
+
+### Example
+
+When your machine is hosted at GitHub:
+`https://github.com/username/repo/blob/main/apps/superMachine.ts`, update the URL to
+`https://github.stately.ai/username/repo/blob/main/apps/superMachine.ts` and Stately Studio will start the import.
+
+
+
+Read more in [our blog post about importing a machine from a GitHub URL](https://stately.ai/blog/2023-02-06-github-import-machines).
+
+
diff --git a/fumadocs/content/docs/index.mdx b/fumadocs/content/docs/index.mdx
new file mode 100644
index 000000000..c17129e9d
--- /dev/null
+++ b/fumadocs/content/docs/index.mdx
@@ -0,0 +1,73 @@
+---
+title: Stately + XState docs
+slug: '/'
+hide_title: true
+---
+
+import { LayoutIcon, BookOpenTextIcon, CodeIcon, RocketIcon } from 'lucide-react';
+import { Cards, Card } from 'fumadocs-ui/components/card';
+
+## Welcome to the Stately and XState docs
+
+[Stately.ai](studio) is a visual software modeling platform for modeling your app & business logic as state machines/statecharts and actors, and scales to any level of complexity.
+
+
+
+
+
XState is a best-in-class open source library for
+ orchestrating and managing complex application logic in JavaScript and TypeScript apps.
+
+
+
+
+
+
+Watch our [“What are initial states?” video on YouTube](https://www.youtube.com/watch?v=goCpmgyrjL0&list=PLvWgkXBB3dd4I_l-djWVU2UGPyBgKfnTQ&index=3) (1m17s).
+
+
+
+
+
+Input is coming to Stately Studio’s editor soon.
+
+
+
+## Creating actors with input
+
+You can pass `input` to any kind of actor by reading this input from the `input` property of the first argument to actor logic creators, such as `fromPromise()`, `fromTransition()`, `fromObservable()`, and other actor logic creators.
+
+**Input with `fromPromise()`:**
+
+```ts
+import { createActor, fromPromise } from 'xstate';
+
+const userFetcher = fromPromise(({ input }: { input: { userId: string } }) => {
+ return fetch(`/users/${input.userId}`).then((res) => res.json());
+});
+
+const userFetcherActor = createActor(userFetcher, {
+ // [!code highlight:3]
+ input: {
+ userId: '123',
+ },
+}).start();
+
+userFetcherActor.onDone((data) => {
+ console.log(data);
+ // logs the user data for userId 123
+});
+```
+
+**Input with `fromTransition()`:**
+
+```ts
+import { createActor, fromTransition } from 'xstate';
+
+const counter = fromTransition((state, event)) => {
+ if (event.type === 'INCREMENT') {
+ return { count: state.count + 1 };
+ }
+ return state;
+}, ({ input }: { input: { startingCount?: number } }) => ({
+ count: input.startingCount ?? 0,
+});
+
+const counterActor = createActor(counter, {
+ // [!code highlight:23]
+ input: {
+ startingCount: 10,
+ }
+});
+```
+
+**Input with `fromObservable()`:**
+
+```ts
+import { createActor, fromObservable } from 'xstate';
+import { interval } from 'rxjs';
+
+const intervalLogic = fromObservable(
+ ({ input }: { input: { interval: number } }) => {
+ return interval(input.interval);
+ },
+);
+
+const intervalActor = createActor(intervalLogic, {
+ // highlight-start
+ input: {
+ interval: 1000,
+ },
+});
+
+intervalActor.start();
+```
+
+## Initial event input
+
+When an actor is started, it will automatically send a special event named `xstate.init` to itself. If `input` is provided to the `createActor(logic, { input })` function, it will be included in the `xstate.init` event:
+
+```ts
+import { createActor, createMachine } from 'xstate';
+
+const feedbackMachine = createMachine({
+ // [!code highlight:4]
+ entry: ({ event }) => {
+ console.log(event.input);
+ // logs { userId: '123', defaultRating: 5 }
+ },
+ // ...
+});
+
+const feedbackActor = createActor(feedbackMachine, {
+ input: {
+ userId: '123',
+ defaultRating: 5,
+ },
+}).start();
+```
+
+## Invoking actors with input
+
+You can provide input to invoked actors via the `input` property of the `invoke` configuration:
+
+```ts
+import { createActor, setup } from 'xstate';
+
+const feedbackMachine = setup({
+ actors: {
+ liveFeedback: fromPromise(({ input }: { input: { domain: string } }) => {
+ return fetch(`https://${input.domain}/feedback`).then((res) =>
+ res.json(),
+ );
+ }),
+ },
+}).createMachine({
+ invoke: {
+ src: 'liveFeedback',
+ // [!code highlight:3]
+ input: {
+ domain: 'stately.ai',
+ },
+ },
+});
+```
+
+The `invoke.input` property can be a static input value or a function that returns the input value. The function will be called with an object that contains the current `context` and `event`:
+
+```ts
+import { createActor, setup } from 'xstate';
+
+const feedbackMachine = setup({
+ actors: {
+ // [!code highlight:3]
+ fetchUser: fromPromise(({ input }) => {
+ return fetch(`/users/${input.userId}`).then((res) => res.json());
+ }),
+ },
+}).createMachine({
+ context: {
+ userId: '',
+ feedback: '',
+ rating: 0,
+ },
+ invoke: {
+ src: 'fetchUser',
+ // [!code highlight:1]
+ input: ({ context }) => ({ userId: context.userId }),
+ },
+ // ...
+});
+```
+
+## Spawning actors with input
+
+You can provide input to spawned actors via the `input` property of the `spawn` configuration:
+
+```ts
+import { createActor, setup, type AnyActorRef } from 'xstate';
+
+const feedbackMachine = setup({
+ types: {
+ context: {} as {
+ userId: string;
+ feedback: string;
+ rating: number;
+ emailRef: AnyActorRef;
+ },
+ },
+ actors: {
+ // [!code highlight:6]
+ emailUser: fromPromise(({ input }: { input: { userId: string } }) => {
+ return fetch(`/users/${input.userId}`, {
+ method: 'POST',
+ // ...
+ });
+ }),
+ },
+}).createMachine({
+ context: {
+ userId: '',
+ feedback: '',
+ rating: 0,
+ emailRef: null,
+ },
+ // ...
+ on: {
+ 'feedback.submit': {
+ actions: assign({
+ emailRef: ({ context, spawn }) => {
+ return spawn('emailUser', {
+ // [!code highlight:1]
+ input: { userId: context.userId },
+ });
+ },
+ }),
+ },
+ },
+ // ...
+});
+```
+
+## Use-cases
+
+Input is useful for creating reusable machines that can be configured with different input values.
+
+- Replaces the old way of writing a factory function for machines:
+
+```ts
+// Old way: using a factory function
+const createFeedbackMachine = (userId, defaultRating) => {
+ return createMachine({
+ context: {
+ userId,
+ feedback: '',
+ rating: defaultRating,
+ },
+ // ...
+ });
+};
+
+const feedbackMachine1 = createFeedbackMachine('123', 5);
+
+const feedbackActor1 = createActor(feedbackMachine1).start();
+
+// New way: using input
+const feedbackMachine = createMachine({
+ context: ({ input }) => ({
+ userId: input.userId,
+ feedback: '',
+ rating: input.defaultRating,
+ }),
+ // ...
+});
+
+const feedbackActor = createActor(feedbackMachine, {
+ input: {
+ userId: '123',
+ defaultRating: 5,
+ },
+});
+```
+
+### Passing new data to an actor
+
+Changing the input will not cause the actor to be restarted. You need to send an event to the actor to pass the new data to the actor:
+
+```tsx
+const Component = (props) => {
+ const feedbackActor = useActor(feedbackMachine, {
+ input: {
+ userId: props.userId,
+ defaultRating: props.defaultRating,
+ },
+ });
+
+ useEffect(() => {
+ feedbackActor.send({
+ type: 'userId.change',
+ userId: props.userId,
+ });
+ }, [props.userId]);
+
+ // ...
+};
+```
+
+## Input and TypeScript
+
+
+
+**XState v5 requires TypeScript version 5.0 or greater.**
+
+For best results, use the latest TypeScript version. [Read more about XState and TypeScript](typescript)
+
+
+
+You can strongly type the `input` of your machine in the `types.input` property of the machine setup.
+
+```ts
+import { createActor, setup } from 'xstate';
+
+const machine = setup({
+ types: {
+ // [!code highlight:4]
+ input: {} as {
+ userId: string;
+ defaultRating: number;
+ };
+ context: {} as {
+ userId: string;
+ feedback: string;
+ rating: number;
+ };
+ },
+}).createMachine({
+ context: ({ input }) => ({
+ userId: input.userId,
+ feedback: '',
+ rating: input.defaultRating,
+ }),
+});
+
+const actor = createActor(machine, {
+ input: {
+ userId: '123',
+ defaultRating: 5,
+ },
+});
+```
+
+## Input cheatsheet
+
+Use our XState input cheatsheet below to get started quickly.
+
+### Cheatsheet: providing input
+
+```ts
+const feedbackActor = createActor(feedbackMachine, {
+ input: {
+ userId: '123',
+ defaultRating: 5,
+ },
+});
+```
+
+### Cheatsheet: providing input to invoked actors
+
+```ts
+const feedbackMachine = createMachine({
+ invoke: {
+ src: 'liveFeedback',
+ input: {
+ domain: 'stately.ai',
+ },
+ },
+});
+```
+
+### Cheatsheet: providing dynamic input to invoked actors
+
+```ts
+const feedbackMachine = createMachine({
+ context: {
+ userId: 'some-user-id',
+ },
+ invoke: {
+ src: 'fetchUser',
+ input: ({ context }) => ({ userId: context.userId }),
+ },
+});
+```
+
+### Cheatsheet: providing dynamic input from event properties to invoked actors
+
+```ts
+const feedbackMachine = createMachine({
+ types: {
+ events:
+ | { type: 'messageSent', message: string }
+ | { type: 'incremented', count: number },
+ },
+ invoke: {
+ src: 'fetchUser',
+ input: ({ event }) => {
+ // [!code highlight:1]
+ assertEvent(event, 'messageSent');
+ return {
+ message: event.message,
+ };
+ },
+ },
+});
+```
+
+### Cheatsheet: providing input to spawned actors
+
+```ts
+const feedbackMachine = createMachine({
+ context: {
+ userId: '',
+ },
+ // ...
+ on: {
+ 'feedback.submit': {
+ actions: assign({
+ emailRef: ({ context, spawn }) => {
+ return spawn('emailUser', {
+ input: { userId: context.userId },
+ });
+ },
+ }),
+ },
+ },
+ // ...
+});
+```
diff --git a/fumadocs/content/docs/inspection.mdx b/fumadocs/content/docs/inspection.mdx
new file mode 100644
index 000000000..54faf1fa2
--- /dev/null
+++ b/fumadocs/content/docs/inspection.mdx
@@ -0,0 +1,217 @@
+---
+title: 'Inspection'
+---
+
+The Inspect API is a way to inspect the state transitions of your state machines and every aspect of actors in an actor system. Including:
+
+- Actor lifecycle
+- Actor event communication
+- Actor snapshot updates
+- State transition microsteps
+
+
+
+[We’ve recently released Stately Inspector](/blog/2024-01-15-stately-inspector/), a universal tool that enables you to visually inspect the state of any application, frontend or backend, with the visualization of Stately’s editor.
+
+[Learn more about Stately Inspector](inspector)
+
+
+
+The Inspect API lets you attach an “inspector,” an observer that observes inspection events, to the root of an actor system:
+
+```tsx
+const actor = createActor(machine, {
+ inspect: (inspectionEvent) => {
+ // type: '@xstate.actor' or
+ // type: '@xstate.snapshot' or
+ // type: '@xstate.event' or
+ // type: '@xstate.microstep'
+ console.log(inspectionEvent);
+ },
+});
+```
+
+The inspector will receive inspection events for every actor in the system, giving you granular visibility into everything happening, from how an individual actor is changing to how actors communicate with each other.
+
+## Inspection events
+
+Inspection events are event objects that have a `type` property that indicates the type of inspection event. There are four types of inspection events:
+
+- `@xstate.actor` for [Actor inspection events](#actor-inspection-events)
+- `@xstate.event` for [Event inspection events](#event-inspection-events)
+- `@xstate.snapshot` for [Snapshot inspection events](#snapshot-inspection-events)
+- `@xstate.microstep` for [Microstep inspection events](#microstep-inspection-events)
+
+## Actor inspection events
+
+The actor inspection event (`@xstate.actor`) is emitted when an actor in the system is created. It contains the following properties:
+
+- `type` - the type of inspection event, always `'@xstate.actor'`
+- `actorRef` - the reference to the actor
+- `rootId` - the session ID of the root actor of the system
+
+Example of an actor inspection event:
+
+```js
+{
+ type: '@xstate.actor',
+ actorRef: {/* Actor reference */},
+ rootId: 'x:0',
+}
+```
+
+## Event inspection events
+
+The event inspection event (`@xstate.event`) is emitted when an event is sent to an actor. It contains the following properties:
+
+- `type` - the type of inspection event, always `'@xstate.event'`
+- `actorRef` - the reference to the target actor of the event
+- `rootId` - the session ID of the root actor of the system
+- `event` - the event object that was sent
+- `sourceRef` - the reference to the source actor that sent the event, or `undefined` if the source is not known or an event was sent directly to the actor
+
+Example of an event inspection event:
+
+```js
+{
+ type: '@xstate.event',
+ actorRef: {/* Actor reference */},
+ rootId: 'x:0',
+ event: {
+ type: 'someEvent',
+ message: 'hello'
+ },
+ sourceRef: {/* Actor reference */},
+}
+```
+
+## Snapshot inspection events
+
+The snapshot inspection event (`@xstate.snapshot`) is emitted when an actor's snapshot is updated. It contains the following properties:
+
+- `type` - the type of inspection event, always `'@xstate.snapshot'`
+- `actorRef` - the reference to the actor
+- `rootId` - the session ID of the root actor of the system
+- `snapshot` - the most recent snapshot of the actor
+- `event` - the event that caused the snapshot to be updated
+
+Example of a snapshot inspection event:
+
+```js
+{
+ type: '@xstate.snapshot',
+ actorRef: {/* Actor reference */},
+ rootId: 'x:0',
+ snapshot: {
+ status: 'active',
+ context: { count: 31 },
+ // ...
+ },
+ event: {
+ type: 'increment'
+ }
+}
+```
+
+## Microstep inspection events
+
+The microstep inspection event (`@xstate.microstep`) is emitted for each individual state transition, including intermediate "microsteps", that occurs during the processing of an event. This is particularly useful for observing eventless transitions (like `always` transitions) and understanding the step-by-step progression through multiple states.
+
+It contains the following properties:
+
+- `type: '@xstate.microstep'`
+- `value` - the current state value after this microstep
+- `event` - the event that triggered this microstep
+- `transitions` - an array of transition objects that occurred in this microstep
+
+Each transition object in the `transitions` array contains:
+
+- `eventType` - the event type that triggered the transition (empty string for eventless transitions)
+- `target` - an array of target state paths
+
+Example of a microstep inspection event:
+
+```json5
+{
+ type: '@xstate.microstep',
+ value: 'c',
+ event: {
+ type: 'EV',
+ },
+ transitions: [
+ {
+ eventType: 'EV',
+ target: ['(machine).b'],
+ },
+ {
+ eventType: '',
+ target: ['(machine).c'],
+ },
+ ],
+}
+```
+
+
+Example of microstep events
+
+Here's an example of microstep events:
+
+```tsx
+const machine = createMachine({
+ initial: 'a',
+ states: {
+ a: {
+ on: {
+ EV: 'b',
+ },
+ },
+ b: {
+ always: 'c', // This will trigger automatically after entering state 'b'
+ },
+ c: {},
+ },
+});
+
+const events = [];
+const actorRef = createActor(machine, {
+ inspect: (ev) => events.push(ev),
+}).start();
+
+actorRef.send({ type: 'EV' });
+```
+
+The microstep events will look like this:
+
+```json5
+// First microstep: EV transition to state 'b'
+{
+ type: '@xstate.microstep',
+ value: 'b',
+ event: {
+ type: 'EV'
+ },
+ transitions: [
+ {
+ eventType: 'EV',
+ target: ['(machine).b']
+ }
+ ]
+},
+
+// Second microstep: always transition to state 'c'
+{
+ type: '@xstate.microstep',
+ value: 'c',
+ event: {
+ type: 'EV'
+ },
+ transitions: [
+ {
+ eventType: '', // Empty string indicates eventless transition
+ target: ['(machine).c']
+ }
+ ]
+}
+```
+
+
diff --git a/fumadocs/content/docs/inspector.mdx b/fumadocs/content/docs/inspector.mdx
new file mode 100644
index 000000000..04714db9b
--- /dev/null
+++ b/fumadocs/content/docs/inspector.mdx
@@ -0,0 +1,133 @@
+---
+title: Inspector
+---
+
+# Stately Inspector
+
+Stately Inspector is a tool that allows you to inspect your application’s state visually. It primarily works with frontend applications using XState but can also work with backend code and code that uses any state management solution.
+
+
+
+[Read about our recent release of Stately Inspector on our blog](/blog/2024-01-15-stately-inspector/).
+
+
+
+## Install Stately Inspector
+
+To inspect applications with Stately Inspector, install [Stately Inspect](https://github.com/statelyai/inspect) from npm via `@statelyai/inspect`:
+
+```bash
+npm install @statelyai/inspect
+```
+
+Then import the relevant inspector creator into your app. The creator is used to create an inspector (e.g., a browser or WebSocket inspector) that you can use to either connect to XState actors and/or manually send inspection events to Stately Inspector:
+
+```ts
+import { createActor } from 'xstate';
+// [!code highlight:1]
+import { createBrowserInspector } from '@statelyai/inspect';
+import { machine } from './machine';
+
+// [!code highlight:1]
+const { inspect } = createBrowserInspector();
+
+// ...
+
+const actor = createActor(machine, {
+ // [!code highlight:1]
+ inspect,
+ // ... other actor options
+});
+
+actor.start();
+```
+
+When you run your app, a new tab or popup window will open with the Inspector.
+
+
+
+When using the browser inspector, ensure that the popup window is not blocked by your browser’s popup blocker.
+
+
+
+## Inspector options
+
+You can pass the following options to the browser inspector:
+
+- `filter` - a function that takes an inspection event and returns `true` if the event should be sent to the Stately Inspector.
+- `serialize` - a function that takes an inspection event and allows you to serialize it before sending it to the Stately Inspector.
+- `autoStart` - whether to automatically start the inspector. Defaults to `true`.
+ - If `autoStart: false`, you can start the inspector by calling `inspector.start()`.
+- `url` - the URL of the Stately Inspector to open. Defaults to `https://stately.ai/inspector`.
+- `iframe` - the `