DEV Community: Sam Smith

A modern front-end workflow for Wordpress

Sam Smith — Wed, 05 Feb 2020 00:00:00 +0000

For all intents and purposes, this is a first look at the Wordpress starter theme Sage. I think I did, a long time ago, try an earlier incarnation of this theme, when it was called Roots, but I can't remember much about it (I must be going back the best part of a decade here). Roots is now a suit of Wordpress development tools, one of which being the starter theme, now known as Sage. Shortly after trying the original Roots, I for whatever reason switched to Underscores, which I continued to use as a starter theme for many years. Underscores has served me well, and I've not really had any major gripes with it; but when something recently drew my attention to Sage it made me (re)consider what I / Underscores was potentially missing. In short the missing pieces are a bunch of developer experience stuff, that we've become used to, especially working with other stacks. Specifically that means a templating engine, and a configured build script with concatenation, minification and live reloading. If these are things you tend to add to your Wordpress workflow, or like me, you'd quite like to have but not sure it's worth the setup time, then read on.

With my interest piqued I needed something Wordpressy to build. I decided to make a little shop; then set about designing a couple of pages, to give myself something to work towards.

If you want to skip to the end result, it can be found at hatecapitalism.com.

Setting up your project is pretty straight forward. Recently I've been using Local by Flywheel as my local Wordpress environment, and I continued to do so here. New Sage projects are created with Composer (which I ran outside of Local).

# wp-content/themes/$ composer create-project roots/sage my-theme-name

During the setup you can choose to include one of a selection of CSS frameworks, but I opted for a blank slate. In your new project you run yarn to install dependancies, then when you've got got things configured yarn start to run the development server. When running the dev server, you'll want to switch the to the BrowserSync address (localhost:3000 by default), not only because this is where the live reloading happens, but once run, your updated assets do not exist in their build location. To build your assets, so they are available at my-new-site.local you need to run yarn build. When you're ready to go live yarn build:production. I suggest reading the docs before getting started. I found them to be pretty good, if maybe a little thin, given how much there is to cover. The forum does a good job of bolstering the docs, should you be left wanting.

Once up and running I had a couple of little niggles with dependancies being out of date. I quickly found that I couldn't disable the Webpack specific Browsersync (in browser) notifications. There wasn't much recourse for this as the plugin being used is no longer maintained. If this is the only problem that this plugin causes, then it's not too big of a deal (I can hide the notifications with CSS, I guess), but a bit of a concern. Less of a concern was Stylelint flagging stuff that it shouldn't be, like the system-ui font-family keyword. Updating Stylelint resolved that problem.

On to the good stuff - as I thought would be the case, having a templating language in place was nice. I've never used a templating language in Wordpress before, frankly because I've never really felt the need enough to warrant looking into it. Sage uses Laravel's Blade templates out of the box, so you get templating for free. The main benefit of using a templating language, such as Blade, is the ability to define, inherit and extend layouts. Many of us are used to working in this way, via various templating languages, in other environments, whether that be Liquid templates in Jekyll or Jinja templates in a Python project. A secondary advantage is less opening and closing of PHP tags in your templates, specifically when echoing variables:

<h1>Hello <?php echo $name; ?>.</h1>

becomes

<h1>Hello {{ $name }}.</h1>

Blade also gives you "shortcuts" for common PHP control structures; for example you can put if statements and loops right in your templates.

@if($products) <ul> @foreach($products as $i=>$product) <li>{{ $product->name }}</li> @endforeach </ul>@endif

When you need to, breaking into regular PHP is easy; you just wrap it like so:

@php //php here@endphp

I found myself doing this out of habit - I wrote a little switch statement (to handle the words that come before the price on the home page) before realising that Blade has its own syntax for this. If you're going to put such things in your templates though, I don't think using one syntax over the other will make a huge difference to the cleanliness of those templates.

@php switch ($i) { case 1: First case... break; case 2: Second case... break; default: Default case... break; }@endphp

@switch($i) @case(1) First case... @break @case(2) Second case... @break @default Default case...@endswitch

