INDEPENDENT BUILD / DESIGN + ENGINEERING

MRoot.co.

One place to write.
Two ways to explore.

One authored collection for a conventional portfolio and an IDE-style interface.

Explore the build Read the engineering story

01 / THE AUTHORED RECORD

project.md

title: MRoot.co
content: shared
views: two

ILLUSTRATIVE METADATA

02 / WEBSITE

Same story.
Different view.RENDERED FROM THE SHARED RECORD

03 / IDE PRESENTATION

▸ projects
  └ mroot.md

# MRoot.co
One source. Two views.

Explanatory composition, not a production screenshot or project source-code capture.

Documented project~2 min read

My contribution: Design, engineering
& deployment

Context: Independent portfolio
June 2026 implementation

Built with: React · TypeScript · Vite
Markdown · vite-react-ssg

01 / THE BUILDDifferent interfaces should not mean duplicate content

MRoot’s website and IDE mode present the same projects and articles in different ways. One is a conventional portfolio. The other uses a file explorer, tabs, terminal, and command palette.

I did not want two copies of each project to maintain. The content lives in Markdown and YAML, and both presentations read the data produced from those files.

02 / THE BUILDEdit once, change both presentations

A build-time Vite plugin reads the content, parses its frontmatter, and emits a data module. The application imports that module through a shared data file.

The small editor below demonstrates that relationship. Change the sample title or summary and both views update. It is a local explanation of the idea—not the real MRoot editor, a production preview, or an actual Vite build.

EDIT ONE LOCAL RECORD

Two views. One source.

example-project.md ILLUSTRATIVE INPUT

Project title 80 characters maximumSummary 220 characters maximum

ONE SHARED RECORD

WEBSITE PRESENTATION

A portfolio, two ways

A shared content collection, presented as a website and an IDE-style interface.

ILLUSTRATIVE PROJECT CARD

IDE PRESENTATION

01title: A portfolio, two ways02summary: A shared content collection, presented as a website and an IDE-style interface.03# Same data. Different rendering.

METADATA, NOT PROJECT SOURCE CODE

This example stays in this page’s memory. Nothing is saved or sent.

A local demonstration of shared data—not the real MRoot editor, a production screenshot, or an actual Vite build. Empty input gets a visible fallback.

03 / THE BUILDDo the parsing before the page reaches the browser

In the documented build, virtual:content exposes the compiled data. A Markdown parser is not shipped to the browser for this content pipeline. Pages use the same exported arrays in website and IDE mode.

The build prerenders routes with vite-react-ssg, then generates a sitemap and 404 page in a postbuild step. The original deployment went to Cloudflare Pages on push.

FOLLOW THE CONTENT

Parse before the browser.

01 / AUTHORED CONTENT

Markdown + YAML

Projects and writing start as content files, not duplicated records for each interface.

Read the complete pipeline

Markdown + YAML: Projects and writing start as content files, not duplicated records for each interface.
Vite plugin: The plugin reads content and frontmatter and emits the virtual:content data module.
Shared exports: src/data.ts re-exports the generated data for the website and IDE views.
Prerendered HTML: vite-react-ssg prerenders routes. A postbuild step writes the sitemap and 404 page.

Conceptual walkthrough of the June 2026 implementation. No compiler or deployment runs here. Deployment on push is described in the article, not triggered by this figure.

04 / THE BUILDKeep the link, change the presentation

The documented router maps a pathname to the file identifier used by IDE mode. A project path can point to the same work in either presentation, rather than requiring separate public URLs for the two interfaces.

The visitor’s mode preference is stored in localStorage. The preference chooses how to view the content; it is not another copy of the content itself.

05 / THE BUILDThe parts I would revisit

The original IDE project code window was generated from frontmatter, not taken from the project’s source. That distinction needs to be visible. A generated preview is not evidence of how the underlying project was implemented.

The original write-up also identified a large App.tsx view-model and no automated test around the content plugin. Splitting the view-model by surface and checking frontmatter before the build were proposed improvements, not completed work in that account.

Source, dates, and what this page verifies

This is an editorial rewrite of the supplied project and technical article, describing the account published June 27, 2026. Original dates, code excerpts, and unfinished work are retained. The production repository, permissions, costs, and historical measurements have not been re-audited.

Interactive figures are local explanations. They do not call an API, send input, create content, or demonstrate production test coverage. The cumulative reference is not deployed.