stephen.news

hypertext, words and more

Gatsby

  • Refactored and Re-loaded

    •

    3 min read

    •

    It’s a tough business to manage a website.

    Between, the pandemic, looming anxiety, and a medically necessary surgery to repair my right knee (more on that later), it seems I’ve left my website in a sorry state for a few months now. I migrated my website to a static infrastructure thanks to Gatsby and Netlify earlier this year. I’ve largely been really happy with this setup of publishing in WordPress, and triggering Netlify page/post generations via a web hook. The pagespeed score alone was incredible. I could sing praises all day long, but what I want to write about today, is refactoring.

    I let my v1 repo sit untouched for roughly 8 months. Yikes. I had plenty of errors and was hastily written. It was not typed at all, and was largely a mess. I decided to get serious, and wrote a list of must-haves for a v2:

    • Typescript baby
    • styled-components
    • Better support for more post types (such as bookmarks or projects)
    • More effective linting setup and better error handling
    • Client-side Apollo-powered GraphQL queries for bookmarks and dynamic content where possible (such as comments, coming later)
    • DRY out the code base, and remove unused dependencies
    • More effective theming approach

    A tall order indeed. However, it was possible! I powered through it, and renamed my .js files to .ts and .tsx and largely followed Gatsby’s own provided typescript example, which was really helpful when it came time to debug build-time errors locally. As I was working on this refactor, I scoped out Brian Lovin’s website and just fell in love with the feed/timeline style he uses to organize his bookmarks. So, naturally, I took great inspiration from him to build something similar:

    I’m pretty pleased with the results. I’ve wanted something like this for a very long time. So, I want to take a moment to thank Brian for open sourcing his site (although his site is powered with next.js, it was an inspiration none the less). It paved the road for me to investigate a path forward building a similar suite of components using Apollo Client and wp-graphql.

    Ultimately, the list of changes and new features led to this nightmare diff (mostly configuration and newlines to get typescript working):

    😳

    But it built successfully, and I was happy to finally have Typescript at the ready.

    Up next, I will be finally adding back the commenting ability to my blog posts (and maybe setup a proper site search?). After that, I’ll probably add some portfolio and personal work. But, until then I will be resting comfortably sipping IPAs and mulled wine during this holiday, playing video games and pampering my two buds, Frank and Kevin:

    Merry Christmas!

  • New site, who dis

    •

    4 min read

    •

    I haven’t developed a new WordPress theme for this website (that I really loved) in a long time. So naturally, it was time to re-examine my personal tech stack. If you personally know me, you know I’m a WordPress advocate. Big fan of ol trusty.

    There’s a few problems with WordPress I’ve been hung up on for a while now. It can be a bit slow (sometimes). Media managing can be painful on the front-end. Deployment processes are… all over the place. Historically, I’ve been a huge fan of Trellis from Roots. While we’re at it, I was a big fan of Bedrock too. Finally, I work with React and JavaScript all day long — why can’y my personal website run on a modern tech stack too?

    Well, I came across this post from Chris Coyier, and I was pretty much sold on the JAMStack concept immediately. At work, and at other organizations like Twitter, server-rendered pages are stupid fastest. Heck, they’re typically standard these days for most web apps. Enter the Gatsby + WordPress stack. Why abandon years of publishing paradigms when you can keep them?

    There’s no shortage of tutorials on the Gatsby + WordPress setup. Initially I played around with some starter projects, like this one. I personally started (and later forked) with egghead.io’s starter. It’s pretty spectacular out-of-the-box, and if you enjoy love @emotion theming or styled-components, I think you’ll dig too. But, really Gatsby itself has a lot to love. For example, Gatsby has drop-in support for server-rendering. Super cool stuff. I really enjoyed Juliano Rafael’s (@frontendwizard) notes on this subject:

    Progressive image loading? Inlining of critical CSS? Painless PWA configuration? You name it, Gatsby got you. It is really impressive. Don’t believe me? I encourage you to try it out.

    The solution for images is so good, that is constantly referred as a strong point of Gatsby, even thought it actually is a plugin. All you gotta do is add a couple of plugins into your Gatsby config file and you’re good to go. Your images will be available on the GraphQL API at build time and the image component will handle all the resize, picking the best file format and everything else. You even get a blur up effect to improve the user experience for free.

    That’s just the tip of the iceberg. Seriously. These web apps freakin purr. I’m overdue for writing a full tutorial on this subject, so stay tuned. But, for now I want to share a high-level overview of the technical lift I undertook for my site migration.

    My order of operations (yours might be slightly different):

    Now that we have our API-site prepped for deploy-hooks, exposed the frontpage and menus endpoints — we’re ready to consume the API with our server-rendered React app powered by Gatsby. Here’s a sample of my gatsby-config.js file:

    ...
resolve: `gatsby-source-wordpress`,
options: {
  // Your API WordPress source goes here.
  baseUrl: `example-api.https://stephen.news`,
  protocol: `https`,
  // Fetches posts, tags, categories, etc from the baseUrl.
  includedRoutes: [
    '**/menus',
    '**/categories',
    '**/frontpage',
    '**/media',
    '**/pages',
    '**/posts',
    '**/tags',
    '**/users'
  ],
  useACF: false,
},
...

    I absolutely love this setup.

    All of the un-fun configuration stuff is already handled by the WordPress/WP REST API side, and all of the actually fun conventional interface building is done on the… well, the interface side. A complete separation of church and state, if you will. It’s a thing of beauty. Absolute zen.