DEV Community: Sebastian Landwehr

Creating an RSS Feed from Nuxt Content with Full Body HTML

Sebastian Landwehr — Sat, 17 Jul 2021 23:49:47 +0000

There is already an official doc article about how to create an RSS feed from Nuxt Content. But it only adds the excerpt as the actual content. Most feed readers allow the reader to read the whole article right in the app without a context switch. This article will present a way to add the whole document to the RSS feed by adding a simple drop-in module.

The problem with HTML code outside the nuxt-content component

Nuxt Content is a great static CMS that makes it incredibly easy to setup a performant Markdown-based blog without the need to add loads of third party services.

The heart of the system is the nuxt-content component. This component gets the Markdown document that should be rendered, and then applies big magic to make a beautiful blog page out of it 😊.

<template>
  <nuxt-content :document="post" />
</template>

So far so good. As long as you use Nuxt Content for rendering, there's not much to think about. But as soon as you want to access and work with the actual generated HTML code , you won't find any field in the documents containing the raw HTML code.

Reason is that the component internally generates a JSON object , which is then turned into VDOM nodes. So it's made for being rendered by Vue.js. There is no native way of letting the Markdown pipeline run somewhere else and working with the HTML code. But this is what we need, since we want to put the article text with markup inside our RSS feed!

Use nuxt-content-body-html to abstract it out

I built nuxt-content-body-html, which basically adds a bodyHtml field to all markdown documents. It reproduces the Nuxt Content Markdown pipeline to generate it and also uses the Remark and Rehype plugins from the module config, so it outputs the same HTML as the component. The good thing is, we can just drop it in and abstracts away the logic of generating the HTML code, so that we can concentrate on the feed creation.

Let's install the module by running npm install nuxt-content-body-html. Then we add it to our nuxt.config.js:

export default {
  modules: [
    'nuxt-content-body-html',
    '@nuxt/content',
  },
}

Great! To test, you can check post.bodyHtml on a blog page and it should contain the HTML code.

Now we can adjust the feed creation to actually use the field. You have probably used a way similar to the Nuxt Content docs to setup your feed. Here is a reduced example of a single RSS feed configuration:

export default {
  modules: [
    'nuxt-content-body-html',
    '@nuxt/content',
    '@nuxtjs/feed',
  ],
  feed: [
    {
      create: async feed => {
        const $content = require('@nuxt/content').$content
        feed.options = {
          title: 'My Blog',
          link: 'https://me.com/blog',
          description: "It's all about programming!",
        }

        const posts = await $content('posts')
          .sortBy('createdAt', 'desc')
          .fetch()
        posts.forEach(post => {
          const url = `https://me.com/blog/${post.slug}`
          feed.addItem({
            author: post.authors,
            content: post.bodyHtml,
            date: new Date(post.createdAt),
            description: post.description,
            id: url,
            link: url,
            title: post.title,
          })
        })
      },
      path: '/feed',
      type: 'rss2',
    },
  ],
}

That's it, now you should have a feed with full HTML content! I recommend Inoreader to test it, you can reload the articles with the little reload button and you should then see changes. Below you can see an example of an article shown in Inoreader:

Bonus tip: Add a teaser image at the very top

Feed readers can not only display the contents of an article, they often also show the first image as a teaser image in the article list. That's a great thing for readers to get a first impression of the article's content! Simply add an image at the very top and you're good to go. Adjust the feed creation like so:

// images at static/blog/<slug>/banner.png

posts.forEach(post => {
  const url = `https://me.com/blog/${post.slug}`
  feed.addItem({
    // ...
    content: `
      <p>
        <img
          alt="Cover image"
          src="https://me.com/blog/${post.slug}/teaser.png"
        >
      </p>
      ${post.bodyHtml}
    `,
  })
})

Here is the result in Inoreader:

And the resulting teaser view:

Conclusion

This article was about RSS feeds with Nuxt Content containing full HTML. nuxt-content-body-html is a quick and easy solution to add a bodyHtml field to documents that can be used in the feed creation function. I hope it's of some use for you! If you like it, feel free to leave a star at star at GitHub 🌟. Thanks for reading!

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️

Generating Beautiful Flowchart Diagrams With Mermaid and Vue/Nuxt

