Custom Components and Plugins Support

[greatsanatanai]

The Idea

Adding a feature for Custom Components and plugins with custom regexes or matchers would be great.

The implementation

Developers could add support of rehype plugins or something similar.

[Simon-He95]

Thanks for the suggestion. Most of the underlying extension points are already available:

Custom components and trusted HTML-like tags through VueRendererMarkdown({ components }), setCustomComponents(), and customHtmlTags.
markdown-it plugins and custom inline/block rules through getMarkdown({ plugin, apply }), registerMarkdownPlugin(), or the customMarkdownIt prop.
Token and AST transformations through preTransformTokens, postTransformTokens, and postTransformNodes.

Markstream currently uses a markdown-it-ts tokens -> ParsedNode[] pipeline because the custom AST carries streaming and renderer-specific state. Adding rehype directly would introduce a second HAST-based pipeline, so it is probably not the right core abstraction.

The remaining gap may be a first-class extension API that:

registers custom syntax or markdown-it token types,
maps those tokens to ParsedNode objects,
maps the resulting node types to local framework components, and
defines how partial matches behave during streaming.

A renderer-local components prop may also make this easier to discover than app-level or scoped registration.

Could you provide one concrete example containing:

the input Markdown,
the custom syntax or matcher,
the expected node data, and
the component that should render it?

That will help determine whether the existing APIs already cover the use case or whether a token-handler/extension registry should be added.

[greatsanatanai]

Yes, certainly.

I want that:

Let us [!!btn!!][Continue][!!btn!!] to chat

Should be rendered to:

<p>Let us <button className="myBtn">Continue</button> to chat</p>

Using a custom function:

function customBtn(str: string) {
const match = str.match(/\[!!btn!!\]\[(.+?)\]\[!!btn!!\]/);
if(!match) return str
const text = match[1];
return (<button className="myBtn">{text}</button>)

I wish this example approach would help you clearly understand my query.

[Simon-He95]

Thanks, this makes the use case much clearer.

The expected output is already a good fit for Markstream's custom-tag component pipeline. We would not recommend overriding the built-in text renderer and applying the regex there.

A text override runs for every text node and may run repeatedly during streaming updates. It also happens after Markdown tokenization, so bracket-based delimiters may already have been split or interpreted by other Markdown rules before the renderer receives them.

The sample function would also require additional logic to preserve the surrounding text, support multiple matches, and handle delimiters arriving across streaming chunks.

The recommended Markstream form is:

Let us <custom-button>Continue</custom-button> to chat

Register the component:

import { setCustomComponents } from 'markstream-vue'
import CustomButton from './CustomButton.vue'

setCustomComponents('chat', {
  'custom-button': CustomButton,
})

Render the Markdown:

<MarkdownRender
  custom-id="chat"
  :content="markdown"
/>

The component can read the dedicated custom node:

<script setup lang="ts">
const props = defineProps<{
  node: {
    content?: string
    attrs?: Record<string, string>
    loading?: boolean
  }
}>()
</script>

<template>
  <button
    type="button"
    class="myBtn"
  >
    {{ props.node.content }}
  </button>
</template>

Markstream parses <custom-button> into a dedicated AST node and dispatches only that node to the registered component. The surrounding content remains ordinary text, without running a custom regex over every text node.

This approach also works better with repeated components, attributes, nested content, streaming states, and the renderer's normal node lifecycle.

If preserving the exact syntax below is a hard requirement:

[!!btn!!][Continue][!!btn!!]

then the appropriate implementation would be a parser-level inline rule that emits the same custom-button node—not a generic regex inside the text renderer.

Could you confirm whether the <custom-button>...</custom-button> syntax satisfies the use case, or whether the exact bracket delimiter syntax is required?

[greatsanatanai]

So, I would have to use a preprocess which converts "[!!btn!!][Continue][!!btn!!]" To

<my-custom-btn>Continue</my-custom-btn>

Am I right?

[Simon-He95]

Yes, the method you mentioned involves replacing the content in the output; another approach is to replace [!!btn!!][继续][!!btn!!] with <my-custom-btn>Continue</my-custom-btn> during the model's context training phase.

[Simon-He95]

Yes — if the exact bracket syntax is required today, preprocess the incoming Markdown before passing it to <MarkdownRender> (not the rendered output):

const normalized = content.replace(
  /\[!!btn!!\]\[([^\]]+)\]\[!!btn!!\]/g,
  "<my-custom-btn>$1</my-custom-btn>",
)

Then opt the tag into the custom-node pipeline and map it to your component:

setCustomComponents("chat", {
  "my-custom-btn": MyCustomBtn,
})

<MarkdownRender
  custom-id="chat"
  :custom-html-tags="["my-custom-btn"]"
  :content="normalized"
/>

For LLM output, you can also instruct the model to emit <my-custom-btn>Continue</my-custom-btn> directly. That is prompt/context guidance rather than model training.

If you need the exact bracket syntax to work incrementally across stream chunks without preprocessing, that is the parser-level inline-rule extension I mentioned; I can turn that into a feature proposal once we have the expected attribute/nesting/error-handling rules.