Another year, another chance to rebuild my website from scratch. Developers are nothing if not predictable 😉.
The tech behind this site
Enough of that, though—on to the juicy stuff, some of the interesting things behind this rebuild. The lion's share is nothing groundbreaking … it's a pretty bog-standard Next JS site. I am excited for one thing, though: MDX with inline React component support 🎉!
All articles are written in GitHub-flavored Markdown using
remark-gfm. This isn't interesting by itself—Next has first-party support for MDX—but I didn't want MDX files littering my
pages/ directory. Instead, I wanted the following (for tidiness's sake):
- All articles live in the
- During Next JS's build step, articles get compiled to static pages based on their written date, with the url scheme
Since I didn't go the "traditional" route (adding
.mdx files directly in the
pages/ directory), there was a bit more setup involved:
- Add a
[...slug].jsfile to the
- In the
getStaticPathsthat builds URLs with the expected parameters of
[year]/[month]/[day]/[slug]based on each markdown file's metadata using
gray-matterto parse the metadata
This separation of concerns keeps my page-specific development separate from my blog posts—not a huge deal, but it's all about the developer experience.
Speaking of developer experience, one of the features I really wanted in my articles was React component support in markdown. This can allow for inline demos alongside code snippets.
Hashicorp has a module called
next-mdx-remote that allows for loading React components directly into MDX via
getStaticProps, but it only supports importing components globally (across all
mdx pages). This is likely fine for most people, but I wanted to be able to import only specific components for each
mdx file for one-off components to pepper into demos.
To that end, I utilized Kent C. Dodd's
mdx-bundler. This library compiles and bundles MDX files, as well as their dependencies, ad-hoc, allowing for bundling dependencies on a per-file basis.
Getting all this set up was not the most straightforward—a con of having so much flexibility means, "no one true way of doing things," which leads to cobbling bits and pieces from many different places. However, the pro outweighs this con, as I have a comfortable writing experience alongside an intuitive way to drop in React components when the occasion arises.
If you're interested in how all of this is wired up, feel free to check out the codebase for this site here: https://github.com/dstrunk/danielstrunk-me