Sebastian Landwehr — Tue, 29 Jun 2021 16:35:15 +0000

Hey folks, today I want to show you how to generate flowchart diagrams in a Vue or Nuxt application using vue-mermaid-string and nuxt-mermaid-string. They both help to integrate the wonderful Mermaid library into your Vue-based projects.

Setup

Alright, let's stick to Vue for now and see later how it works for Nuxt. First we need to install the component.

There are several ways to add the component to your project. The quickest solution is via CDN like this:

<script src="https://unpkg.com/vue"></script>
<script src="https://unpkg.com/mermaid/dist/mermaid.min.js"></script>
<script src="https://unpkg.com/vue-mermaid-string"></script>

Note that you also need to add mermaid itself.

Alternatively, install it via a package manager:

$ npm install vue-mermaid-string

And register the component. You can do it locally:

<script>
import VueMermaidString from 'vue-mermaid-string'

export default {
  components: {
    VueMermaidString,
  },
}
</script>

Globally:

import Vue from 'vue'
import VueMermaidString from 'vue-mermaid-string'

Vue.component('VueMermaidString', VueMermaidString)

Or as a plugin:

import Vue from 'vue'
import VueMermaidString from 'vue-mermaid-string'

Vue.use(VueMermaidString)

Let's draw some serious stuff

Alright, now let's start drawing a diagram! Since probably most of the readers are JavaScript fans, we create a little tech tree for demonstration purposes 😊.

Here is the code needed to display the diagram. We also add endent to make life easier with multi-line strings.

<template>
  <div id="app">
    <vue-mermaid-string :value="diagram" />
  </div>
</template>

<script>
import VueMermaidString from "vue-mermaid-string";
import endent from "endent";

export default {
  computed: {
    diagram: () => endent`
      graph TD
        DateTime[Date and time]

        JavaScript --> Frameworks
        JavaScript --> DateTime
        JavaScript --> 3D
        Frameworks --> Vue.js
        Frameworks --> React
        DateTime --> Moment.js
        DateTime --> date-fns
        3D --> Three.js
        3D --> Babylon.js
    `,
  },
  components: {
    VueMermaidString,
  },
};
</script>

This results in the following diagram:

Great! You can also edit the diagram string (for example the node labels), and it updates the result accordingly.

As a next step we change the colors for each library type. I've used Paletton to generate a tetradic color scheme and applied the colors to the corresponding nodes.

I've put the result into a sandbox with source code, the result looks like this:

Feel free to play around with the sandbox and try out different Mermaid strings!

Usage with Nuxt

If you are a Nuxt user, it is probably more convenient to add a module to your project and then have everything available right away. There is nuxt-mermaid-string, which basically wraps the vue component.

Simply install it via npm install nuxt-mermaid-string.

Then add it to your nuxt.config.js like this:

export default {
  modules: ['nuxt-mermaid-string'],
}

And there we go. The rest works like above!

Conclusion

In this article we had a look at diagram generation in Vue and Nuxt apps. I hope you liked it and it's of some use for you!

You help me know if people like the packages by leaving a GitHub star at vue-mermaid-string and/or nuxt-mermaid-string 🌟.

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️

How to Access Nuxt.js Page Data in Route Meta Fields

Sebastian Landwehr — Thu, 13 May 2021 13:09:25 +0000

Hey folks, this article is about accessing page data in route objects. It's a use case I have frequently stumbled upon, for example when generating sitemaps.

Nuxt pages allow you to define structural data like the meta property or the auth property from @nuxtjs/auth (note that they should not be confused with meta tags). It would be great to be able to access them elsewhere. The route object can be accessed at quite a lot of places:

context.route in asyncData
this.$route.meta in components
this.extendRoutes in modules
context.route in Middlewares

I did some testing and found out that the only possibility to access page data outside pages is in asyncData and middlewares, as discussed in this issue. All other places do not work and have empty meta objects. Also, the case discussed in the linked issue adds a meta property in the route object itself, not in the matched array, as it is in vue-router (see the example from vue-router).

Alright, that's the current state. Now, how can we fix it and add page data to route objects?

nuxt-route-meta

