import { Meta, Title, Subtitle, Description, Primary, Controls, Stories, Canvas } from '@storybook/addon-docs/blocks';
import * as MarkdownMessageStories from './markdown-message.stories';

<Meta of={MarkdownMessageStories} />

<Title />
<Subtitle>Renders AI assistant messages as formatted Markdown with syntax-highlighted code blocks.</Subtitle>

<Description />

<Primary />

---

## Usage

```tsx
import { MarkdownMessage } from 'xertica-ui/assistant';

<MarkdownMessage content="**Hello!** Here is a `code` example." />
```

## Supported Markdown

- **Bold**, *italic*, ~~strikethrough~~
- `inline code`
- Fenced code blocks (` ```lang `) with real syntax highlighting — rendered via `CodeBlock`, not a plain `<pre>`
- Lists (ordered and unordered)
- Headers `h1`–`h4` (`#` through `####`) — deeper levels are not supported
- Tables (GFM pipe syntax, `| a | b |`)
- Blockquotes (`> text`, including multi-line)

## Props

| Prop | Type | Default | Description |
|---|---|---|---|
| `content` | `string` | _(required)_ | The Markdown string to render |
| `className` | `string` | `''` | Additional CSS classes on the root container |

---

## Rich Text

Bold, italic, strikethrough, and inline code, mixed the way a real assistant reply combines them mid-sentence.

<Canvas>
  <MarkdownMessageStories.TextEmphasis />
</Canvas>

### Headings

<Canvas>
  <MarkdownMessageStories.Headings />
</Canvas>

### Bullet Lists with `*`

GFM allows `-`, `*`, or `•` as a bullet marker, and the assistant's own backend (Gemini via FDM) reliably picks `*`. Lists are resolved *before* bold/italic for exactly this reason: `*` is also the italic delimiter, so a bullet's leading `*` has to be turned into a `<li>` before any inline-emphasis rule gets a chance to misread it.

<Canvas>
  <MarkdownMessageStories.AsteriskBulletList />
</Canvas>

---

## Code Blocks

Fenced code (` ```python `) is extracted **before** any other Markdown rule runs and rendered as a real `CodeBlock` — with syntax highlighting and a copy button, not an HTML string. This matters: without that separation, characters like `**`, `_`, or backticks that naturally show up in real code (exponents, dunder methods, docstrings) would get misread as Markdown emphasis or inline-code markers by the rules meant for surrounding prose.

<Canvas>
  <MarkdownMessageStories.FencedCodeBlock />
</Canvas>

### Special Characters Stay Literal

<Canvas>
  <MarkdownMessageStories.CodeBlockWithSpecialCharacters />
</Canvas>

### No Language Annotation

A fence with no language hint still renders as a real code block — no syntax highlighting, but no corruption either.

<Canvas>
  <MarkdownMessageStories.CodeBlockWithoutLanguage />
</Canvas>

---

## Blockquotes

<Canvas>
  <MarkdownMessageStories.Blockquote />
</Canvas>

### Multi-line

Consecutive `>`-prefixed lines are grouped into a single `<blockquote>`, not one per line.

<Canvas>
  <MarkdownMessageStories.MultiLineBlockquote />
</Canvas>

---

## Tables (GFM)

<Canvas>
  <MarkdownMessageStories.Table />
</Canvas>

---

## Realistic Assistant Response

A full reply mixing several formatting types at once — heading, prose with emphasis, a numbered list immediately after a colon-ended line (no blank line before the list, the way models actually write it), a blockquote, and a table. Modeled on real responses captured from the FDM assistant (Gemini via LangGraph), not a hypothetical example.

<Canvas>
  <MarkdownMessageStories.RealisticAssistantResponse />
</Canvas>

---

## AI Rules

> [!IMPORTANT]
> - This component is used **exclusively inside** `XerticaAssistant` message bubbles.
> - Do not use it for general-purpose Markdown rendering outside the assistant context — use a standard Markdown library instead.
> - Always sanitize content before passing it if coming from untrusted sources.
> - This is a lightweight, regex-based renderer (not a full CommonMark parser) — it covers the Markdown patterns real LLM responses actually produce (see "Realistic Assistant Response" above), not the full spec. Underscore-style emphasis (`_italic_`, `__bold__`) is intentionally **not** supported, to avoid false-positive matches inside plain prose containing `snake_case_identifiers`; use asterisk-style (`*italic*`, `**bold**`) instead.