Add Custom Blocks/Components
As an Author,
I want to have access to existing datasets inside the content editor, for example internal pages to link to,
To lower the potential of error and dead links.
As a Template Designer,
I want to render strongly typed blocks
So that I don't need to implement parsers that are error-prone and hard to implement.
As a Database Admin,
I prefer typed data over flat markdown files (strings)
Because they allow me to add relations and GraphQL queries.
As the Developers and Authors,
We want the build process to fail if content addresses stale data or types instead of runtime errors
So that we can fix the inconsistencies before they get public.
Earlier discussion concerning "Markdown Blocks"
Astro Components may extend the core markdown blocks. I have been using an extensible markdown interpreter in Elm (for example on flupsi.com/multimedia) with great joy because it's so easy to implement new parsers. This is how it works:
- Any tag
<x a=b>c</x>
is valid markdown and will be rendered as Html into the browser DOM. - Default tags
<p style="text-align:center">..</p>
render as what they are. - Custom tags such as <weather when="today" /> are also valid in markdown, and directus offers the option to define such custom tags in its default markdown editor.
- By default, custom tags are rendered as such. Visually, the browser handles them like <span>s, iirc.
- A parser extension needs to be defined that catches certain custom or default tags and renders them in a specific way before the Markdown is converted to Html.
Example Blocks:
Date, TOC, interactive e-mail, Contact, popover md content, clickable "related terms/tags", Diagram, Code block with language-specific highlighting...
To research or try out:
-
What is the most common or useful way to interprete any tag <x a=b>
as meaningcomponents/x.astro
with the Astro.props being `[a=b]`? --> that would be Markdoc, which has a very comfy-looking Astro integration -
A mistyped tag would result in either a build failure or gibberish Html, both of which are suboptimal. How early can we validate (or parse?) the markdown, how do we want to communicate errors to the author, and how can a markdown editor know the types of Astro components? -
Or would we implement and render an .md editor in the Astro frontend instead of directus, such that it compiles with the latest component schema? -
More generally, do we ever want the Astro-generated frontend to send any edits upstream to directus, or do we prefer a strict one-way street?