I wrote the nuxt-route-meta module that does it by parsing the page components at build time and adding the data to the routes via this.extendRoutes. It's a zero config module, so you can just add it to your nuxt.config.js and it works out of the box.

First, install it via npm install nuxt-route-meta.

Then add it to your nuxt.config.js:

// nuxt.config.js

export default {
  modules: ['nuxt-route-meta'],
}

Now let's create a page with some data like so:

// pages/index.vue

export default {
  auth: true,
  meta: {
    theme: 'light',
  },
}

We are already done with the configuration! Let's go through the cases discussed above:

asyncData:

// pages/index.vue

export default {
  auth: true,
  meta: {
    theme: 'light',
  },
  asyncData({ route }) {
    // route.matched[0].meta.auth = true
    // route.matched[0].meta.theme = 'light'
  }
}

this.$route.meta:

// pages/index.vue

export default {
  auth: true,
  meta: {
    theme: 'light',
  },
  mouted() {
    // this.$route.meta.auth = true
    // this.$route.meta.theme = 'light'
  },
}

this.extendRoutes:

// modules/module.js

export default function () {
  this.extendRoutes(routes =>
    routes.forEach(route => {
      // route.meta.auth = true
      // route.meta.theme = 'light'
    })
  )
}

Middlewares:

// middleware/middleware.js

export default ({ route }) => {
  // route.matched[0].meta.auth = true
  // route.matched[0].meta.theme = 'light'
}

As we can see, we can access the page data everywhere now! That's it already on how to use the module.

Generating a sitemap with non-auth routes

A common use case of accessing page data is sitemap generation, especially conditionally adding entries to the sitemap. We will now configure @nuxtjs/sitemap to only add non-auth routes. So let's add the sitemap module via npm install @nuxtjs/sitemap and add it to our config:

// nuxt.config.js

export default {
  modules: [
    'nuxt-route-meta',
    '@nuxtjs/sitemap',
  ],
}

Filtering the routes is easy now because we only have to check the meta property:

// nuxt.config.js

export default {
  modules: [
    'nuxt-route-meta'
  ],
  ['@nuxtjs/sitemap', {
    filter: ({ routes }) =>
      routes
        .filter(route => [false, 'guest'].includes(route.meta.auth)),
  }],
}

And that's it, if you check /sitemap.xml, you should only see non-auth routes!

Conclusion

That was an introduction to nuxt-route-meta. I hope it's of some use for you! If you like it, feel free to leave a star at star at GitHub 🌟. Also, the module probably needs some more work, so in case you need something or there is a bug, file an issue. Thanks for reading!

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️

How to Write File-Based JavaScript Tests With Real Files

Sebastian Landwehr — Wed, 21 Apr 2021 10:47:47 +0000

Hey guys, this post is about writing tests for projects that access the file system by reading and writing files to disk.

A lot of my past projects in some way had to do with file access. I started to test with mocking libraries like mock-fs, but soon recognized that they do not work for all cases, and sometimes you are using third party libraries internally that you cannot mock easily. So I thought of a different solution and the one I'm using right now for most projects actually uses real files.

with-local-tmp-dir and output-files

Why not use real files for testing instead of mocking? I built an NPM package called with-local-tmp-dir that basically creates a temporary subfolder inside cwd, cds into it, runs a function, and cds back to the previous cwd afterwards. In this function you can create files and pretty much anything, run your unit under test. Afterwards the folder is removed and everything is cleaned up. You actually do not solely need to use it for tests, you can use it anywhere, but it's mostly useful for tests.

I also wrote another helper package output-files that creates a whole file tree at once by passing an object. It's much easier than writing a lot of fs.writeFile calls to create many files.

Let's test a scaffolding tool!

Alright, let's dive into it! First of all you need a testing framework. I'm going to use Mocha here, but you can also use Jest or any other framework of your choice. I'm also using expect for assertions. After that, we'll install some packages that we need to write our tests:

with-local-tmp-dir to create our temporary testing folder.
output-files to create multiple files at once.
fs-extra to read files after running the scaffolding tool.
endent to declare multi-line strings.

$ npm install --save-dev with-local-tmp-dir output-files fs-extra endent

We are going to test a small scaffolding tool that writes config files to disk. If a file already exists, it is not overwritten. Otherwise a default file is created. It's actually not important how it works but how we test it 😀.

