building my new portfolio with next.js

why?

When building out the most recent version of my portfolio, about two years ago, I was prompted to try a low-code solution for presenting projects that wouldn't be difficult to update. An optimal solution presented itself in Google Sheets, as v3 of the program exposed a JSON API to send the data from a spreadsheet. However, unbeknownst to me, this feature was torn down, and all of a sudden my projects were no longer presentable.

While it was tempting to spin up an API that presented the projects, creating a CMS didn't seem like the most efficient solution; the React build was from a much earlier version of React, so the front-end needed a fresh coat of paint as well. With both sides of the site needing another approach, I decided to recreate the project in Next.js.

why next.js?

I'd found out about Next.js from some colleagues and ended up investigating their docs after watching a video on the Next.js 12 conference. Having worked with Gatsby.js before, my initial reaction was that this was a better-wired version—the routing was more intuitive, the plugins and image optimization were easier to work with, and the build time was lightning fast.

One of Next.js' greatest advantages is the ability to make static content as well as dynamically create pages from a variety of different formats, most notably Markdown. As an avid user of Markdown for lesson writing in my instructional career, it seemed like an ideal format to convert into HTML pages.

The work on the site was then divided into two parts: handling the galleries of work and projects kept in .json files, and creating the blog page with static pages for each entry.

approaching work and projects

The work / projects pages are almost identical, with the exception of work not necessarily having both a repository and a live hosted site. With that in mind, a 2-column grid layout for both pages, with immediately accessible links seemed best. In my previous portfolio, I added a few too many microinteractions, and for this, the only ones that are added are on links or alternative links (i.e. hiding a link around an image).

At first, it was tempting to set up an API endpoint to fetch the different projects and their information. However, after some consideration both to Next.js and the use of APIs for this project, it seemed that keeping the projects within a .json file locally was the most helpful approach for this.

There wasn't a lot to add with this phase of building out the site, but as I add more work / projects, I intend to add a filter bar at the top to filter different types of projects by technology / stack. With the work and projects pages done, I set out to create the blog and markdown converters!

developing the blog

Creating the initial page builder only involved sourcing markdown and choosing a bit of styling. Apart from development, I am mostly a mobile user of the internet, so it made the most sense to structure the blog in a mobile-friendly format. That, combined with a bit of YAML frontmatter, made it convenient to create the necessary metadata for any of the blog entries to display information.

The Markdown was a bit more of an interesting problem, as some of the assets that were being sanitized wouldn't be rendered—namely the images. It turns out that sanitize-html natively removes all img tags unless specified, and after a brief hunt through GitHub issues, it was a quick fix to get them on the page.

The last item on my list was sorting the pages by creation time. My first response was to sort by created date in the metadata, but sometimes the silly solution works best: adding a 3 digit entry code (e.g. 001, 002) to the beginning of each blog entry file name. Once again, the least complicated solution proved to be the best.