When it came to writing styles I felt at home working with CSS in Sage. First of all, this is probably the point when you appreciate that Sage has BrowserSync ready to go, out of the box. In addition to that, Sass and PostCSS are wired up in a Webpack configuration. If I were constructing this build process from scratch I would probably forgo Sass in favour of PostCSS plugins, and opt for something less gnarly than Webpack, but I think the choices here are reasonable, and given that they are configured for us, I'm perfectly happy to use them.

The Sage build process really started to shine when it came to adding Javascript. Sage provides DOM-based routing, giving you an easy way to specify which scripts run on what pages. For example, if I wanted the Javascript for the slider on my homepage to only run the homepage, that can be achieved pretty much just by putting it in a file named home.js (the is based on body classes, of which home is one). Global Javascript, such as the slide-out navigation for example, lives in common.js. From a developer experience point of view, I found this to be a really nice answer to the question of what to do with page specific Javascript. From a user experience point of view, the appropriateness of this technique will vary with each project. You will need to consider whether putting all the Javascript in a single file the best approach.

Ironically, given that this was an exercise in exploring a Wordpress starter theme, I felt like I didn't spend much time engaging with Wordpress while working on this little project. That is perhaps the biggest compliment I could give Sage, it puts a layer of modern tooling between you and Wordpress. I still had the odd Wordpress moment, like writing a PHP function in order to change the contents of the title tag, but for the most part I felt free to focus on the sort of front-end stuff that I wanted to be focusing on. That was a breath of fresh air.

Use design tokens to customise Bootstrap

Sam Smith — Sun, 12 Jan 2020 00:00:00 +0000

If you are creating a customised version of Bootstrap, and especially if you intend to use it for more than one website / app, I think design tokens can make for a nice authoring experience, as well as bring a bit of future-proofing along for free. This is the approach I took with a recent project; if you just want to see what I did, skip down to .. What I did. First, a little about how I arrived at this method.

I was working on a project which involved updating the visual identity of two websites, which share that visual identity. The two codebases were pretty disparate, though they were both built on Bootstrap. A benefit of using a framework such as Bootstrap is that you can create a custom version then not only use it to build one site, but reuse it to build other sites with the same visual identity.

There are various approaches to sharing a customised Bootstrap between sites. The worst case scenario (which was the case here) is that you rely on those maintaining the sites to make sure that they are visually consistent. Achievable but inefficient. Another approach I've seen is to compile your bespoke Bootstrap then share that code between sites, probably via a CDN. There is value in the CDN here, but more often than not I think this will lead to you having to override your shared Bootstrap styles with site specific ones. This is where frameworks start creating more problems than they solve, in my opinion - causing bloated and overly complicated code. An approach I have favoured in the past is to just maintain a version of the Bootstrap SCSS variables file which can be included into each site's main SCSS file, along with a freshly NPM installed Bootstrap. This is a clean, simple, and flexible approach, but there is room for improvement. If you have taken this approach, you have potentially created a single source of truth for the brand's styles. Nice. The problem is that this single source of truth is heavily tied into Bootstrap. Even if you have taken the time make your variables.scss more versatile with additional, less bootstrapy variables; you are still tied into SCSS at this point. The danger here is that if/when you build something without SASS, not only is your single source of truth going to be of limited use, you are probably going to stop caring about maintaining it.

Design tokens

This is where design tokens come in. Design tokens simply offer an agnostic way to store variables. That is to say, those variables can in theory be used in any project, regardless languages involved. A clear use-case for design tokens is to share variables (or tokens) between a web project and a native mobile project. It might sound like over-engineering to use design tokens just to generate Bootstrap variables, but the additional setup is small, and to me the workflow felt good.

What I did

I used Style Dictionary to transform my tokens into SASS variables. I created a new package.json (npm init) for my design tokens project, and added Style Dictionary as a dev dependancy:

npm install -D style-dictionary

Style Dictionary has a command to create a starter project, which you might find useful. Here though I will detail the project structure I used for this particular use-case. The first thing you need in your project is a config.json. In this file you tell Style Dictionary what exactly you want outputted (and to where). Here's what you need for our purposes:

{ "source": ["properties/**/*.json"], "platforms": { "scss": { "transformGroup": "scss", "buildPath": "build/scss/", "files": [{ "destination": "_variables.scss", "format": "scss/variables" }] } }}

This tells Style Dictionary to look in the properties folder (which we haven't made yet), convert the properties there to SCSS variables, in a file named _variables.scss, at the path build/scss. Tweak this as you please.

Now for those properties. My preference here was to first create non-Bootstrap specific variables, then reference these in my Bootstrap variables. I like having a versatile and consistently named collection of variables (not limited by the constraints of Bootstrap), to use for any additional styles that need to be written. Style Dictionary comes with a suggestion about about how you structure your properties, and thus, what your variables will be named. You do not need to follow this suggestion, but doing so gives you access to some helpers. For example you can convert colour values from one format to another. I found the suggested structure to be sensible, and pretty close to what I would have naturally adopted for my non-Bootstrap variables. So I ran with it, without looking too much into the perks. The suggested property structure is Category / Type / Item. A SASS variable following this structure would look like $size-font-small, or $color-blue-base. size and color being the categories, font and blue being types, and small and base being items. If this is confusing or throws up questions, I suggest you either check out the docs, or just put it to the back of your mind. You don't really need to understand this structure to get going; I think it's worth mentioning though, so you know how I decided to structure my properties. With that said, let's create those properties. My properties folder looked something like this:

|-- bootstrap
| |-- color.json
| |-- headings.json
| |-- link.json
|-- size
| |-- font.json
| |-- spacing.json
|-- color.json
|-- font.json

The properties are stored in multiple files, and split into subdirectories for ease of maintenance (this is another reason why I like this design token approach). I don't believe there is any reason you couldn't store all your properties in a single JSON file, if you wanted to. Each JSON file follows the same format. Let's look at color.json as an example:

{ "color": { "gray": { "100": { "value": "#F6F6F6" }, "500": { "value": "#939598" }, "900": { "value": "#231f20" } }, "blue": { "base": { "value": "#00D1FF" } }, "text": { "base": { "value": "{color.gray.900.value}" }, "decoration": { "value": "{color.blue.base.value}" } } }}

Any object in the JSON that has a value attribute is a property. So color.gray.100 is a property, as is color.blue.base. In terms of SASS variables, these will output as:

$color-gray-100: #f6f6f6;$color-blue-base: #00d1ff;

You can see in the above example that you can reference other properties; so $color-text-base will have the same value as $color-gray-900. The size directory can be thought of as a size.json file split into two smaller files. Both the JSON files within that directory have size as the top level object.

{ "size": { "font": { "sm": { "value": "0.875" }, "base": { "value": "1" }, "lg": { "value": "1.125" } } }}

{ "size": { "spacing": { "sm": { "value": "0.5" }, "base": { "value": "1" }, "lg": { "value": "1.5" } } }}

Note that these size properties do not include units (px, rem etc). Because I am using the size category, units get added by Style Dictionary. For SCSS, the default is rem.

For my Bootstrap properties, I stopped thinking about the Category / Type / Item structure and focused on generating the required variable names (I found bootstrapvars.com to be a useful reference here). You can organise these properties how you like, I mostly named the JSON files after the first word in the variable name. For example headings.json could contain properties for $headings-font-family, $headings-font-weight, $headings-line-height etc. Because I had already created a comprehensive set of variables, no new values were included in these Bootstrap properties - they were all aliases of existing properties. This may not be the case for you, and if you are only interested in creating Bootstrap specific variables, you could skip straight to this part and include actual values here.

{ "headings": { "font": { "family": { "value": "{font.family.base.value}", "comment": "Bootstrap" }, "weight": { "value": "{font.weight.black.value}", "comment": "Bootstrap" } } }}

I used Style Dictionary's comment feature to add a comment to each Bootstrap property, so it could be recognised as such in the outputted _variables.scss file.

Once you have your properties defined, you can generate your SCSS file with:

npx style-dictionary build

That will generate the file at the path specified in your config. That file is now ready to be included in your Bootstrap builds. There are a few ways you could get it into your project. I included the whole design tokens repo as a Git subtree, so I could continue to build the variables from within the Bootstrap project, and push the changes back. I had my task runner watch the design tokens directory, and run the build command from there.

What is primarily achieved by following this method is the ability to easily build your variables into a different format, CSS custom properties for example. Even without taking advantage of that though, I found the structure described above, and the JSON format made for a nice way to structure and keep track of the large number of variables that a customised Bootstrap tends to require.

Top static site generators of 2019

Sam Smith — Fri, 20 Dec 2019 00:00:00 +0000

OK, this is not going to be an all encompassing, objective review of available static site generators (SSGs). In this article I will talk about what SSGs I have been enjoying this year, and why.

Recently someone commented that I seem to use a different static site generator (SSG) for every project. This prompted a conversation about the pros and cons of sticking with a familiar stack VS trying something new. I explained my position - for projects that are time sensitive (most projects) I prefer to use technologies that are familiar and predictable to me. However, for projects where I have more freedom, i.e personal projects, I like to try new things. And yes, I have a bit of a thing for SSGs. It's only through trying new things that you can find and familiarise yourself with those killer solutions, that you'll come to rely on later. I think SSGs are a great example of this. There are lots of products that we call static site generators, and they differ greatly. I like to keep my hand in with a few, so I know what to reach for when I don't have the luxury of time to experiment.

I wrote a similar post to this back in early 2016; I thought an interesting way to frame this today might be to look at how the landscape and my preferences have changed since then. One of the points I made in that 2016 post was that I hadn't found a non-developer friendly way to manage content for static sites. Maybe I wasn't looking in the right places, but it feels like this is an area that has really improved since then. Headless CMSs are very much part of the JAMstack landscape, of which SSGs are now almost synonymous. This brings me to my first SSG mention:

Gridsome

Getting your data from an external source (such as a headless CMS) can be a little fiddly. Some SSGs are more focused on making this easier than others. I don't have a huge amount of experience with Gridsome, but enough to know that CMSs feel like first-class citizens here. It's early days, but the Starters page at least sets out a direction for ready-made integrations with a really good selection of content / data sources. To try this out, I recreated a simple site I had previously made with Nuxt. Like Nuxt, Gridsome is Vue.js based, which made this migration quick and easy. It's worth mentioning that the two versions are different in that the Nuxt version was server side rendered, while Gridsome creates pre-rendered HTML. That said, the code required to fetch and query the data felt much simpler with Gridsome, thanks to the CMS specific plugin, and the leveraging of GraphQL. If you're into JavaScript frameworks, and in particular Vue, this is a SSG to keep an eye on.

While I wasn't strictly integrating CMSs with static sites in 2016, I was pulling data from APIs. This is a staple of JAMstack today, but just a few years ago the ability to pre-render HTML from remote APIs didn't feel like a common SSG feature. In fact, one of the SSGs I mentioned in the 2016 post, I chose purely for this feature. That SSG was Roots, which is no longer under active development. At the time I used it to build my portfolio site. Today I use my next SSG mention:

Hugo

Hugo, much like many modern SSGs offers the ability to work with remote data. It does so via its getJSON and getCSV functions. What perhaps sets Hugo apart from other SSGs is that this, and other common features are ready to use, out of the box. So whether you want taxonomies, shortcodes, word count, theming - these things are all ready to go in your freshly created Hugo site. For a lot of use cases, you only need to concern yourself with templating. About those templates though, Hugo uses Go's templating language, so unless you are familiar with Go, templating logic will take a bit of getting used to. I didn't find this to be too much of a pain, I do however think the templating in Hugo is the thing most likely to put me off reaching for it. Not so much because you need to work with the ways of Go, but because I've found myself tending to put a lot of logic and variables in these templates at times, which while gets the job done, leads to messy and complicated templates. If I'm going to pinpoint what is most likely to put me off using Hugo, I should say what is most attractive about it. Besides being feature rich and capable, I think the community might be the biggest attraction. The Hugo website has a dedicated and active forum, where in my experience, your questions will be answered. I much prefer the forum format over something like a Discord or Gitter, which seem to be popular with other projects.

In 2016 I mentioned two other SSGs, Jekyll, which was powering my blog at the time, and Middleman, which I identified as my go-to SSG. These two have in common their dependancy on Ruby. This commonality is a significant factor in why I no longer use them. After using Jekyll for many years, a macOS update broke Jekyll on my machine. I was only maintaining one Jekyll site (my blog) by this time, so after spending a significant amount of time troubleshooting I decided it would be quicker to just rebuild my blog with a different SSG. I don't imagine this extreme scenario is common, but I think some consideration should be given to whether you want to setup / maintain a Ruby development environment, just for static sites. This is probably in part why out of the top ten SSGs on staticgen.com eight are written in JavaScript. As it turns out, since moving away from Jekyll I haven't looked back. The SSG that now powers my blog, has become my new go-to SSG (so I guess its a sort of winner). That SSG is:

Eleventy

Coming back to my point about trying new things - finding an excuse to try Eleventy was really worthwhile. Not only did I find it to be a good drop-in replacement for Jekyll, but having made a few sites with it I found it to be very versatile. Versatility runs right through Elevently. If you are making something simple, it can get out of the way, with zero configuration; making something more complex, it can be very powerful. The options available for working with data I've found to be particularly powerful. JavaScript data files mean you can prepare your data in any way that JavaScript allows, and make it available to your templates. The versatility extends to the templating language too, you can configure Eleventy to use the languages you want. No more putting up with what the SSG dictates. What I think Eleventy generally does really well is allow you to bend and shape it to your needs. It doesn't really presuppose anything about your code. I would say this is less true of other SSGs, to varying degrees. Something like Gridsome is dictating a lot, you are definitely building a Vue app in that case. Hugo on the other hand doesn't necessarily dictate the code that reaches the browser, but your templates will probably be less concise, as you jump though Hugos hoops. If you don't mind doing your own wiring, and you value elegance and simplicity, then Eleventy should be on your shortlist of SSGs.

Honorable mention

A lot has changed in SSG land in a past few years, including my preferred tools. I was wondering if there are any SSGs I was using in 2016 that I would still use today. I could think of one: Lektor. I don't think Lektor has changed much over those years, and it feels kind of pre JAMstack. That said, the value it had to me in 2016 it still has now. Lektor is a static content management system, it only deals with flat-file data. What makes Lektor interesting is while most SSGs tend to be centred around Markdown files with metadata, Lektor has its own file format which allows any number of fields. It's like the difference between Wordpress with and without Advanced Custom Fields. You even get an admin GUI to edit the content once the fields are configured. I find the idea of a very simple setup for a site where pages can be configured to have any combination of fields to be quite liberating; I can see myself using Lektor again in the future.

Building a swipeable card stack with interact.js and Svelte

Sam Smith — Mon, 07 Oct 2019 00:00:00 +0000

I've been waiting for an opportunity to dip my toe into some Svelte for a while. Faced with a little free time, I decided to create that opportunity. For anyone who hasn't heard of Svelte, it is a JavaScript / component framework, along the lines of React and Vue, but with an added compile step at build time. So what did I decide to use it for? Inspired by this post by Mateusz Rybczonek, I set myself the challenge of building a swipeable card stack interface. You can see the result here.

In this article I will explain the steps I took in building the above interface, and detail some of the approaches I took.

Step 1: Sapper

I really like static site generators (SSG), and will usually reach for one if a project has static content (such as this one). Fortunately there is a Svelte based SSG; its called Sapper. The Sapper template makes a pretty good starting point for a project like this, and comes in Rollup and Webpack variants. I went for Rollup, getting up and running like so:

npx degit "sveltejs/sapper-template#rollup" my-app
cd my-app
npm install
npm run dev

There were a few things in this template that I didn't need, which were either deleted or repurposed. The about and blog routes were removed, but not before repurposing blog/_posts.js, blog/index.json.js and blog/index.svelte to deliver the content for my app.

I used the include Nav component as a guide to creating my first Svelte component, the only component in this app. I'll get back to that in a moment.

Step 2: (optional) PostCSS

I like processing my styles with PostCSS, I tend to use preset-env to enable nesting and autoprefixing. I used this Tailwind template as a guide to set this up with Sapper. Installing the required/desired packages, editing the Rollup config, and importing the CSS file into server.js.

npm install --save-dev postcss postcss-import rollup-plugin-postcss svelte-preprocess postcss-preset-env cssnano

// rollup.config.js
// ...
import getPreprocessor from 'svelte-preprocess';
import postcss from 'rollup-plugin-postcss';
import path from 'path';
// ...
const postcssPlugins = [
    require("postcss-import")(),
    require("postcss-preset-env")({
    features: {
      'nesting-rules': true
    }
  }),
    require("cssnano")()
]
const preprocess = getPreprocessor({
    transformers: {
        postcss: {
            plugins: postcssPlugins
        }
    }
});
// ...
export default {
    client: {
      // ...
        plugins: [
            postcss({extract: true}),
            svelte({
                // ...
                preprocess
            }),
            // ...
        ],
        // ...
    },
    server: {
        // ...
        plugins: [
            // ...
      postcss({
                plugins: postcssPlugins,
                extract: path.resolve(__dirname, './static/global.css')
            })
        ],
        // ...
    },
    // ...
};

(Add styles to src/css/main.css)

// src/server.js
// ...
import './css/main.css';
// ...

Its worth noting that using this particular approach means you won't be taking advantage of Sapper's code splitting when it comes to CSS, but given that this would be a single page app, I didn't see that as being an issue.

Step 3: Creating the Card component

There will be multiple cards in this interface, so it makes sense to create a component for them. This simply needs to be a template with some props, like so:

<!-- components/Card.svelte -->
<script>
    export let isCurrent;
    export let cardContent;
</script>

<p class="card" data-dragging="false" data-status="{isCurrent === true ? 'current' : 'waiting'}">
    <span class="card_content">{cardContent}</span>
</p>

I've given the card a class so it can be styled as such, plus a couple of data attributes to hold some contextual information that will become useful later. All three attributes could be handled with classes, but I like to use a different syntax for contextual stuff to make my CSS easier to read. You might also think that the JavaScript to handle the dragging etc should live in this file. When I tried this I found that the script would run for each instance of the component (which is not what I wanted). There's probably a way of making it behave as I wanted, but as I had a layout template not really being used for much, I decided to put all the logic there.

If you were writing your CSS inside the component, it would live in a style tag within this file. My CSS lives in a good old CSS file. Its pretty simple so I won't go over it here. Essentially I have a fixed size card component, absolutely positioned.

Step 4: Putting your cards on the table

In index.svelte I add instances of the Card component to the page. As mentioned earlier, I made use of the blog code to store the content of each card in an array, which I then iterated over like so:

{#each cards as card, i}
    <Card cardContent={card.content} isCurrent={i === 0}/>
{/each}

Setting isCurrent to true for the first item in the array. For simplicity you might just want to put the cards directly into this page:

<Card cardContent={"One"} isCurrent={true}/>
<Card cardContent={"Two"} isCurrent={false}/>
<Card cardContent={"Three"} isCurrent={false}/>

In either case, you also need to import the component into the page:

<script>
    import Card from '../components/Card.svelte';
</script>

Step 5: Draggable cards

Now for the fun stuff, the interactivity. I put all the interactivity logic in my _layout.svelte file, which until this point was pretty much empty. The dragging relies on interact.js which we need to add to our project before importing into our template.

npm install --save-dev interactjs

The basis for the below code is the dragging example given on the interact.js website. The alterations and additions I will outline here. First thing to note is in Svelte anything that relies on the DOM being ready goes inside an onMount function. To use this function, we first need to import { onMount } from 'svelte'. I took the concept of "interact threshold" and how that relates to rotation from Mateusz Rybczonek's article. interactThreshold represents how far a card needs to be dragged before it is considered dismissed. The interact.js example stores the draggable objects position in data attributes, and adds inline styles to transform its position. Preferring to keep the styles in the style sheet, I used CSS custom properties to store these variables, which are referenced in the CSS. To access the custom properties in the JavaScript, I used Andy Bell's getCSSCustomProp function. Finally, inside the onend function, we check whether the card has moved a sufficient amount to dismiss. If so we remove its current status and give it to the next card. We also move it off the screen to the left or right, depending on whether its x coordinate is positive or negative. If the card has not moved a sufficient amount, we reset its position and rotation custom properties.

<script context="module">
    import interact from "interactjs";
</script>

<script>
    import { onMount } from 'svelte';

    const interactThreshold = 100;
    const interactMaxRotation = 15;

    let rotation = 0;
    let x = 0;
    let y = 0;

    // https://hankchizljaw.com/wrote/get-css-custom-property-value-with-javascript/#heading-the-getcsscustomprop-function
    const getCSSCustomProp = (propKey, element = document.documentElement, castAs = 'string') => {
        let response = getComputedStyle(element).getPropertyValue(propKey);

        // Tidy up the string if there's something to work with
        if (response.length) {
            response = response.replace(/\'|"/g, '').trim();
        }

        // Convert the response into a whatever type we wanted
        switch (castAs) {
            case 'number':
            case 'int':
                return parseInt(response, 10);
            case 'float':
                return parseFloat(response, 10);
            case 'boolean':
            case 'bool':
                return response === 'true' || response === '1';
        }

        // Return the string response by default
        return response;
    };

    function dragMoveListener (event) {
        var target = event.target

        // keep the dragged position in the custom properties
        x = (getCSSCustomProp('--card-x', target, 'float') || 0) + event.dx
        y = (getCSSCustomProp('--card-y', target, 'float') || 0) + event.dy

        // add rotation based on card position
        rotation = interactMaxRotation * (x / interactThreshold);
        if (rotation > interactMaxRotation) rotation = interactMaxRotation;
        else if (rotation < -interactMaxRotation) rotation = -interactMaxRotation;

        // update styles
        target.style.setProperty('--card-x', x + 'px');
        target.style.setProperty('--card-y', y + 'px');
        target.style.setProperty('--card-r', rotation + 'deg');
    }

    onMount(() => {
        // get viewport width
        const vw = document.documentElement.clientWidth;
        // create an off canvas x coordinate
        let offX = 400;
        if (vw > 400) {
            offX = vw;
        }

        // interact.js
        interact('.card[data-status="current"]:not(:last-child)').draggable({

            onstart: () => {
                // signify dragging
                event.target.setAttribute('data-dragging', true);
            },

            // call this function on every dragmove event
            onmove: dragMoveListener,

            // call this function on every dragend event
            onend: (event) => {
                // signify dragging stopped
                event.target.setAttribute('data-dragging', false);

                // calculate how far card moved
                let moved = (Math.sqrt(Math.pow(event.pageX - event.x0, 2) + Math.pow(event.pageY - event.y0, 2) | 0));

                if (moved > interactThreshold) {
                    // remove card
                    event.target.setAttribute('data-status', "done");
                    if (x > 0) {
                        x = offX;
                    } else {
                        x = (offX * -1);
                    }
                    // activate next card
                    event.target.nextElementSibling.setAttribute('data-status', 'current');
                }
                else {
                    // reset vars
                    x = 0;
                    y = 0;
                    rotation = 0;
                    // update rotation
                    event.target.style.setProperty('--card-r', rotation + 'deg');
                }
                // update x and y pos
                event.target.style.setProperty('--card-x', x + 'px');
                event.target.style.setProperty('--card-y', y + 'px');
            }
        });
    });

</script>

<main class="container">
    <slot></slot>
</main>

That's a big chunk of code, but pretty self explanatory I hope.

Step 6: Details and finessing

With the functionality in place, there remains some refining to do. For example, you're probably going to want to include some transitions in your CSS, to make the moving and rotations smooth. An important point to consider is that having a transition on the card while it is being dragged will cause problems. That's why we added the data-dragging attribute that is toggled to true when a card is being dragged. It means you can safely add something like this to your CSS:

.card[data-dragging="false"] {
    transition: transform 0.5s;
}

I also added a small rotation to the next card in the stack, to indicate that there is a card below. There are many ways you could design this though, I'll leave that to you.