I recently struggled with getting Sortable to work in my app, as the combination of Svelte and Tauri created integration complexities. Since I didn’t find a resource that explained how to use all three together and consequently spent a lot of time debugging, here’s a one-stop post for how I managed to get it working.

Wrapping Sortable in an attachment

I created a helper function, sortableList, that returns an attachment creating a Sortable given the input options. Using it is as easy as attaching the function call to a list. I also wrote another helper function to return the order of items after a reordering.

import Sortable from "sortablejs";
import type { Attachment } from "svelte/attachments";

export const sortableList = (options: Sortable.Options): Attachment => {
  return (element: Element) => {
    const sortable = Sortable.create(element as HTMLElement, options);
    return () => {
      sortable.destroy();
    };
  };
};

export function reorder<T>(
  array: T[],
  evt: Sortable.SortableEvent,
): T[] | null {
  const newArray = [...$state.snapshot(array)] as T[];
  const { oldIndex, newIndex } = evt;

  if (oldIndex === undefined || newIndex === undefined) {
    return null;
  }
  if (newIndex === oldIndex) {
    return null;
  }

  const target = newArray[oldIndex];
  const increment = newIndex < oldIndex ? -1 : 1;

  for (let k = oldIndex; k !== newIndex; k += increment) {
    newArray[k] = newArray[k + increment];
  }
  newArray[newIndex] = target;
  return newArray;
}

<script>
  import { reorder, sortableList } from "$lib/sortable.svelte";

  // Your list of things
  const items = [
    {
      id: "item-id",
      text: "item-text",
    }
  ];

  const sortableOptions = {
    onUpdate(event: any) {
      const newList = reorder(groups, event);
      if (newList == null) {
        return;
      }
  
      // Placeholder for updating the order of items.
      updateOrdering(newList);
    }
  }
</script>

{#key items}
  <ul {@attach sortableList(sortableOptions)}>
    {#each items as item (item.id)}
      <li>{item.text}</li>
    {/each}
  </ul>
{/key}

I found that it was crucial to wrap the list in a #key block so that it’s recreated every time you reorder items. Otherwise, the Svelte and Sortable states get out of sync, and your list won’t be displayed in the expected order.

Disabling application window drag-and-drop

On a desktop app, you’re often able to drag-and-drop items directly into the application window. This functionality overrides drag-and-drop within the webview in the Tauri app. To allow drag-and-drop of the Sortable items, you need to disable the application-level drag-and-drop in tauri.conf.json via the dragDropEnabled setting.

{
    "app": {
      "windows": [
        {
          "dragDropEnabled": false
        }
      ],
    }
}

Disabling the HTML5 DND implementation

Sortable has two implementations for its drag-and-drop functionality based on whether the browser supports HTML5. After some experimentation, I realized that the HTML5 DND implementation does not work in Tauri. Specifically, I noticed that I would often be unable to reorder items consecutively — after moving one item, I had to click anywhere else on the view to “reset” and be able to move the next item. To fix this problem, force Sortable to use the non-HTML5 implementation with the option forceFallback.

const sortable = Sortable.create(el, {
  ...options,
  forceFallback: true,
});

Many thanks to these resources which proved quite helpful while I was attempting this:

• https://dev.to/jdgamble555/svelte-5-and-sortablejs-5h6j
• https://www.reddit.com/r/tauri/comments/1hg85k7/using_vue_3_dragable_components_why_do_i_need_to/

When you use Azure CDN to deliver content, you may need to purge your endpoint so that changes you make are sent to your users, as files are cached in the Azure CDN until their time-to-live (TTL) expires. If you don’t set a TTL for your files, Azure automatically sets a TTL of 7 days. Even if you set a lower TTL, your updates may not coincide with the cache expiration.

For example, my personal website uses Azure CDN and is updated on every push I make to GitHub. It’s tough to set a good caching rule for this because my changes are unpredictable. When I’m working on my site, I might push several times a day, but I can also go weeks without modifying my website.

While it is possible to purge an endpoint through the Azure portal, I wanted to automate this process. Fortunately, this is possible with GitHub Actions.

Creating a Service Principal

An Azure service principal is “an identity created for use with applications, hosted services, and automated tools to access Azure resources”. It is recommended, for better security, to use service principals with automated tools, since access is restricted by roles assigned to the service principal. In this section, I’ll discuss how to create a service principal and give it the CDN Endpoint Contributor role. To get started, you’ll need the Azure CLI.

To create a new service principal, enter the following command in your terminal, making sure to copy the correct<subscription_id> and <resource_group_name> from your Azure portal.

az ad sp create-for-rbac -n "<name_of_service_principal>" --role "CDN Endpoint Contributor" --sdk-auth --scopes /subscriptions/<subscription_id>/resourceGroups/<resource_group_name>

The output will look similar to the following; be sure to copy and save it somewhere safe, as you will not be able to retrieve the clientSecret in the future.

{                                                                                 "clientId": "<GUID>",                             
"clientSecret": "<GUID>",                         
"subscriptionId": "<GUID>",                       
"tenantId": "<GUID>"
}

In the command, we are creating a service principal and assigning it a role of “CDN Endpoint Contributor”. This allows the service principal to manage CDN endpoints. The --sdk-auth flag causes the output to be correctly formatted for use in the GitHub Action; without it, you will get the following error when you copy the output to GitHub.

Error: Not all values are present in the creds object. Ensure clientId, clientSecret, tenantId and subscriptionId are supplied.

Adding GitHub Secrets

Add the following secrets (encrypted environment variables) to your GitHub repository:

1. AZURE_CREDENTIALS: paste the output from the az ad sp create-for-rbac command.
2. AZURE_CDN_ENDPOINT: the name of your Azure CDN endpoint.
3. AZURE_CDN_PROFILE_NAME: the name of your Azure CDN profile.
4. AZURE_RESOURCE_GROUP: the name of the resource group containing the Azure CDN profile.

Writing the GitHub Actions Workflow File

Now that you have a service principal and GitHub secrets, all that remains is to write the GitHub Action. There are two essential steps in the workflow: 1) logging in to Azure, and 2) purging the CDN. To start, go to your repository on GitHub and select the “Actions” tab. Click “New workflow”, then choose “Set up a workflow yourself” or the appropriate starter for your needs.

