DEV Community: Jim Bridger

Dnd-Master: Lightweight, Powerful Drag-and-Drop for Svelte

Jim Bridger — Thu, 16 Oct 2025 20:22:45 +0000

A big thankyou to epicenter for sponsoring my open source work.

Have you ever noticed that when it comes to drag and drop options, the choices seem to be:

Use the Native Drag and Drop API (which everyone should do exactly once), or;
Use this fully-featured library with a big detailed API to learn, and we hope you want to animate lists

There doesn't really seem to be a middle-ground: something that abstracts over the painful parts of the native experience, but that is also dead simple to use and flexible. Powerful, even.

So I made Dnd-Master; a minimal hooks-based solution that is extendable via middleware. And it's typesafe. In this article, I'll go over the basics of how it works and then show examples of two-way validation and a dynamic ghost element.

This is just meant to be a quick read so you can decide if it's right for you; for the full README, visit the github repo.

You can also find a test playground here.

Dragging

To pass some data, use dnd.draggable to create an attachment, and attach it to an element:

const draggable = dnd.draggable("My data")

<div {@attach draggable}>My data</div>

Creating a dropzone is almost the same, but pass it a callback instead of an object:

const dropzone = dnd.dropzone(data => console.log(data))

<div {@attach dropzone}>Drop here</div>

That's pretty straightforward, but the real fun begins when we start using hooks:

let timesDropped = $state(0)

const draggable = dnd.draggable("My data", {
   drop: () => timesDropped++
})

Notice that here, we're running some drop-aware logic on the data side of things, without needing to connect anything to the drop callback, which might very well be in a different component.

Both the data and drop attachments can implement all the native drag events as hooks, as well as a couple of others, and middlewares can provide more.

Middleware

Dnd-Master comes with two middlewares: Validate and Ghost. Let's quickly look at how to validate data, then we'll create a ghost element, and then we'll finish by implementing two-way validation and a dynamic ghost that responds to different dropzones.

Validation

To validate data, use assertData. This function takes a predicate, and returns a validator function that also has a builder on it that replaces dnd.draggable. Like this:

const isString = dnd.assertData(data => typeof data === "string")

const dropzone = isString.soDrop(data => lastDropped = data)
// this will only run your drop callback if the predicate is true

You can also make your drop callback typesafe by using a type assertion in assertData:

const isString = dnd.assertData(
   (data): data is string => typeof data === "string"
) //     ^^^^^^^^^^^^^^^^

const dropzone = isString.soDrop(data => lastDropped = data)
// now typescript knows data is a string!

I like this approach because it encourages me to use a feature that I always forget exists, without abstracting over it.

Ghost

First, let's create an element to use as our ghost. We'll wrap it in <template> so it doesn't appear in the DOM:

<template>
   <div class="ghost" bind:this={ghostElement}>👻 Ghost</div>
</template>

You could style this however you like. Now here's how to add it to the dragged element:

let ghostElement = $state<HTMLDivElement>()

const draggable = dnd.draggable("My item", {
   dragstart: () => dnd.setGhost(ghostElement)
})

We can just use the dragstart hook, as well as the setGhost function provided by the ghost middleware. Painless.

Advanced Examples

Two-way Validation

We already saw how to validate data. Here's how to validate a dropzone:

const isValidZone = dnd.assertZone(
   element => element.dataset.zone === "valid"
)

const draggable = isValidZone.soGive("My item")

// and let's validate some data again:
const isString = dnd.assertData(
   (data): data is string => typeof data === "string"
)

const dropzone = isString.soDrop(data => lastDropped = data)

<div {@attach draggable}>My item</div>

<div data-zone="valid" {@attach dropzone}>Valid Dropzone</div>

Now both sides of the drag and drop flow will validate before passing the data.

Dynamic Ghost

Here we want a ghost that will update when over different dropzones.

let defaultGhost = $state<HTMLDivElement>()
let validGhost = $state<HTMLDivElement>()
let invalidGhost = $state<HTMLDivElement>()

const isValidZone = dnd.assertZone(element =>
   element.dataset.zone === "valid"
)

const dynamicItem = isValidZone.soGive("Item with Dynamic Ghost", {
   dragstart: () => dnd.setGhost(defaultGhost),
   dragleave: () => dnd.setGhost(defaultGhost),
   dragover: (_event, element) => {
      isValidZone(element)
         ? dnd.setGhost(validGhost)
         : dnd.setGhost(invalidGhost)
   }
})

const dropzone = dnd.dropzone(data => console.log(data))

<div {@attach draggable}>My item</div>

<div data-zone="valid" {@attach dropzone}>Valid Dropzone</div>
<div data-zone="invalid" {@attach dropzone}>Invalid Dropzone</div>

<template>
   <div bind:this={defaultGhost}>👻 Ghost</div>
   <div bind:this={validGhost}>✅ Drop here!</div>
   <div bind:this={invalidGhost}>❌ Can't park here mate</div>
