Svelte RSS feed

Tue Mar 28 2023

Some interesting-enough things I ran into while adding RSS to this site.

Serving XML with Svelte

The site was already set up to generate these post pages from Markdown files, which have YAML frontmatters with some metadata about the post. Since we have the metadata available already, I wanted to generate the rss.xml file automatically instead of updating it myself. After transforming the post data into the RSS format, I used some random library to generate the XML. The part that took the longest was probably the dates, which I'll go into more later (just for fun).

Generating the feed itself was pretty easy, but getting Svelte to serve it properly was a little more complicated. It couldn't be in a normal page since it would get wrapped with the default HTML layout and wouldn't work. Instead, we can create an API route at /rss.xml by creating the file /routes/rss.xml/+server.ts. We'll have this file handle GET requests and respond with the XML.

import type { RequestHandler } from './$types';

export const GET = (() => {

    // ... XML generation stuff ...

    const body = '...';

    return new Response(body, {

        headers: {

            'Content-Type': 'text/xml',

        },

    });

}) satisfies RequestHandler;

The next problem was that links to /rss.xml would be routed by SvelteKit and wouldn't find the API route and would 404 instead. To fix this, SvelteKit provides the attribute data-sveltekit-reload which lets the browser handle the link instead.

<a href="/rss.xml" data-sveltekit-reload>

    <img src="/rss.svg" />

</a>

The last issue was that SvelteKit's adapter-static was complaining about being unable to statically render all routes when it tried to build the site. We just need to add one line to +server.ts:

export const prerender = true;

RFC 822 dates without dependencies

The RSS spec requires dates to be in a format described in RFC 822. There's lots of Javascript libraries we could reach for (and since we statically render the site, it wouldn't affect our final bundle size), but let's try and avoid them.

We could use Date.toUTCString(), which the spec says is based on the format in RFC 7231 and appears to be the same as RFC 822. Instead, we can also use Intl.DateTimeFormat, which needs a little more manipulation but handles timezones nicely. We'll use formatToParts and then pick out the parts we need and reformat them into the RFC 822 format:

const formatDate = (date: Date) => {

    const formatter = new Intl.DateTimeFormat('en-US', {

        year: 'numeric',

        month: 'short',

        weekday: 'short',

        day: '2-digit',

        hour: '2-digit',

        minute: '2-digit',

        second: '2-digit',

        hourCycle: 'h23',

        timeZone: 'America/Los_Angeles',

        timeZoneName: 'short',

    });

    const parts = formatter.formatToParts(date);

    const weekday = parts.find((p) => p.type === 'weekday')?.value;

    const day = parts.find((p) => p.type === 'day')?.value;

    const month = parts.find((p) => p.type === 'month')?.value;

    const year = parts.find((p) => p.type === 'year')?.value;

    const hour = parts.find((p) => p.type === 'hour')?.value;

    const minute = parts.find((p) => p.type === 'minute')?.value;

    const second = parts.find((p) => p.type === 'second')?.value;

    const timeZoneName = parts.find((p) => p.type === 'timeZoneName')?.value;

    return `${weekday}, ${day} ${month} ${year} ${hour}:${minute}:${second} ${timeZoneName}`;

};

I definitely didn't figure out the Intl.DateTimeFormat solution first and then discover toUTCString... Thanks for reading.