JavaScript


I recently decided to fully rebuild my blog from the ground up using Next.js. By default, there's no built-in support to auto-generate an RSS for blog posts like there are in so many starters for Gatsby. As such I needed to roll my own.

Ultimately, an RSS feed is just an XML file that gets updated with new entries as new posts are made. Lucklily, we can take advantage of the fact that committing a new blog post will trigger a new build of the site. Using that, we can update the build command in our `package.json` to run a node script before our actual build like this:

<Code language="json">
{`"scripts": {
	"build": "node ./buildFeed && next build",
},`}
</Code>

Now we just need to update our `buildFeed.js` (which lives in our root directory) to create a new XML file when it's run. To do that I'm going to use 3 packages: `fs`, [`rss`](https://www.npmjs.com/package/rss), and [`next-mdx`](https://www.next-mdx.org/).

<Code language="javascript">
{`const fs = require('fs')
const RSS = require('rss')
const { getAllNodes } = require('next-mdx');`}
</Code>

First we need to create a new RSS feed.

<Code language="javascript">
{`const feed = new RSS({
	title: 'My Blog',
	site_url: 'https://my-blog.com'
});`}
</Code>

Next we need to get the blog posts to load into this feed.

<Code language="javascript">
{`const posts = await getAllNodes('post');`}
</Code>

Then we need to iterate over our posts and add them to our feed.

<Code language="javascript">
{`posts.forEach(post => {
	feed.item({
		title: post.frontMatter.title,
		guid: post.slug,
		url: 'https://my-blog.com/post/' + post.url,
		date: post.frontMatter.date
	});
});`}
</Code>

Now we have our feed built out, we just need to generate the XML and write it out to a file.

<Code language="javascript">
{`const xml = feed.xml({ indent: true });\n
fx.writeFileSync('public/rss.xml', xml);`}
</Code>

This will write our `rss.xml` file to the public folder of our Next.js app so that it will be at a publicly available URL at `https://my-blog.com/rss.xml`.

[See the gist for the full code](https://gist.github.com/arkmuntasser/7d73909b3c7d7cc8f61c915f1df1b65f).


Creating an RSS feed with Next.js and Next-MDX


Recently, I came across the following post on Twitter:

<TwitterTweetEmbed
  tweetId={'1108290606458175489'}
/>

It became known as the _Impossible Layout_ with many concluding that it couldn't be done with just CSS. Of course, I had to tackle it. In the end I came up with 2 solutions. One is a pure CSS solution, but it has a relatively minor caveat and the other requires a bit of JS, but no caveats.

## Solution 1 - Pure CSS

Looking at the layouts I saw there were three uniformly-sized images and an arbitrary amount of text. I also know that all the elements involved are siblings of each other and not three containers each with their distinct image and text, otherwise, the larger layout wouldn't be workable. And since the items are all siblings and I need to move things in 2 dimensions that I will be needing CSS Grid at some point.

Let's elaborate on that last point.

Going back to the small layout, everything is in a single column and intermixed. On the large layout, there are clearly two columns with the text on one side and images on the other. So that explains needing to manipulate the elements in one direction, horizontally. Also on the large layout, the text all sits snug together without large breaks between them where an image used to be so that means Ii'll need to move them vertically as well. And if you're working with two dimensions in CSS, then you're likely to be wanting CSS Grid to keep things tidy.

To begin, let’s create our grid container and move everything in it to the second column. And then move just the images over to the first column.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - CSS Grid only"
  src="//codepen.io/arkmuntasser/embed/eXboKv/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/eXboKv/">
    Impossible Layout - CSS Grid only
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

Now we're getting somewhere! This is starting to look like the large layout we want, but there are rows between the images when they should be immediately under each other and the height of the images are causing the rows to be too tall in some instances.

To fix this, we're going to set the `position: absolute` on the images. This will allow the text on the right to sit comfortably without the images effecting the row height. But with now the images are stacked on top of one another.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - CSS Grid + Absolute Positioning"
  src="//codepen.io/arkmuntasser/embed/MxZRZJ/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/MxZRZJ/">
    Impossible Layout - CSS Grid + Absolute Positioning
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

This is where the caveat comes in with this method. Because I am assuming the images are uniform in size, I can translate the images reproduce the desired layout. For this, I am also going to assume that you as the developer or the CMS have some way of knowing how many images there are and which number each image is. Why? So we can set an inline CSS variable (CSS Custom Property) on the images. This will let us write a very simple rule in our CSS to enable support for an arbitrary number of images.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - CSS Grid only"
  src="//codepen.io/arkmuntasser/embed/YgdMgd/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/YgdMgd/">
    Impossible Layout - CSS Grid only
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

Finally, we can add a little extra CSS for some better styling and a media query go back to the small layout.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - Final"
  src="//codepen.io/arkmuntasser/embed/YgdbKg/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/YgdbKg/">
    Impossible Layout - Final
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

And you're done!

![](https://cdn.glitch.com/2caac55b-1244-4a5a-9e9c-6389d180ccf7%2Ftenor.gif?1553317759077)

## Solution 2 - What about images of varying sizes?

Not quite.

What if you want to have images of different sizes? Or what if you can't know how many images there are or the index of each image? Then we're going to need a little JavaScript to help out.

What we need to do is find every image in the grid and as we loop over them keep a rolling sum of their heights and set a CSS variable on the images with the current height total. Then in our CSS we can simple translate the image by that amount.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - Solved!"
  src="//codepen.io/arkmuntasser/embed/PLXvWP/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/PLXvWP/">
    Impossible Layout - Solved!
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

With this, you can have an indefinite number of images, an indefinite amount of text, and images of varying sizes. Not so impossible after all.


How I Solved the Impossible Layout


The other day I was thinking back on the my early days building small games with [RPG Maker](https://www.rpgmakerweb.com) and I was thinking about all the cool sprite sheets I would download and make. I wasso fascinated by sprite sheets and how you could get such complex animations with relatively little. Of course, now that I'm grown up and understand quite a bit more about animation and film in general I know that those sprite animations weren't all that technically advanced. But that doesn't mean I'm any less enamored with them.

I was curious how easy it would be to load a sprite sheet an animate on the web. Turns out it's super easy, barely an inconvenience. Check out my sweet animation:

<Embed src="https://glitch.com/embed/#!/embed/sprite-animation?path=README.md&previewSize=100" title="sprite-animation on Glitch"/>

To create the animation I need to know 2 things: how many individual spites make up the animation (or frames in the animation) and the dimensions of each sprite.

First, I'm going to create a box that is the dimensions of a single sprite and set it's `background-image` to out sprite sheet.

<Code language="html">
{`<style>
	#sprite {
		display: block;
		width: 80px;
		height: 80px;
		background-color: #333;
		background-image: url('https://cdn.glitch.com/f39fa1a5-5693-46f3-ba29-dd9d43879a63%2Fsonic-walk-cycle.png?v=1614057158459');
		background-position: 0 0;
		background-size: auto 100%;
	}
</style>\n
<div id="sprite"></div>`}
</Code>

Next we're going to animate this using the [Web Animations API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API). Why use the Web Animations API here instead of just writing the animation in CSS using `@keyframes`? Well, I've never used the Web Animations API and wanted a chance to play with it a bit. This could totally be done with just CSS as we'll discuss further down. Thankfully, unlike of JS-based animations, the Web Animations API is optimized in the browser and is as peformant as a CSS animation. So you can safely use either depending on which works best for your situation.

Here's what that code looks like:

<Code language="javascript">
{`const keyframes = new Array(numFrames)
  .fill(0)
  .map((x, i) => ({ backgroundPosition: (i * -1 * frameWidth) + 'px 0' }));\n
sprite.animate(keyframes, {
  easing: 'steps(' + numFrames + ', jump-none)',
  duration: 400,
  iterations: Infinity
});`}
</Code>

And boom, you're done! Behold as your sprite comes to life; you might need to adjust the easing and duration until it looks right. And with little tweaking, this can work for any sprite of any size and any animation of an complexity as complexity is merely the number of frames.

But how practical is something like this? Well, a gif or and SVG can actually end up being very expensive especially if your animation is small in size and contains a lot of moving parts. Making a sprite sheet can actually be more performant than other methods.

In fact, Twitter uses this exact style of animation for their like buttons! [Check out this great article detailing that animation](https://medium.com/@chrismabry/how-did-they-do-that-the-twitter-like-animation-2a473b658e43). You'll notice they do it using CSS.

With this technique, there a whole new world of animation possibilities that opens up on the web. I look forward for a chance to actually use this on a real project at some point.


How to Animate Sprites on the Web


If you're anything like me then `async` and `await` were a revelation when they got added to JavaScript. Finally, there was a solution to the endless callbacks and chained `then()`s. It enabled us to write synchronous looking code with all the goodness asynchronicty provides.

But very quickly you might have noticed an issue handling rejected Promises. To address it you probably tackled it in one of two way:

**Method 1**
The simplest method was to just wrap everything in a try/catch block.

<Code language="javascript">
{`try {
  const res = await fetch("...");
  const data = await res.json();
} catch (err) {
  console.log(err);
}`}
</Code>

I found using this method often resulted in me dumping huge amounts of code within the try block. This meant that every error would result in all the code in the try not being run which wasn't always what I would want; sometimes I would want to handle an error by simply logging the error to the console and moving on with the rest of the code.

This brings to the second method.

**Method 2**
With this method you handle the error handling on a per-Promise-basis by chaining a `catch()`.

<Code language="javascript">
{`const res = await fetch("...").catch((err) => console.log(err));`}
</Code>

The problem here is a matter of developer experience. It SUCKS to keep writing a `.catch()` at the end of everything. And, honestly, who's got that kind of time?

And this brings me to the method that I use: the third method.

**Method 3**
With this method, we go back to our trusty try/catch block, but this time it's in a handy helper function. We are are going to make use of array destructuring to make the error a first-class citizen along with the desired resolution from the Promise.

<Code language="javascript">
{`const [data, err] = await call(fetch("..."));
if (err) console.log(err);\n
async function call(promise) {
  let data, error;
  try {
    const res = await promise;
    data = await res.json();
  } catch (err) {
    error = err;
  }
  return [data, error];
}`}
</Code>

Using this method we relegate our Promise rejection and resolution handling to the `call()` function. In this case, I even have it handling the `.json()` for me so I can use `fetch` and immediately get the JSON data I care about. This helper function returns an array where the first item is the data from a resolved Promise and the second item is the err from the rejected Promise. If the Promise resolved, the error will be undefined; if the Promise rejects the data will be undefined.

This let's me write very clean, synchronous looking code. It make handling error a breeze as I can easily either log the error and move on or provide some complex fallback scenario if I need to.

Since I've been writing all my async/await code this I've found that I've been able to write much more complex applications in less time, with fewer bugs, and with richer error-handling than I did previously.


This one weird trick changed my whole async/await game


Clean. Code. Clean code. CLEAN CODE! C-L-E-A-N C-O-D-E. Clean code.

What does that even mean? It's something we all say at some point, but it's meaningless. Or, more accurately, means different things to different people with different priorities and contexts.

For the purpose of this post I'm going to focus on separating business logic from the template. To illustrate this, I'll be using a code snippet I pulled from actual production code a developer on my team wrote. I've slightly modified it for clarity. Additionally, this is not meant to be an end-all-be-all way to write "clean code", but rather how I would approach writing this bit of code.

Before I get started, just a couple notes about the code:

1. The solution I end up with is not intended to be production-ready.
2. I am using server-side rendered [goatee](https://github.com/simpleviewinc/goatee) for templating, so syntax may seem unfamiliar at times.

Let's get into it:

<Code language="html">
{`<picture>
	<source
		srcset="{{image.getUrl({
			width: 900,
			height: 300,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 641px)"
	/>
	<source
		srcset="{{image.getUrl({
			width: 1280,
			height: 500,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 1025px)"
	/>
	<source
		srcset="{{image.getUrl({
			width: 1600,
			height: 700,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 1440px)"
	/>
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Here our dev created a responsive image to draw on the page. It works! But there's a few things that stand out to me about it.

First, there are 3 source elements that are nearly identical; that looks like an opportunity to simplify.

Second, it looks like the crop and quality properties are the same across all calls to `getUrl()`.

Third, if I need to introduce another source, then I need to make yet another source element and it's own call to `getUrl()` which grows adds visual clutter to the template and promotes copy/pasting which can lead to unexpected results if the dev isn't paying attention.

Let tackle this in phases. To start, I'm going to pull out the `getUrl()` calls and make the HTML simpler to read.

<Code language="html">
{`{{~exec(function() {
	helpers.var.srcSm = data.image.getUrl({ width: 900, height: 300, crop: 'fill', quality: 60 });
	helpers.var.srcMd = data.image.getUrl({ width: 1280, height: 500, crop: 'fill', quality: 60 });
	helpers.var.srcLg = data.image.getUrl({ width: 1600, height: 700, crop: 'fill', quality: 60 });
})}}\n
<picture>
	<source srcset="{{~var.srcSm}}" media="(min-width: 641px)" />
	<source srcset="{{~var.srcMd}}" media="(min-width: 1025px)" />
	<source srcset="{{~var.srcLg}}" media="(min-width: 1440px)" />
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Already, this feels better. It isn't actually better, but I'm headed in the right direction. I still have a lot of repeated code, but at least I can more readily see how I might be able to simplify the multiple sources into a loop over a single source. Similarly, now that I've pulled out the `getUrl()` calls into a JS context, I can standardize how I generate the URLs.

<Code language="html">
{`{{~exec(function() {
	const props = {
		641: { width: 900, height: 300, crop: 'fill', quality: 60 },
		1025: { width: 1280, height: 500, crop: 'fill', quality: 60 },
		1440: { width: 1600, height: 700, crop: 'fill', quality: 60 },
	};
	const widths = [641, 1025, 1440];
	helpers.var.srcs = widths.map(width => ({
		width,
		src: data.image.getUrl(props[width]),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

This is starting to look much better now.

Starting with the HTML, I've condensed the multiple sources into a single, easy-to-read loop. This also means, that if I needed to add a 4th or 5th source, I modify the array.

Next, let's take a look at the JS. I've created an array of viewport widths called `widths`; these widths are also the keys in the `props` object so I can associate a width with a set of arguments for our `getUrl()` call. And lastly, I map over the widgets to create and array of `srcs` which is what drives the generation of source elements in our HTML.

At this point, the HTML is pretty much where I want it. However, there's still room for improvement in the JS; `crop` and `quality` are still shared across all the sets of arguments.

Let's address that.

<Code language="html">
{`{{~exec(function() {
	const sizes = {
		641: { width: 900, height: 300 },
		1025: { width: 1280, height: 500 },
		1440: { width: 1600, height: 700 },
	};
	const settings = { crop: 'fill', quality: 60 };
	const widths = [641, 1025, 1440];
	helpers.var.srcs = widths.map(width => ({
		width,
		src: data.image.getUrl({
			...sizes[width],
			...settings
		}),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Here I've pulled out the `crop` and `quality` into their own object called `settings`. I've also renamed `props` to `sizes` which is much more descriptive now since all that object is concerned with are the sizes of the images to render.

Next, in the map, I spread the sizes and settings into an arguments object to be passed to `getUrl()`.

This is looking really slick now, but I'm not a fan of managing the viewport widths both in the `sizes` object and in the `widths` array. I really would like to keep it to a single touch point to reduce my chances to break something.

<Code language="html">
{`{{~exec(function() {
	const sizes = {
		641: { width: 900, height: 300 },
		1025: { width: 1280, height: 500 },
		1440: { width: 1600, height: 700 },
	};
	const settings = { crop: 'fill', quality: 60 };
	helpers.var.srcs = Object.entries(sizes).map([width, size] => ({
		width,
		src: data.image.getUrl({
			...size,
			...settings
		}),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

To simplify the handling of widths, I removed the `widths` array altogether and am, instead, mapping over the entries of the `sizes` object and destructuring out the size and the width. This is what I would consider "clean code".

First off, the HTML is greatly reduced and can support an indefinite number of sources. And there's no ambiguity about what the HTML is doing: it's putting a picture on the page.

Second, I have a single entry point for getting the actual image URLs that, ideally, I or a future developer supporting this site shouldn't need to touch.

Third, moving out the shared settings like `crop` and `quality` afford me two things:

1. I can easily make a global quality or crop change.
2. I can ignore them if I don't actually care about what they're set to.

Lastly, I am freed up to focus on the part that I most care about: defining sizes of images for different screen sizes.

I would and have delivered something like this in production. I find it to be much more readable, maintainable, and extendable compared to any of the previous iterations I ran through in this post.

How would you approach this? Do you have a better idea? Let me know in the comments below.


Category:
JavaScript

Creating an RSS feed with Next.js and Next-MDX

How I Solved the Impossible Layout

How to Animate Sprites on the Web

This one weird trick changed my whole async/await game

Write Cleaner Code by Separating Logic from Templates

Category:JavaScript

Category:
JavaScript