Writing our first test

Let's add a test file:

// index.spec.js

const withLocalTmpDir = require('with-local-tmp-dir')
const endent = require('endent')
const expect = require('expect')
const fs = require('fs-extra')

const scaffold = require('.')

it('no existing files', () => withLocalTmpDir(async () => {
  await scaffold()
  expect(await fs.readFile('README.md', 'utf8'))
    .toEqual(endent`
      ## Package

      This is a test package.
    `)
  expect(await fs.readFile('.configrc.json', 'utf8'))
    .toEqual(endent`
      {
        "name": "Package"
      }
    `)
}))

And we can run our test via:

$ mocha index.spec.js

Pretty neat already, we have tested if the scaffolding tool creates a README.md and a .configrc.json file and checks if the contents are correct!

Writing files beforehand

Let's add another test that checks if the files are preserved if they are already existing. We are going to use output-files to write those files.

// index.spec.js

const withLocalTmpDir = require('with-local-tmp-dir')
const outputFiles = require('output-files')
const endent = require('endent')
const expect = require('expect')
const fs = require('fs-extra')

const scaffold = require('.')

it('existing files', () => withLocalTmpDir(async () => {
  await outputFiles({
    'README.md': endent`
      ## My Package

      Here is how to use this package.
    `,
    '.configrc.json': endent`
      {
        "name": "My Package"
      }
    `
  })
  await scaffold()
  expect(await fs.readFile('README.md', 'utf8'))
    .toEqual(endent`
      ## My Package

      Here is how to use this package.
    `)
  expect(await fs.readFile('.configrc.json', 'utf8'))
    .toEqual(endent`
      {
        "name": "My Package"
      }
    `)
}))

Great, that's already most of the work! Of course you can go into detail now and write more tests, but technically that's all it needs. You see, writing file-based tests with these packages is not a lot of more work than without them and you can use real files for your tests 🚀.

Writing Git-based tests

The test setup actually opens up another door: Using Git repositories for tests! I know this sounds a bit scary at first, but now that we can write files to disk for our tests, why not git init a git repository?

Let's assume that our scaffolding tool makes use of the currently checked out Git repository and puts the origin URL into the .configrc.json file. Now we can test if this works by actually instantiating a Git repository in our testing folder. We need another package for running child processes, run npm install --save-dev execa.

// index.spec.js

const withLocalTmpDir = require('with-local-tmp-dir')
const endent = require('endent')
const expect = require('expect')
const fs = require('fs-extra')
const execa = require('execa')

const scaffold = require('.')

it('uses repository url', () => withLocalTmpDir(async () => {
  await execa.command('git init')
  await execa.command('git config user.email "foo@bar.de"')
  await execa.command('git config user.name "foo"')
  await execa.command('git remote add origin git@github.com:foo/bar.git')
  await scaffold()
  expect(await fs.readFile('README.md', 'utf8'))
    .toEqual(endent`
      ## Package

      This is a test package.
    `)
  expect(await fs.readFile('.configrc.json', 'utf8'))
    .toEqual(endent`
      {
        "name": "Package",
        "repo": "git@github.com:foo/bar.git"
      }
    `)
}))

Be cautious though, if the repository is not initialized correctly, user user Git config might be overridden.

Conclusion

You see there are plenty of possibilities! 🥳 What do you think about this? Let me know in the comments! Also, if you like with-local-tmp-dir and output-files, give it a star on GitHub 🌟.

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️

@nuxt/content: How to Keep createdAt and updatedAt Valid After Cloning

Sebastian Landwehr — Tue, 13 Apr 2021 22:53:46 +0000

I recently tried out @nuxt/content, a Git-based CMS for Nuxt projects. And I really like it! It allows me to write markdown files and host them right in my existing project.

One thing I noticed when deploying the project to my server was that the createdAt and updatedAt fields were always reset and didn't reflect the actual dates. The reason for this is that Git does not keep file metadata. This means that the timestamps that @nuxt/content relies on are of no use.

Git to the rescue!

One way to fix this is not to use the file stats, but instead use the Git history for this. Special thanks to Andrew Kreuzer for the initial idea. We check the history for each file and take the earliest commit date as createdAt and the latest as updatedAt.