</template>

And that's it! Notice that we didn't need to create two separate dropzones; all our validation is data-based in the element data attributes. You could of course choose a different method, the data attribute approach is nothing to do with the library itself, just an idiomatic way of doing it.

Hopefully that's enough to make you interested in trying out Dnd-Master. You can find it on github and npm. It's open source, MIT Licensed, and ready to be expanded with more middleware!

If you use it, let me know how it goes!

How I Recreated Keynote's Magic Move with Svelte Snippets

Jim Bridger — Sat, 30 Aug 2025 11:53:55 +0000

A big thankyou to epicenter for sponsoring my open source work.

Earlier this week, I woke up with a thought: would it be possible to automate transitions between components purely by using element IDs, in a similar way to how View Transitions or Magic Move work? The catch was, I specifically did not want to write ANY transition logic. At all.

I figured that in order to transition between multiple elements as if they were one, they would need to have a persistent container that never left the page, and I would need to swap the relevant elements in and out.

So I would need to rip the elements out of a bunch of components, and store them somehow, ready for use. Oh, and I wanted to keep any reactivity intact.

My first thought was, what if I pass the components into a Stage component through its children snippet, and then instead of rendering the snippet, get inside it somehow and take the elements?

Since you normally render snippets using {@render children()}, what if I just call children in my script tag? Well, if you try it, you get this: Cannot read properties of undefined (reading 'before'). So, the children snippet is expecting some object, which has a property called 'before'. Interesting.

children({ before: null }) 
// error: anchor.before is not a function

Ok, so before should be a function. Let's expect some arguments and see what we get.

children({ before: (...args) => console.dir(args) })

...and wouldn't you know it, this gives us a Node, or a DocumentFragment - exactly what we need. Easy!

