[FEAT] mermaid diagrams initial support

[rutvik-at-pieces]

[FEAT] mermaid diagrams initial support

[Copilot]

Pull request overview

This PR adds initial support for Mermaid diagrams to the super_editor package. Mermaid diagrams are text-based representations that can be rendered into visual charts, flowcharts, and other diagram types.

Changes:

• Adds MermaidNode class to represent Mermaid diagram blocks in the document model
• Adds MermaidNodeSerializer to serialize MermaidNode instances to markdown code blocks with 'mermaid' language identifier
• Exports the new mermaid.dart module from the super_editor package

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
super_editor/lib/src/default_editor/mermaid.dart	New file defining MermaidNode class extending BlockNode with mermaid diagram content
super_editor_markdown/lib/src/document_to_markdown_serializer.dart	Added MermaidNodeSerializer class and registered it in serialization pipeline
super_editor/lib/super_editor.dart	Exported mermaid.dart to make MermaidNode publicly available

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Missing ComponentBuilder for MermaidNode. Similar block nodes like ImageNode and HorizontalRuleNode include a ComponentBuilder class (e.g., ImageComponentBuilder, HorizontalRuleComponentBuilder) that implements the ComponentBuilder interface. This builder is necessary to render the node in the editor UI. Without it, MermaidNode instances won't be displayed in the editor. Consider adding a MermaidComponentBuilder class similar to the pattern used in horizontal_rule.dart and image.dart, and registering it in defaultComponentBuilders in super_editor.dart.

Suggested change

	}
	}
	/// A [ComponentBuilder] that knows how to render [MermaidNode]s in the editor UI.
	///
	/// This follows the same pattern as other block node component builders, such as
	/// `ImageComponentBuilder` and `HorizontalRuleComponentBuilder`.
	class MermaidComponentBuilder implements ComponentBuilder {
	const MermaidComponentBuilder();
	/// Returns `true` if this builder can build a component for the given [node].
	@override
	bool supportsNode(DocumentNode node) {
	return node is MermaidNode;
	}
	/// Builds a visual component for the given [MermaidNode].
	///
	/// This implementation currently renders a simple box displaying the raw
	/// Mermaid code. It can be replaced with a richer Mermaid renderer without
	/// affecting the rest of the editor integration.
	@override
	Widget buildComponent(
	BuildContext context, {
	required Document document,
	required DocumentNode node,
	required bool isSelected,
	}) {
	final mermaidNode = node as MermaidNode;
	return BoxComponent(
	isSelected: isSelected,
	child: Container(
	width: double.infinity,
	padding: const EdgeInsets.all(8),
	decoration: BoxDecoration(
	borderRadius: BorderRadius.circular(4),
	color: Theme.of(context).colorScheme.surfaceVariant,
	),
	child: Text(
	mermaidNode.mermaidCode,
	style: Theme.of(context).textTheme.bodyMedium,
	),
	),
	);
	}
	}

[Copilot]

Inconsistent metadata initialization pattern. This uses a Map literal with NodeMetadata.blockType as key, whereas HorizontalRuleNode (line 18 of horizontal_rule.dart) uses a string literal "blockType" as the key. ImageNode (line 20 of image.dart) uses NodeMetadata.blockType. For consistency within the codebase, consider using the same pattern as ImageNode which is a similar type of block node.

[Copilot]

Incomplete equality check. The equality operator compares id and mermaidCode but doesn't check metadata, while HorizontalRuleNode only compares id (line 60-61 of horizontal_rule.dart) and ImageNode compares id, imageUrl, and altText but not expectedBitmapSize or metadata (lines 95-101 of image.dart). However, the hashCode implementation (line 95) only uses id and mermaidCode, which is consistent. Consider whether metadata should be included in equality checks for consistency with how copyWith and other methods handle metadata.