Requirement for this is that Git is installed on the build system and that the history is actually checked out. There will be problems if a shallow clone is made on CI, in this case the cloning has to be configured accordingly.

Using the nuxt-content-git module to make things easy

I created the Nuxt module nuxt-content-git to make the setup plug-and-play. You probably do not want to reinvent the wheel in each project.

Install the module with npm install nuxt-content-git and add it to your nuxt.config.js like this:

export default {
  modules: [
    'nuxt-content-git',
    '@nuxt/content',
  ],
}

Note that it is important to add it before @nuxt/content, so @nuxt/content knows about the hooks that our helper module installs.

Conclusion

That was basically it! The rest works behind the scenes. Your dates should be up to date 😊.

Let me know if you like this module and leave a star at GitHub 🌟.

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️

Using Modernizr with Nuxt.js to Detect Browser Features

Sebastian Landwehr — Wed, 10 Mar 2021 14:00:57 +0000

What is Modernizr?

Modernizr is a package that detects browser features and makes them queriable via JavaScript and CSS. This is very handy to find out which CSS properties are supported, for example. The approach is much more flexible and stable than using browser vendor and version for this. I wrote a module that allows to use Modernizr with Nuxt.js.

Using Modernizr with Nuxt.js

Modernizr uses a plugin-based architecture, and you have to build the package yourself, depending on the features you need to detect – at least if you are not using Nuxt.js! I have created the nuxt-modernizr module that makes it easy to add Modernizr to your Nuxt.js app. You pass the features as module options, and the module creates a Modernizr build and places it in the .nuxt folder. Here is how to configure it:

First, install the module via npm install nuxt-modernizr or yarn add nuxt-modernizr.

Then, in your nuxt.config.js, add the module and pass the options that should be passed to Modernizr:

export default {
  modules: [
    ['nuxt-modernizr', {
      'feature-detects': ['css/scrollbars', 'css/overflow-scrolling'],
      options: ['setClasses'],
    }],
  ],
}

Check out the Modernizr documentation for details.

Now we can use the Modernizr variable and the generated CSS classes on the HTML root element to check for browser features. My all-time favorite among browser features is CSS scrollbars, because the support is pretty different between browsers and depending on if they are available, you can adjust container sizes and style them or not.

if (Modernizr.cssscrollbar) {
  // CSS scrollbar support
}

html.cssscrollbar {
  /* CSS scrollbar support */
}

Conclusion

That was already it! Usage is pretty simple. Let me know if you find it useful or if there are any things that you are missing. Also, if you find it useful, leave a GitHub star on the repository.

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️

Image Snapshot Testing with Mocha

Sebastian Landwehr — Fri, 05 Mar 2021 23:31:15 +0000

Snapshot testing is a testing mechanism that for long has seemed to be exclusive to Jest. The main idea is to generate expected values into a separate file and to compare the actual tested values with these saved values. It is also possible to update snapshots by passing an environment variable. This testing approach is great for complex data like large strings, DOM content, or images. I wrote a package to use image snapshot testing also with Mocha.

Snapshot testing with Jest

Snapshot testing itself is a built-in feature of Jest, and when searching specifically for image snapshots, you'll quickly find jest-image-snapshot, which does great work comparing and updating image snapshots. It also provides convenience features like a base64 diff output, which allows us to view the diff from a CI environment (since the diff image file cannot be saved or viewed).

What about Mocha?

While this is all great, what if I'm not using Jest for whatever reason? What if I'm using Mocha?

For simple snapshot testing, there are some options. For Chai users, there is mocha-chai-snapshot. For expect users, there is expect-mocha-snapshot. It basically wraps the jest snapshot logic by injecting an artificial testing context. Big credit to Alexander Beletsky here!

What was still missing was a package that ports image snapshot testing to Mocha. Since I'm currently using expect as an assertion library, I focused on finding a solution for this one.

I started to fiddle around with jest-image-snapshot in combination with expect-mocha-snapshot, and it turned out to be way easier than expected to make it Mocha compatible. I put it into its own NPM package, called expect-mocha-image-snapshot. Usage is pretty similar to Jest, you only have to pass the testing context via this. Here is a quick code sample:

import expect from 'expect'
import { toMatchImageSnapshot } from 'expect-mocha-image-snapshot'

expect.extend({ toMatchImageSnapshot })

it('works', async function () {
  ...
  const screenshot = await puppeteer.screenshot()
  expect(screenshot).toMatchImageSnapshot(this)
});

You can have a look at the code in case you are interested in how it works. It is pretty straight-forward.

Conclusion

That was my guide to image snapshot testing with Mocha. If you like expect-mocha-image-snapshot, you can support me by putting a star on GitHub. Also, let me know what you think about it.

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️

Sending Emails with Nuxt.js the Easy Way

Sebastian Landwehr — Fri, 05 Mar 2021 01:18:24 +0000

When I started to work with Nuxt.js, I frequently had the problem that I wanted so send emails via a contact form. While there are third party services to do that, I thought: Why not use the existing server infrastructure that comes with Nuxt.js?

That is why I wrote nuxt-mail, a Nuxt.js module that adds a /mail/send route to the server and injects a $mail variable that wraps the API call.

Usage

You start by installing the module and @nuxtjs/axios via npm install nuxt-mail @nuxtjs/axios or yarn add nuxt-mail @nuxtjs/axios.

@nuxtjs/axios is important here because it allows the module to do the REST call.

Then you add @nuxtjs/axios and nuxt-mail to your nuxt.config.js file. We have to pass the SMPT settings that should internally be used by nodemailer. We also configure the recipients here for security reasons. This way, a client cannot send emails to arbitrary recipients from your SMTP server. You can actually preconfigure the messages here in case you always want to give them the same title, from address or something.

export default {
  modules: [
    '@nuxtjs/axios',
    ['nuxt-mail', {
      message: {
        to: 'me@gmail.com',
      },
      smtp: {
        host: 'smtp.mailtrap.io',
        port: 2525,
        auth: {
          user: 'username',
          pass: 'password'
        },
      },
    }],
  ],
}

Note that you probably should pass the credentials or the whole config via environment variables (e.g. via dotenv). Also note that you cannot use this module for static sites (via nuxt generate), because the server middleware does not exist.

And there we go! Now we can implement ourselves a contact form page and send emails:

<template>
  <form>
    <label for="email">Your email address:</label>
    <input id="email" type="email" v-model="email" />
    <label for="message">Message:</label>
    <textarea id="message" v-model="message" />
    <button type="submit" @click.prevent="send">
      Send email
    </button>
  </form>
</template>

In the <script> section we basically call this.$mail.send():

<script>
export default {
  data: () => ({
    email: '',
    message: '',
  }),
  methods: {
    send() {
      this.$mail.send({
        from: this.email,
        subject: 'Contact form message',
        text: this.message,
      })
    }
  }
}
</script>

When you hit the Send button now, you should receive an email into your inbox!

Multiple message configs

It is also possible to provide multiple message configurations by changing the message config into an array.

export default {
  modules: [
    '@nuxtjs/axios',
    ['nuxt-mail', {
      message: [
        { name: 'contact', to: 'contact@foo.de' },
        { name: 'support', to: 'support@foo.de' },
      ],
      ...
    }],
  ],
}

Then you can reference the config like this:

this.$axios.$post('/mail/send', {
  config: 'support',
  from: 'John Doe',
  subject: 'Incredible',
  text: 'This is an incredible test message',
})

Or via index (in which case you do not need the name property):

this.$axios.$post('/mail/send', {
  config: 1, // resolves to 'support'
  from: 'John Doe',
  subject: 'Incredible',
  text: 'This is an incredible test message',
})

That's basically it, I hope that this is of use for some of you.

Conclusion

You can use the module to easily setup email sending capabilities. If you plan to build a bigger SaaS that sends a lot of emails, an async solution that does the sending via a cronjob or via server-side hooks is probably a better idea. But for a first-off solution, it should work fine.

Let me know what you think about the module and if there are any open questions. Also, since this is my first post, let me know what you think about the post in general.

You can find the module here.

If you like what I'm doing, follow me on Twitter or check out my website. Also consider donating at Buy Me a Coffee, PayPal or Patreon. Thank you so much! ❤️