The following is the bare minimum required for this workflow.

The Azure service principal login step logs in to Azure CLI with the credentials you added to your GitHub secret. The Purge CDN step purges the CDN, so your updates should occur between these two steps. In the Purge CDN step, --content-paths "/*" purges all content. --no-wait means the script does not wait for the purge operation to finish before continuing; this flag is optional. You can read more about the az cdn endpoint purge command here.

That’s all there is to it, happy coding!

I host my own static website on Azure Storage, and I got tired of running a script to upload my content every time I made a change to my website. After some Googling, I discovered GitHub Actions, made public about a month ago, which lets users automate how they build, test, and deploy their projects. Interestingly, though I found great guides for automating static website deployment to Azure using GitLab and building and deploying Gatsby sites with GitHub Actions, there wasn’t one guide with everything I needed, and I had to cobble pieces together from different sources. This is an attempt to rectify that.

This post assumes your static website is already up and running on Azure Storage. If not, the Azure documentation on static website hosting was enough for me to get started.

Setup

To begin, go to the Azure Storage account with your static website content, and find the setting “Access keys”. Copy either one of the connection strings; this is needed to upload content to Azure via GitHub actions.

Now, open your personal website repository on GitHub. Go to the settings tab and select “Secrets” in the left panel. Click “Add a new secret”, name it “AZURE_STORAGE_CONNECTION_STRING” (you can use a different name as long as you update the GitHub Actions .yml accordingly), and paste the connection string value obtained from Azure into the “Value” area.

Workflow Script

To build your Action, go to the “Actions” tab in your repository. Select “New workflow” and use the Node.js starter.

In the page that loads, paste the following code into the editor.

The above .yml is tailored to my personal website, which was built with React and Gatsby. Hence, you may not need all the steps listed.

1. The Install dependencies step is only necessary if you used Node packages.
2. The Build with Gatsby step can be replaced with your build command, if you have one.
3. The Azure upload step is the only required step. The first line in the script deletes all your old files in Azure, while the second uploads your local files. Since Gatsby generates my website files in the public folder, I upload that (-s parameter); you may need a different value there.

After uploading your files, you may need to purge your CDN endpoint to see the updates. (Update: I now use GitHub actions to automate purging.)

That’s it! Now, your content will automatically be uploaded to Azure Storage on every push.