mui / mui/material-ui

[docs-infra] Reuse md files for both docs pages and GitHub exploration

Open
#38,065 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

scope: docs-infra scope: toolpad
Dominant language
JavaScript
Stars
99.1k
Forks
32.5k
Avg merge
2d 17h
Merged PRs (30d)
106

Description

Wondering what is the way to go in cases when we want to reuse .md files that we write for the docs which contain "our" custom syntax.

For example, we reuse the .md file that powers this docs page: https://mui.com/toolpad/examples/admin-app/ as a README.md here: https://github.com/mui/mui-toolpad/blob/master/examples/admin-app/README.md

TL;DR: Problem: To allow .md files reusability. Solution: For the docs markdown parser: Parse custom syntax within comments, and add a directive to ignore lines. (edited)

Option 1 - Use comments

One idea is to potentially allow parsing any custom syntax within comments, so:

{{"component": "modules/components/DocsImage.tsx", "src": "/static/toolpad/marketing/admin-app.png", "alt": "Admin application", "caption": "A CRUD application"}}

could become:

<!-- {{"component": "modules/components/DocsImage.tsx", "src": "/static/toolpad/marketing/admin-app.png", "alt": "Admin application", "caption": "A CRUD application"}} -->

and still be parsed by the docs markdown parser, but ignored when rendering plain markdown.
And, for the other way around, we could add a directive like:

<!-- mui-markdown-ignore-start -->
![screenshot](/static/toolpad/marketing/admin-app.png)
<!-- mui-markdown-ignore-end -->

allowing us to add lines to the .md that don't get parsed by our parsers.

Option 2 - Use a cusomized <img />

If the problem only concern the images, we could use special renderer for <img /> tags in the docs, and let GitHub handle them by itself

Mark <img/> as special sections

--- a/packages/markdown/parseMarkdown.js
+++ b/packages/markdown/parseMarkdown.js
@@ -161,6 +161,7 @@ function getContents(markdown) {
     .replace(headerRegExp, '') // Remove header information
     .split(/^{{("(?:demo|component)":.*)}}$/gm) // Split markdown into an array, separating demos
     .flatMap((text) => text.split(/^(<codeblock.*?<\/codeblock>)$/gmsu))
+    .flatMap((text) => text.split(/^(<img.*?\/>)$/gms))
     .filter((content) => !emptyRegExp.test(content)); // Remove empty lines
   return rep;
 }
@@ -560,6 +561,11 @@ ${headers.hooks
             storageKey,
           };
         }
+        if (content.startsWith('<img')) {
+          return {
+            type: 'image',
+          };
+        }
 
         return render(content);
       });

Render them with React component instead of static HTML

--- a/docs/src/modules/components/MarkdownDocs.js
+++ b/docs/src/modules/components/MarkdownDocs.js
@@ -115,6 +115,13 @@ export default function MarkdownDocs(props) {
               </Wrapper>
             );
           }
+          if (renderedMarkdownOrDemo.type === 'image') {
+            return (
+              <Wrapper key={index} {...(isJoy && { mode: theme.palette.mode })}>
+                <DocsImage {...renderedMarkdownOrDemo.props} />
+              </Wrapper>
+            );
+          }
 
           const name = renderedMarkdownOrDemo.demo;
           const demo = demos?.[name];

One limitation is that images should be stored in a way that can be handled by both the docs and GitHub. So src should be a static url, not a url generated by nextJs or whatever JS magic

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading packages/markdown/parseMarkdown.js and docs/src/modules/components/MarkdownDocs.js to understand the current markdown parsing and rendering paths. Compare the proposed comment/directive and image approaches against the example README and docs page, then confirm the intended design. Done means a documented, tested way to reuse the same .md files in GitHub and the docs without breaking custom syntax.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, markdown
Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.