<p>
that are provided by Web Browser, JSX allows you to use “react components”, e.g. <HelloComponent>
. Since JSX almost looks like HTML, it is easy to use compared to JavaScript, and is also quite familiar to people who understand HTML. HTML is easier to learn than JavaScript. So this gives a lot of JavaScript power without having to write JavaScript.
So what is MDX? MD of MDX refers to Markdown, and X is from JSX. MDX lets you write Markdown and JSX in the same file.
**Hello**, world! Below is an example of markdown in JSX. <div style={{padding: '1rem', backgroundColor: 'violet'}}> Try and change the background color to `tomato`. </div>
**
around “Hello” will make it appear as bold text, this is Markdown. And <div>
is a JSX syntax for creating a “div”.# mdsvex svelte in markdown <Penguin walk={true} />
.mdx
or .svx
is not the same as the language in which you write the actual component implementation. To write a new React component you have to switch to JavaScript:
class ShoppingList extends React.Component { render() { return ( <div className="shopping-list"> <h1>Shopping List for {this.props.name}</h1> <ul> <li>Instagram</li> <li>WhatsApp</li> <li>Oculus</li> </ul> </div> ); } } // Example usage: <ShoppingList name="Mark" />
Similarly to create a new svelte component you have to write something like this:
<`script`> let name = 'world'; </`script`> <h1>Hello {name}!</h1>
The authors have to completely switch the language when they are creating any component. And this is not a simple switch. Markdown is the base language of either of these technologies, mdx and svx, and Markdown is really easy to learn. Then you learn the HTML like syntax and add some components. HTML syntax is also quite easy to learn.
But to create even the simplest components you have to switch to JavaScript and JavaScript is a full blown programming language. And it’s not just JavaScript, React or svelte are quite non trivial learning curves on their own even if you know JavaScript.
Having to deal with two completely different languages, two languages whose learning curves are drastically different (how many people in your company can learn MDX/SVX? Maybe everyone. How many can realistically learn enough React to create components? Not even the entire software team.) means the expressive power available to authors is constrained by what is provided as existing components, if someone arrives at even slight variation to some component they have to either know JavaScript or they have to create a support ticket.
We have been creating largely static documentation. But if some powers are given authors and creative people a lot can be created, but is not possible today because of upwards battle of learning JavaScript.
\--- layout: blog \---
import MyLayout from './MyLayout' <MyLayout> # Hello This section has custom styles </MyLayout> This part of the document uses default styles
<TeamMember>
component, else with Markdown you will have a very boring presentation. Now even if someone has anticipated your need and created the <TeamMember>
component, there are going to be difficulties. If you want to specify more than one attribute for team member with prose in it.
<TeamMember name="Some Name"> Bio of the member. </TeamMember>
role
where you want to use multiline text, it would become ugly.<TeamMember name="John Doe, \"JD\"" role="She is the customer success person and is responsible for timely handling of support queries etc." > Bio of the member. </TeamMember>
You can always do something like this:
<TeamMember> <Name>Jane Doe, "JD"</Name> <Role> She is the customer success person and is responsible for timely handling of support queries etc. </Role> <Bio> Bio of Jane. </Bio> </TeamMember>
But there is a much bigger problem. Here the order in which name, role and bio are displayed are decided by the author. In this case the name will show before role and bio in the end.
One can create hacky components that will do either parsing or run time DOM traversal to extract and tweak things, but it will mess with React’s virtual DOM rendering, and is not the React natural way of doing things. You can find a huge collection of React libraries, but none are used like this.
We want to pass clean data to the end component and let components figure out how to render them.
team-member
we could have a syntax like this:-- team-member: Jane Doe, "JD" role: > She is the customer success person and is responsible for timely > handling of support queries etc. Bio of Jane.
If you are going to show Jane Doe in more than places or pages you can easily create a component:
-- team-member jd: Jane Doe, "JD" role: > She is the customer success person and is responsible for timely > handling of support queries etc. Bio of Jane.
jd
component anywhere:-- jd: