The concept of this is clever.

I'll get some time to do a review tomorrow night. But based off the PR description, one comment I do want to make is that mkdocs users are more used to Jinja tags rather than HTML tags.

{%reactpyfile='path/to/file'%}# tag name could just be reactpy

By the way, the tabbed sections are a thing in mkdocs-material.

We could add a Jinja tag, but it may be an unnecessary layer of indirection since the tag would probably just render as a<reactpy-frame> anyway. And yeah, I saw the tabbed sections in mkdocs-material. I just wasn't sure how to use them from within this plugin.

Here's asimilar plugin, except it's designed to inject arbitrary HTML/Markdown.

I wonder if we can just depend on that plugin and just leverage some of its utilities inside ours.

If we end up needing a jinja tag to get the tabbed code examples working then we may as well just use a jinja tag for the simple embedded view as well, even if it's just an alias for the web-component, in order to keep things consistent.

Everything in mkdocs compiles to HTML so we won't need jinja tags to get tabs working.

Jinja tags are more of a creature comfort thing. But I've never seen a mkdocs plugin that makes the user write raw HTML.

Ok, so I don't think this syntax will work:

<reactpy-block><reactpy-filename="main.py"/><reactpy-filename="data.json"/></reactpy-block>

Ultimately this would require me to manually construct the tabs in Javascript. While reverse engineering the DOM structure/classes created by the mkdocs-material tabs is possible, that seems like it would be brittle and a lot of work.

I'm thinking that we could piggyback onsuper-fences. This would allow us to just write:

```reactpyfrom reactpy import component, html, run@componentdef example():    ...run(example)```

Perhaps then, for tabs, one could write:

```reactpy { tab="main.py" }# python code``````reactpy { tab="data.json" }{"some": "data"}```

Where consecutive tabbed reactpy code-fences would be grouped together.

The implementation details are a little unclear to me, butcustom fence formatters do seem to receive the main markdown parser as one of their parameters so I'm hoping that I can just convert the reactpy code-fences into standard markdown and ask it to parse that for me. For example, the tabbed code fences might get transformed into:

=== "main.py"    ```python    # some code    ```=== "data.json"    ```json    {"some": "data"}=== "Preview"    <reactpy-frame file="path/to/main.py" />

Based on ouroriginal plan from half a year ago, we were considering doing the embeds viamkdocs-macros-plugin.

I thinkmkdocs-macros would be the cleanest option overall.

The advent ofthis pyscript demo means we can take an entirely different approach to running live examples in our docs.

A macro that poops out a pre-generated pyscript template would be pretty simple to make.

The template tag usingmkdocs-macros would look like this:

{% reactpy "../../examples/thinking_in_react/build_a_static_version_in_react" %}

Ifbuild_a_static_version_in_react isn't a folder, we should use pre-defined tab names. For example:

=== "app.py"```pythonPYTHON CODE GOES HERE FOR "../../examples/thinking_in_react/build_a_static_version_in_react.py" IF IT EXISTS```=== "styles.css"```cssCSS CODE GOES HERE FOR "../../examples/thinking_in_react/build_a_static_version_in_react.css" IF IT EXISTS```=== "data.json"```cssJSON CODE GOES HERE FOR "../../examples/thinking_in_react/build_a_static_version_in_react.json" IF IT EXISTS```=== ":material-play: Run"PYSCRIPT CODE GOES HERE. FOR PERFORMANCE, PYSCRIPT CODE SHOULD NOT RUN UNLESS THIS TAB IS CLICKED.

If"../../examples/thinking_in_react/build_a_static_version_in_react" is a folder, we should create tab names based on the files within that folder, rather than generics names.

Inside of python files it should automatically look for any# start and# end. If they exist, truncate the code block.