The X in MDX


Markdown is great for content-driven sites. MDX is even better, letting you embed interactive components directly from your markup. It's usually used for the same linear layouts you often see on many blogs, readmes, and documentation sites. But it doesn't need to be like this.

In this talk, we'll see how to reshape MDX so we can use it for very different layouts, things like scrollytelling, slide decks, and more.


♪ Let's start with this Markdown file. I'm assuming we all know Markdown. There's a reason why it's so popular. It has a very clean syntax. I'm sure I'm not the only one who likes to move as much content as possible to Markdown. Even content that doesn't originally belong to Markdown. And that's why we have MDX, right? We had to extend the original format so we could put more things on it. In this talk, we'll take this to the extreme. We'll use MDX for more unusual content and layouts. But first, I need to show you how this works. We're going to start with this small react app. This is using next.js, but the same applies to any app that has the MDX loader. Most of the magic comes from this import. Here, the MDX loader transforms the Markdown file into a react component that we can use anywhere. And you can see it renders what you expect here on the right. If we want to change what's rendered, we can use the MDX provider component. It has a component prop that lets us override any of the default components. For example, here we are changing all the H1s and adding a purple border. A special component we can override is the wrapper. The wrapper is the component that wraps the content. Here we are just adding a border to it. But the cool thing about this component is that in the children prop, we get all the content from the Markdown file as react elements. react elements are just javascript objects. Here you can see what's inside the children prop. We are rendering the wrapper children as JSON and filtering some properties to make it easier to read. You'll see that it is an array. The first element is an H1, the second a paragraph. Each element comes with an MDX type. We will use that MDX type to extract information about the content or to change the elements. For example, we could get a list of all the H1s from the children and render it as a table of contents. This is a simple example, but it illustrates the pattern we are going to use on the rest of the examples. In all of them, first we extract some data from the children and then we render it in a specific way. Keep in mind that this runs on every render. In most cases, it isn't a performance problem, but if it is, you can move it to a plugin and run the transformation on build time. I usually write content that has steps, like tutorials or any type of walkthrough where you explain something step by step. Markdown doesn't have any specific syntax for grouping things in steps, but we can use MDX to extend Markdown and introduce our syntax. The implementation of the step component we are using here doesn't matter, we are just using it for grouping elements. If you are new to MDX, this may not be the best introduction. The typical use case for MDX is embedding interactive components in Markdown, but here we are taking a different approach and using it more as a syntax extension for Markdown. Now, based on the MDX file that has steps, we can write another wrapper component. In this case, in the children prop, we get one react element for each step. So we can keep track of what step we are showing using react state and let the user change the current step with a button. Ok, now I want to show the same content but with a different layout. There is a technique called scrollItaling, you might have seen it on some websites. As the user scrolls down, there is some part of the layout that sticks to the screen while the rest scrolls away. So let's do that. Since this is a lightning talk, I'll import the scrollItalingLayout component. I'll share the link to the repo later if you want to see how it works. The scrollItalingLayout component takes two props, one for the left side that can be scrolled and the other for the sticky part on the right. When the user scrolls to a new step, we show the corresponding element from the sticker list. Now, instead of showing the step number, let's add the sticker content to the MDX file. Suppose we want to show some code in the sticky part of the layout. There isn't any specific syntax for this, so we need to create our own convention. Like for example, we put the sticky part of the step as the first element. Now, doing some array transformation, we get the list of steps and the list of stickers and pass them to the same layout component. So when the user scrolls, the code on the right should change accordingly. Just for fun, I have a terminal component that animates between code transitions, so we can use it for the stickers. I've been experimenting with another layout for walkthroughs. Instead of changing the steps using the scroll, like in this example, we can synchronize the steps with some media, like a video or an audio, maybe a podcast, and change the steps as the media progress. To do that, in the MDX file, we need to specify the media file and the time range for each step. Once we have that, we can extract the information from the children on the wrapper and pass it to another react component. This time it's the TalkLayout component that will solve all the syncing for us. And you should see the steps changing every time I snap my fingers. Some of you might have noticed that this looks similar to the layout of this talk that I'm giving right now. And it is! This talk was built using the same technique. It's all MDX. For example, here on the left, you can see the code for the steps you are currently watching. And here is the next step. And that's all. That's all I have. The takeaway is you can use MDX to build your own dialect tailor for any specific layout. I leave you here the links to the repo of the talk. Not the slide, but the talk itself. You run yarn dev and you can watch this talk again. Also, there's my Twitter and the components we used. Most of them come from a new project I'm working on. It's called CodeHike. And it focuses on code walltrusts and tools for making it easy to explain code. Thank you.
10 min
17 Jun, 2021

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic