DEV Community: Matthew Weeks

Adding an RSS Feed To My Gatsby Site To Automatically Cross-share New Posts To DEV.to

Matthew Weeks — Wed, 13 May 2020 12:51:19 +0000

Gatsby's plugin system makes adding and extending functionality SUPER easy. Today I set up an RSS feed for my blog, so that new posts can be automatically distributed to Dev.TO and Medium, in about twenty minutes.

Here's how you can do it in 10!

Wait hold on. Why are we doing this?

An RSS Feed is a structured format for sharing subscribe-able content in an XML feed. It was great the heyday of blogging when folks actually subscribed to blog feeds (RIP Google Reader, 2005–2013 😓).

But an XML feed can enable more than that. Because with a feed, you can do cool things like automatically cross-post all your blog posts to other platforms like Dev.to, and Medium. Just like how I've shared this post!

Will this hurt your SEO? NOPE! The opposite.

Thanks to a concept called canonical links, you can share your blog posts on other platforms like Medium and Dev, but refer back to your site as the original source. You get the benefit of exposing content to other audiences, but you get to keep the page rank.

So, how do we add the RSS feed to you Gatsby site?

Thanks to Gatsby's awesome plugin system, we can use gatsby-plugin-feed to do most of the heavy lifting.

For this example I'm using my site which uses MDX for my blog. If you have the same setup from the Gatsby Blog Starter or the NetlifyCMS Starter then this should be about the same, but if not, you may need some customization from the docs.

Either way, feel free to follow along and ask questions below!

So, first off install the plugin:

npm i --save gatsby-plugin-feed

Then, add the following chunks to your gatsby-config.js

module.exports = {
  siteMetaData: {
    // ....
    siteUrl: 'https://mweeks.dev',
    // ...
  },
  plugins: [
    // ...
    {
      resolve: `gatsby-plugin-feed`,
      options: {
        feeds: [
          {
            serialize: ({ query: { site, allMarkdownRemark } }) => {
              return allMarkdownRemark.edges.map(edge => {
                return Object.assign({}, edge.node.frontmatter, {
                  description: edge.node.excerpt,
                  date: edge.node.frontmatter.date,
                  url: site.siteMetadata.siteUrl + edge.node.fields.slug,
                  guid: site.siteMetadata.siteUrl + edge.node.fields.slug,
                  custom_elements: [{ "content:encoded": edge.node.html }]
                });
              });
            },
            query: `
              {
                allMarkdownRemark(
                  sort: { order: DESC, fields: [frontmatter___date] },
                ) {
                  edges {
                    node {
                      excerpt
                      html
                      fields { slug }
                      frontmatter {
                        title
                        date
                      }
                    }
                  }
                }
              }
            `,
            output: "/blog/rss.xml",
            match: "^/blog/"
          }
        ]
      }
    }
  ],
  // ...
}

And that's it! Next time I run a gatsby build, my site will have a shiny new /blog/rss.xml for all of my blog pages!

In my case, I simply git commit, do a git push and watch Netlify deploy it!

How to share your feed automatically on Dev.to

You'll want to head over to https://dev.to/settings/publishing-from-rss and enter in your fancy new RSS feed URL, and just watch the magic happen!

Be sure to check the Mark the RSS source as canonical URL by default option to get that delicious, delicious Google Juice.

And that's it!

If you wanted to post it on Medium as well, you can copy this Zapier Zap! https://zapier.com/shared/16969b48fc141b0d85705bc2d7fe2109e64b61ce

Now you've got no barrier to writing, and no need to worry about lock-in!

Happy hacking, and please like and subscribe!

Why do you want better commits?

Most people don't start thinking about their commits when they first start development (I get it, there's a lot going on and a lot to learn)

But commits become especially important when you're a part of a team.

When you enter a new repository, you want to be able to see how the project has developed over time. If you were to see commits like this:

Fix the thing
Update styles
Add the thing

(Note, these are actually not the worst examples—I'm sure you've seen worse)

You likely won't be able to understand what happened, without reading the code changes in a commit itself.

However, contrast those with these commits:

fix(blog): Imported posts formatted correctly with new styles
feat(blog): Update styles to reflect new design
feat(blog): Add blog feed to site.

Looks great, so how do we do it?

How to write a semantic commit

The semantic commit contains 4 parts:

The type of commit
The Scope of the commit (optional, but often nice to have)
The actual content of the commit
An optional body, for more description. Good for larger commits.

Here's how it works:

<type>(<scope>): <description>
  <Optional Body>

So in our first example above, we might create:

feat(blog): Add blog feed to site
  Add the markdown plugin, generate pages, and create blog template.

The type

You can use your own types, but here are the defaults:

feat: a new feature, or change to existing feature.
fix: Fixing a bug or known issue in code.
test: Adding additional tests for existing features.
chore: Updating build tools, like webpack, gulp, ascripts, etc.
docs: Update to documentation like README

The scope

Your scope can be as granular as you'd like and will likely change based on the complexity of the project. If you're just starting off a project, you could omit the scope, but I highly recommend you consider it, because it forces you to think very clearly about what you're changing.

The description

You want to summarize your commit with a single line. If you can't, then you probably want to consider breaking the commit down into smaller pieces to make the work logical and self-contained.

The (optional) body

A single line is good for summary, but sometimes you want to add additional detail so that readers can see more about what you changed now that they know why you changed it.

Conclusion

Writing better commits will help you write better code. Simple practices like this force you into a mindset of craftsmanship and self-documenting projects.

Want to take it further?

Consider reading the original source The Karma Commit Message Format or this newer resource The Conventional Commits.

Once you're going with semantic commits, you might want to enforce it as a standard on your projects! For something like this, you can use Commitizen(for validation) and Husky (for pre-commit hooks).

I will be following up with a guide on using pre-commit hooks to do linting, testing, and more in a future article.

Til then, happy coding.

May your code be functional, readable, and well-used.