From here, I scanned through every element, (helpfully separated per component by comment nodes, thanks Svelte) and added each id to a set. Then I created persistent containers (which I'll call marks) from this set.

Here was the real challenge though: How do you swap elements in and out of your DOM while transferring their styles to a parent element and ensuring everything looks the way it ought to?

Well, you can do it manually if you want. I did. I even made Show & Svelte's first video this way. But it's incredibly brittle, it breaks some reactivity, and in general it's just a Rube Goldberg machine with an arsenal of edge cases to sting you with. So let's skip over the entire ordeal and keep this article on track. If you want to see what it looked like, here you go.

Fast forward a couple of days, and I was still thinking about snippets. Since createRawSnippet exists, I thought, it must be possible to convert all those root elements into their own snippets, and then render them inside their marks.

Unfortunately, anyone who's tried using Svelte to this level has probably also noticed something. A lot of this stuff is fairly conservatively documented:

function createRawSnippet<Params extends unknown[]>(
    fn: (...params: Getters<Params>) => {
        render: () => string;
        setup?: (element: Element) => void | (() => void);
    }
): Snippet<Params>;

You just read the entirety of the createRawSnippet documentation.

For starters, what the above doesn't tell you is that the element parameter in setup will be the topmost element that you put inside render. Try to use createRawSnippet and pass an empty string to render, and all you'll get is: Illegal invocation, an uncharacteristically unhelpful error. Add an element though:

const mySnippet = createRawSnippet(() => ({
        render: () => "<div id='render-div'></div>",
        setup: (element) => console.log(element)
    }))

// this will log the div#render-div to the console.

Eventually, after reading through various discussions, issues and pull requests on the svelte github, and pasting svelte source code into Claude and asking him to dumb it down for me, I learned how to create reactive snippets with createRawSnippet:

let count = $state(0)

const mySnippet = createRawSnippet(() => ({
      render: () => `<div></div>`,
      setup: (div) => {
         $effect(() => {
            div.textContent = count
         })
      }
   })
)

As best as I can figure out, in the above example, we need to wrap div in $effect because it's a new div. We just created it right there in render. It isn't a dependency of any current effects.

However, in our case below, if we made our root element reactive in the original scene component, then it already exists as an effect dependency somewhere, and its reactivity will be preserved even if we move it, because effect dependencies are stored by node reference.

Also note that we're not trying to add any new reactive dependencies here, like putting count in setup or anything. We're just moving the node.

// ourRootElement was extracted from the original snippet

const mySnippet = createRawSnippet(() => ({
      render: () => `<div></div>`,
      setup: (div) => {
         div.appendChild(ourRootElement);
      }
   })
)

Hopefully that's at least partially correct. I set up this playground to test my understanding and it seems ok.

So now we have a way to render our scene components' root elements inside their marks, and it appears to be capable of preserving the reactivity we set up. It feels like we're close to a solution.

For clarity, here's an example structure:

- Slide/Scene Component 1
  - <article id="title">

- Stage
  - <Mark id="title">
    - #snippet (the one we've been talking about making)
      - <div></div> (created inside `render`)
        - <article id="title"> (appended to `div` in `setup`)

Next we need something that we can append our scene element to in setup. This obviously can't be our mark, because that already exists; we're trying to render this created snippet inside it. We also have to create an element in render. We'll also need a reference to our mark in just a moment. Three birds. One div.

So we put a div in render and then in setup, we append our element to it. Then we use div.parentNode to get the reference to our mark which we need because we're going to transfer our scene element's styles to it*.

Or rather, we're going to transfer our scene element's className to the mark (it already has the id from creation), which will achieve the same thing:

createRawSnippet(() => ({
   render: () => "<div></div>",
   setup: (div) => {
      const mark = div.parentNode;
      swapClass(element, mark)
      element.removeAttribute("id")
      div.appendChild(element);
      return () => {
         swapClass(mark, element)
         element.id = mark.id
      }
   }
}))

The final code, minus boring stuff like type checking.

And with that, we have seamless transitions between elements in different components, without needing to write any transition logic at all. Pretty sweet! Our components are just a collection of root elements with IDs that we can style internally with scoped styles, and then pass as children into our Stage.

Here's a short video of what all of that looks like, made with Show & Svelte of course.

Snippet gang rise up!

Show & Svelte is 100% open source, MIT Licensed, and available on github and npm. Comes with full markdown and code editing support, with syntax highlighting.

So far it's been a game changer for me making videos for YouTube, a process that I genuinely hated before. Check it out and let me know how it goes!

Discord | Github

* ...to save you a huge amount of trouble in future, remember this: if you want to transfer CSS styles from one element to another, you ONLY need to transfer the ID and the className. Not the, you know, actual styles. And you certainly don't need to render an entire offscreen stage element populated with clone elements from which you get computed styles, and then sift through which styles actually get included in computed styles, not to mention that you're now dealing with the results of the CSS calculations instead of the actual CSS and... well... ID and className. That's. All. You. Need.

Write less code with Svelte 5's dot notation: self-populating components

Jim Bridger — Wed, 30 Apr 2025 11:13:09 +0000

This is a trick I came up with a few months ago and have been using regularly. It lets you render a component for a specific object without needing to import the component and without needing to pass the object as a prop. Two very common occurrences!

First, here's the component we want to render:

<script lang="ts">
   import { type Instance } from "$lib/classes/Instance.svelte.js"

   let { instance }: { instance: Instance } = $props()
</script>

{instance.name}

Now, here's the effect of what we're going to do, both before and after, with the relevant lines marked:

Before:

<script lang="ts">
   import InstanceComponent from './Instance.svelte' // this line
   import { Instance } from '$lib/classes/Instance.svelte.js'

   const instance = new Instance("Hello there")
</script>

<InstanceComponent {instance} /> <!-- this prop -->

After:

<script lang="ts">
   import { Instance } from '$lib/classes/Instance.svelte.js'

   const instance = new Instance('General Kenobi')
</script>

<instance.component />

To make it work, first save this function somewhere in your project:

import { type Component as ComponentType } from "svelte";
import { type ComponentInternals } from 'svelte'

interface Props {
   [key: string]: any
}

export function withProps<T extends Props>(Component: ComponentType, defaultProps: T) {
   return function ($$anchor: ComponentInternals, $$props: Partial<T>): ReturnType<typeof Component> {
      const mergedProps = { ...defaultProps, ...$$props };
      return Component($$anchor, mergedProps);
   };
}

You don't necessarily need the typescript type imports or interface, but I add it for completeness.

Next, make a class for your object, and add a component getter, like this:

import { withProps } from "$lib/functions/with-props.js"
import InstanceComponent from "$lib/components/Instance.svelte"

export class Instance {
   public name = $state('')

   constructor(name: string) {
      this.name = name
   }

   // has to be a getter for the component to be reactive
   get component() {
      return withProps(InstanceComponent, { instance: this })
   }
}

That's it! Now you can use Svelte 5's dot notation to write less code! :)

Ok, here's how the withProps function works. It's pretty straightforward. Let's look at it without the typescript:

export function withProps(Component, defaultProps) { // this line is called when defining get component()
   return function ($$anchor, $$props) { // this line is called by the dot notation
      const mergedProps = { ...defaultProps, ...$$props }; // anchor is the element to be added to
      return Component($$anchor, mergedProps); // this is what is returned to be rendered
   };
}

All this function does is take the imported component, and the props you want to add by default (which in this case is the class instance.) We're doing this in the component getter. Then withProps returns a function that merges the default props with the props that are passed to the component when Svelte needs to render it, i.e. when you use the dot notation, which in this example is the <instance.component />.

You can of course add more props in the normal way, so say you added a second prop to the component:

let { instance, nonDefaultProp } = $props()

<instance.component nonDefaultProp="How did this happen?" />

Then you would only need to pass that second prop when calling the component.

You can also override the default prop:

<instance.component instance={{ name: "override "}} />

That's everything I know about it. It's been working for me for months and I haven't had any issues with it so far. That said, if anyone knows why it's a bad idea, please let me know! :D