DEV Community: Tias

Cloudflare Workers tutorial with custom domain

Tias — Mon, 21 Jul 2025 03:05:34 +0000

So I spent too long figuring this out. After implementing the Caching recommendations from the OpenNext docs, I hit a cryptic error, which you'll read about below, and then I found the answer (thanks to a random Discord comment). I'm writing this article so you can just get it working too.

Goals:

Use @opennextjs/cloudflare.
Deploy via GitHub Actions.
Connect to a custom domain.
Use a monorepo.

We started with the standard command:

pnpm create cloudflare@latest example.com --framework=next

Note: the OpenNext page uses a --platform=workers arg that apparently doesn't do anything (I diffed it). The Cloudflare page omits it.

That command generates a bunch of files and I'm going to assume that you ran that. I'm not going to print every file here.

The one important thing is that my project is a monorepo, with a web directory for the website workers project. You'll see this web path in the GitHub actions job.

wrangler.jsonc

Here is the wrangler config.

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "web",
  "main": ".open-next/worker.js",
  "compatibility_date": "2025-07-20",
  "compatibility_flags": [
    "nodejs_compat",
    "global_fetch_strictly_public",
  ],
  "observability": {
    "enabled": true,
  },
  "routes": [
    {
      "pattern": "example.com",
      "custom_domain": true,
    },
  ],
  "assets": {
    "binding": "ASSETS",
    "directory": ".open-next/assets",
  },
  "services": [
    {
      "binding": "WORKER_SELF_REFERENCE",
      "service": "web",
    },
  ],
  "r2_buckets": [
    {
      "binding": "NEXT_INC_CACHE_R2_BUCKET",
      "bucket_name": "next-inc-cache",
    },
  ],
  "durable_objects": {
    "bindings": [
      {
        "name": "NEXT_CACHE_DO_QUEUE",
        "class_name": "DOQueueHandler",
      },
    ],
  },
  "migrations": [
    {
      "tag": "v1",
      "new_sqlite_classes": ["DOQueueHandler"],
    },
  ],
  "d1_databases": [
    {
      "binding": "NEXT_TAG_CACHE_D1",
      "database_id": "______________",
      "database_name": "next-tag-cache",
    },
  ],
  "send_metrics": false,
}

The routes block connects it to my custom domain (which is not example.com, opsec or whatever). I don't think you need to set up the custom domain in the dashboard manually, but you do definitely need to have the domain set up in the dashboard as a zone. You can't use someone else's domain, sorry.

My domain didn't have any records, and cloudflare sets up the records automatically when it creates the "custom domain" for the worker.

I wasn't sure if WORKER_SELF_REFERENCE was required, but it shouldn't hurt.

You do need to manually create an R2 bucket named next-inc-cache.

Also, create a D1 database named next-tag-cache and paste its id in database_id.

Yeah I disabled metrics. Mostly for maximal performance... Cloudflare should understand.

open-next.config.ts

import { defineCloudflareConfig } from '@opennextjs/cloudflare';
import r2IncrementalCache from '@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache';
import d1NextTagCache from '@opennextjs/cloudflare/overrides/tag-cache/d1-next-tag-cache';
import doQueue from '@opennextjs/cloudflare/overrides/queue/do-queue';


export default defineCloudflareConfig({
  incrementalCache: r2IncrementalCache,
  queue: doQueue,
  tagCache: d1NextTagCache,
});

NBD. The hardest part here was changing the double quotes to single quotes.

By the way, can you believe that wrangler uses tabs in its generated types file? Unconscionable! How do these people make it out of bed in the morning!

.github/workflows/deploy.yml

name: Deploy Workers

on:
  push:
    branches:
      - main

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    env:
      CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
      CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

    steps:
      - uses: actions/checkout@v4

      # Install node and npm with cached pnpm installation.
      # https://github.com/pnpm/action-setup?tab=readme-ov-file#use-cache-to-reduce-installation-time
      - uses: pnpm/action-setup@v4
        with:
          run_install: false
      - uses: actions/setup-node@v4
        with:
          node-version-file: '.nvmrc'
          cache: 'pnpm'
      - run: pnpm install

      - name: Cache Next.js build
        uses: actions/cache@v4
        with:
          path: ${{ github.workspace }}/web/.next/cache
          # Generate a new cache whenever packages or source files change
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/pnpm-lock.yaml') }}-${{ hashFiles('**/*.js', '**/*.jsx', '**/*.ts', '**/*.tsx') }}
          # If source files changed but packages didn't, rebuild from a prior cache
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/pnpm-lock.yaml') }}-

      - name: Deploy
        run: |
          cd web
          pnpm run deploy

You need to add these repository secrets:

CLOUDFLARE_API_TOKEN
CLOUDFLARE_ACCOUNT_ID

About the API token. It needs (some if not all of) these permissions:

Your Account
- Workers KV Storage:Edit
- Workers Scripts:Edit
- Account Settings:Read
- Workers Tail:Read
- Workers R2 Storage:Edit
- Cloudflare Pages:Edit
- Workers Builds Configuration:Edit
- Workers Observability:Edit
- D1:Edit
Your zone - Workers Routes:Edit
All users - User Details:Read
- Memberships:Read

I got these permissions by choosing the API token preset called "Edit Cloudflare Workers". However, I also needed to add the D1:Edit permission.

If there is no D1:Edit permission, you'll see this error:

Creating D1 table if necessary...
ERROR Wrangler command failed
ELIFECYCLE  Command failed with exit code 1.

So helpful, right? (I wonder if prefixing WRANGLER_LOG="debug" would make it more verbose.)

Technically the CLOUDFLARE_ACCOUNT_ID doesn't need to be a secret, but I'm doing what I know works.

This job has some npm caching stuff, and the actions are all up to date and using best practices.

Oh, remember to create a .nvmrc file containing the string 22, or whatever version of node you use.

Beware the line 33 has the path web. Change that if you don't use a monorepo or if your path is different.

Also the cd web line in the deploy step.

And here's a snippet from my package.json scripts:

    "opennext:build": "opennextjs-cloudflare build",
    "deploy": "pnpm run opennext:build && opennextjs-cloudflare deploy",

That's all

Yeah I guess that's it!

Starting with semver `1.0.0`

Tias — Sun, 05 Jan 2025 18:33:40 +0000

Look I get it. You're releasing a new package... stepping out, uncertain if the library will need changes. So you say, "maybe I should release v0 now and release v1 later when it's ready enough". This article will attempt to persuade you to release v1 from the beginning.

There are a few reasons to release v1:

SemVer 0.x versions are different
be confident and take it seriously
project strength

To me, it seems that the various reasons for v0 boil down to:

uncertainty
laziness
lack of understanding / skill issue

...

But after reading this interesting Issue on the semver repo: https://github.com/semver/semver/issues/221 my opinion is changing. Using version 0.x indicates instability, true, but the reality is that some libraries are unstable.

What do I mean by unstable? It's not that the library changes (because those changes can be planned and be represented by major version numbers). Instability relates to the prevalence of bugs.

Bugs may be:

regular software bugs, or
breaking changes released in a minor or patch versions.

Side note: there's little difference between these two. A lot of bugs are just mismatches or incompatibilities between APIs.

So --- how likely is it that your library will break for consumers? Only library maintainers can answer this question, and it's often sourced from experience with issues that have been brought up over time by your consumers.

But how do you know how unstable the library will be before you release it? Maybe a period of time in 0.x is a good idea.

But will the library ever get out of 0.x? Because inertia is a real thing. Will you have time? Will it pass the committee? That's a risk.

On the other hand, the risk of releasing 1.0.0 is that consumers will get instability if they upgrade frequently. But there are mitigations to this. Firstly, with lockfiles, upgrading packages is a manual action. Consumers are not affected by issues unless they upgrade. And they can simply not upgrade, or defer the upgrade until later.

New consumers may land on a buggy release, that's true, but that would be the case in the 0.x system also.

Libraries like storybook are not very stable between versions (in my experience), yet they're still not using 0.x. For what it's worth.

And then there is the area of transitive dependencies. If your package is a dependency of another package, then that other package needs to decide what semver range to use. Your stability affects that package's stability, so the stakes are higher.

Either that package pins your library or uses a broader semver range. In the first case, it causes duplication which is bad for performance. In the second case it risks instability. I'd wager to say that the first option is a non-starter and instability is always a risk.

I don't have an answer here, but the main point is that if your library is used by other libraries then the stakes are higher and you should probably make sure your library is stable.

So you should try to write a stable library, but if it's unstable then go ahead and use 0.x until it's stable. But if you can, use 1.x.

Using Terraform to deploy a web site to a DigitalOcean droplet with Cloudflare

Tias — Mon, 23 Sep 2024 20:22:31 +0000

It took me way too long to find this golden combination.

Here are the goals:

The web files deploy to a nginx droplet.
Cloudflare manages the DNS for the domain.
The www subdomain redirects to the bare TLD.
Cloudflare does the SSL.
http connections are always upgraded to https.
Redeployments happen with zero downtime.

This isn't all, but it's worth posting so far.

main.tf

I'll paste it in sections:

Setup


terraform {
    required_version = ">= 1.0.0"
    required_providers {
        digitalocean = {
            source = "digitalocean/digitalocean"
            version = ">= 2.0"
        }
        cloudflare = {
            source = "cloudflare/cloudflare"
            version = "~> 4.0"
        }
    }
}

# DigitalOcean provider
provider "digitalocean" {
    token = var.digitalocean_token
}

# Cloudflare provider
provider "cloudflare" {
    email = var.cloudflare_email
    api_key = var.cloudflare_api_key
}

You probably have all the provider stuff squared away, if you've arrived here from a Google search. But it's here for completeness.

Cloudflare DNS

resource "cloudflare_record" "main_app" {
    zone_id = var.cloudflare_zone_id
    name = "example.com"
    content = digitalocean_reserved_ip.main_ip.ip_address
    type = "A"
    proxied = true
}

resource "cloudflare_record" "www_cname" {
    zone_id = var.cloudflare_zone_id
    name = "www"
    type = "CNAME"
    content = "example.com"
    proxied = true
}

The first is the important one. It directs the domain to the static IP address of the DigitalOcean droplet.

DigitalOcean calls this a "Reserved IP", but in the past it was called a "Floating IP". FYI.

The CNAME section ... I think ... will redirect the www subdomain to the bare TLD. I say "I think" because I have no idea. Feel free to experiment by leaving this off.

proxied = true makes sense because Cloudflare is proxying all of our traffic, if you didn't realize.

Cloudflare SSL

resource "cloudflare_zone_settings_override" "https_redirect" {
    zone_id = var.cloudflare_zone_id
    settings {
        always_use_https = "on"  # This ensures HTTP is upgraded to HTTPS
    }
}

resource "cloudflare_ruleset" "redirect_from_value_example" {
    zone_id = var.cloudflare_zone_id
    name = "www"
    description = "Redirects ruleset"
    kind = "zone"
    phase = "http_request_dynamic_redirect"

    rules {
        action = "redirect"
        action_parameters {
            from_value {
                status_code = 301
                target_url {
                    expression = "concat(\"https://example.com\", http.request.uri.path)"
                }
                preserve_query_string = true
            }
        }
        expression  = "(starts_with(http.host, \"www.\"))"
        description = "Redirect www to non-www"
        enabled = true
    }
}

always_use_https = "on":

Always Use HTTPS redirects all your visitor requests from http to https, for all subdomains and hosts in your application.

Good stuff.

Now, about that ruleset. It works but I'm not confident that it's the ideal solution. I feel like the API should have a "Redirect Rules" surface, because that's a thing in the console. But apparently here you can only use Page Redirects or raw rulesets. Please comment if you know what it should be.

Anyway, this does a 302 redirect from www to the bare TLD, and I'm not concerned about preserving paths or query strings, because it takes user effort to turn a valid url into a non-working www url. I just don't care about that rare scenario when someone manually edits a path-bearing URL to add a www, and sends it to someone else without checking it. Their path will get stripped. Sucks for them.

DigitalOcean project

data "digitalocean_project" "project" {
    name = "My Project"
}

resource "digitalocean_project_resources" "main_app_project" {
    project = data.digitalocean_project.project.id
    resources = [
        "do:droplet:${digitalocean_droplet.main_app.id}",
        "do:floatingip:${digitalocean_reserved_ip.main_ip.id}"
    ]
}

I have a dedicated project that I'm creating these resources in. Without this, the resources would be created in the default project.

The Reserved IP Address

resource "digitalocean_reserved_ip" "main_ip" {
    droplet_id = digitalocean_droplet.main_app.id
    region = digitalocean_droplet.main_app.region
}

This digitalocean_reserved_ip is what worked for me. I tried getting digitalocean_reserved_ip_assignment to work, but it always deregistered the reserved IP from the live droplet before the replacement droplet was provisioned. This was unacceptable because it created a period of downtime lasting minutes. Completely unacceptable.

SSH Key

resource "digitalocean_ssh_key" "my_key" {
    name = "mykey"
    public_key = file("~/.ssh/mykey.pub")
}

This SSH key is for letting me ssh into the droplet.

Resource-Based Invalidation

data "external" "hashes" {
    program = ["bash", "${path.module}/generate_hash.sh"]
}

When I change the html files or the initialization script (see below), I want it to trigger a replacement of the droplet. By default, terraform doesn't recreate a droplet if its user_data or remote-exec blocks change. Weird, I know. So this is a way of hacking around it.

We hash all the files and use the resulting hash to invalidate.

Here is generate_hash.sh:

#!/bin/bash

# Compute hash of all files in the HTML directory
HTML_HASH=$(find ../web/dist -type f -exec sha256sum {} \; | sha256sum | awk '{print $1}')

# Compute hash of the main-server-init.sh script
SCRIPT_HASH=$(sha256sum ./setup/main-server-init.sh | awk '{print $1}')

# Combine the two hashes
COMBINED_HASH=$(echo -n "${HTML_HASH}${SCRIPT_HASH}" | sha256sum | awk '{print $1}')

# Output the combined hash in JSON format
echo "{\"inputs_hash\": \"$COMBINED_HASH\"}"

The droplet

resource "digitalocean_droplet" "main_app" {
    name = "main-app"
    region = "nyc1"
    size = "s-1vcpu-1gb"
    image = "ubuntu-24-04-x64"
    ssh_keys = [digitalocean_ssh_key.my_key.id]

    # Trigger recreation on changes to input files.
    user_data = "# inputs_hash: ${data.external.hashes.result.inputs_hash}"

    lifecycle {
        create_before_destroy = true
    }

    connection {
        type = "ssh"
        user = "root"
        private_key = file("~/.ssh/mykey")
        host = self.ipv4_address
        timeout = "5m"
    }
    provisioner "remote-exec" {
        inline = [
            "mkdir -p /tmp/html",
        ]
    }
    provisioner "file" {
        source = "${path.module}/../web/dist/"
        destination = "/tmp/html"
    }
    provisioner "remote-exec" {
        script = "setup/main-server-init.sh"
    }
}

The user_data block now only has the invalidation hash. It doesn't have any cloud-init scripts, because I'm handling that in a custom script (setup/main-server-init.sh) in the remote-exec provisioner block.

lifecycle.create_before_destroy is critical to getting a zero-downtime deploy. This way, when you run terraform apply, your current droplet will continue to serve requests while your new droplet is building. And only after it's ready does the Reserved IP switch over to the new droplet. So, an instant cutover.

Here is main-server-init.sh:

#!/bin/bash
set -x # echo commands
set -e # fail on errors

# Upgrade to get security fixes
export DEBIAN_FRONTEND=noninteractive
apt -q update -y
apt -q upgrade -y 
apt -q install -y nginx
curl -sSL https://repos.insights.digitalocean.com/install.sh | bash

# Remove the default Nginx index file
rm -rf /var/www/html
mv /tmp/html /var/www/html

# Nginx
systemctl enable nginx
systemctl start nginx

# Configure the firewall
ufw allow OpenSSH
ufw allow 'Nginx Full'
ufw allow http
ufw allow https
ufw --force enable

# Start Nginx
systemctl restart nginx

echo "Server setup complete."

Not perfect, but it's what I have.

Improvements

I'd like to separate the html files from the nginx init script, so that I can update the deployed files without recreating the whole droplet. It's safe enough.

The DigitalOcean droplet no longer shows its graphs in the console. This is how you get it working, but ufw is probably misconfigured.

It could use a health check to make sure nginx started properly.

That's it!

Why LitElement isn't as good as React

Tias — Wed, 10 Mar 2021 22:25:11 +0000

^ Photo of a bear-proof garbage container from Humpback Rock in the Blue Ridge Parkway (Virginia). Note: LitElement is not garbage, but I couldn't resist the pun.

This is an opinionated and unordered list of the downsides of lit-element and web components compared to React. It does not list any downsides of React, so take it with a grain of salt. Many of these reasons apply to other WC frameworks, and even the spec itself.

Default values are more complicated

Web components are classes*, and input is given as properties. We often want to default the properties, giving them a default value when a value is omitted. In functional patterns like angularjs link functions or React function components, this is done with a single variable assignment at the beginning:

link: (scope) => {
    const closeDelay = isDefined(scope.closeDelay) ? scope.closeDelay : 300;
...

** WCs don't have to be classes. See matthewp/haunted which uses hooks like React. But that library is not a mixin or wrapper around lit-element; it would replace lit-element. It does use lit-html though.

Why does this matter? It's just a more burdensome way of coding. This may be tenable, but our code needs to resolve defaults very often, and focusing on small details can distract from focusing on bigger issues like data flow and asynchronicity.

Property initialization is an antipattern

class MyThing extends LitElement {
    @property({type: Number})
    closeDelay = 300;
...

While this may seem to be a solution, it does not achieve the kind of idempotent defaultness that we want. We want the value to always have a default, not just at the beginning.

// Oops the default is gone:
el.closeDelay = undefined;

Suboptimal solutions

Defaulting everywhere

Instead of resolving the defaulted value in one place, it gets resolved in every usage site:

...
setTimeout(fn1, this.closeDelay ?? DEFAULT_CLOSE_DELAY);
...
setTimeout(fn2, this.closeDelay ?? DEFAULT_CLOSE_DELAY);
...

The "defaulting everywhere" workaround is suboptimal because it's error prone and complexifies the code.

Using a getter property as a proxy

class MyThing extends LitElement {
    @property({type: Number})
    closeDelay: number;
    get defaultedCloseDelay (): number {
        return this.closeDelay ?? DEFAULT_CLOSE_DELAY;
    }
...

This is ok but still suboptimal because it adds noise, and the closeDelay property remains at risk of getting mistakenly used.

...
setTimeout(fn1, this.defaultedCloseDelay); // ok
...
setTimeout(fn2, this.closeDelay); // oops!
...

Compared to classes, functions provide the simplest pattern for resolving default values.

Property validation / sanitization / transformation / deriving data is more complicated

When a component receives a property value, and:

validates it
sanitizes or transforms it (trimming spaces, normalizing)
deriving data from it

There's no good place to do this. In React functional components, you'd do this simply at the top of the function, or within useMemo if you need to memoize it.

Similar to the "default values" issue above, the solutions require using a secondary property or getter or some other mechanism.

Memoization is not well supported

Strong memoization patterns are needed in order to avoid duplicate computation and duplicate rendering.

lit-html has guard which memoizes based on a depends array. It wraps the value in a function, which is a little weird for functions. React has a separate useCallback for functions and useMemo for non-functions.

guard([ ... ], () => () => {
    ...

React hooks have memoization strongly ingrained into them, with well-established lint rules (eslint-plugin-hooks) to catch mistakes. It's really easy to forget to maintain the contents of the depends array when you change the variables used in the memoized function. Lit-html's guard directive currently doesn't have any eslint rules to check this, which will certainly bite everyone continually.

"Property is not definitely assigned in the constructor" — classes just aren't meant for this

Using class properties as inputs doesn't mesh well with typescript.

From working with legacy angularjs components, I'm used to seeing this error and either "taping over the warning light" by asserting non-null (!), or suffering through always guarding a possibly-undefined value that I'm never really sure about.

This is a consequence of using class properties as inputs. Normally, class inputs come from constructor parameters, but with LitElement, the inputs are properties. In React, input comes from constructor params (for class components) or function params (for function components), so it does not suffer from this issue.

No way to enforce required properties

lit-analyzer does not support enforcing required properties (runem/lit-analyzer!74), so a user can leave off any & all properties.

This forces all properties to be defined as optional, which complicates the code. Alternatively, using non-null assertions is risky (and arguably wrong in this case) and erodes confidence in the types.

React via JSX does type-check all props properly, including enforcing required properties.

No support for generics

In typescript, generics establish relationships between two values, whether that's two function parameters, or two properties of an object. In components, there are opportunities where we want to add these constraints to the component props. Such as a selector that accepts a set of objects, and a callback that receives the user-selected object. The callback must be a function whose parameter type matches the union of all object types. Generics allow you to write these types without hardcoding this type into the component.

Generics are also needed for type inference. Without generics, we miss out on some of the best parts of typescript. This limits what types we can express on our component interfaces.

See runem/lit-analyzer#149

Teardown is more cumbersome

Event listeners added on connectedCallback must be removed on disconnectedCallback. Below is a more complicated (but real) example from a "menu trigger" component. Compare the LitElement version to the React Hooks version:

LitElement

@customElement('menu-trigger')
export class MenuTrigger extends LitElement {
    @property({type: String})
    trigger?: string;

    private eventHandler?: () => void;

    connectedCallback () {
        super.connectedCallback();
        if (!this.isConnected) return;
        this.registerHandler();
    }

    disconnectedCallback () {
        super.disconnectedCallback();
        this.deregisterHandler();
    }

    shouldUpdate (changedProperties: PropertyValues<MenuTrigger>) {
        if (changedProperties.has('trigger')) {
            this.deregisterHandler();
            this.registerHandler();
        }
    }

    render () {
        return html`<div></div>`;
    }

    private registerHandler () {
        this.eventHandler = () => {
            ...
        };
        this.addEventListener(this.trigger, this.eventHandler);
    }
    private deregisterHandler () {
        this.removeEventListener(this.trigger, this.eventHandler);
    }
}

Every single line of code here is required. I have simplified this as much as possible.

React

function MenuTrigger ({trigger}: {trigger: string}) {
    const eventHandler = useCallback(() => {
        ...
    }, []);

    const [el, setEl] = useState<HTMLElement>(null);

    useEffect(() => {
        if (!el) return;
        el.addEventListener(trigger, eventHandler);
        return () => el.removeEventListener(trigger, eventHandler);
    }, [el, trigger, eventHandler]);

    return <div ref={setEl} />
}

It's amazing how much cleaner the React version is.

In this example, beyond registering a listener and deregistering it on teardown, we also needed to handle the trigger event string itself changing. While some might say "just don't support that", this example serves to illustrate a common development task: dealing with cascading changes — values based on other values, and state based on values, and multiple levels of this.

The hooks pattern is more linear than the class-based pattern. The execution always goes top-to-bottom. In contrast, the class has three possible starting points: connectedCallback, shouldUpdate, and disconnectedCallback.

The hooks pattern takes advantage of closures for retaining the identity of callback functions. In the class-based paradigm, you must store the reference, since it must be bound with Function.prototype.bind, or as in my example: an anonymous arrow function.

React Hooks is better because it's more concise without sacrificing meaning, and easy to follow. The class-based example is full of noise and hard to follow.

I concede that React's memoization patterns can be hard to wrap one's mind around, and the "what invalidated my memoized value?" question can be hard to debug. But I also wonder if that's just the nature of asynchronous programming and stateful systems?

I personally would greatly prefer to write code with hooks instead of any class-based scheme.

Tied to the DOM

Web components do require an Element in order to exist. There are ways of sharing template fragments, but that has its limits. Adding extra HTML elements can conflict with CSS selectors and break existing styles, so this adds burden to migration.

In the React world, components don't even have to have DOM presence. At its core, React is a state management library. DOM is just a render target. This is why React can be used to write native apps and other things. Allowing components to represent things, not just DOM elements, allows for more expressive APIs.

styleMap issues

Rejects undefined values

This is an issue with the type. Can't pass undefined as a value, even though it's equivalent to not passing an entry at all. We should be able to pass nullable values.

    style=${styleMap({
        top: top === undefined ? undefined : `${top}px`,
//      ^^^^
//      Type 'string | undefined' is not assignable to type 'string'.
//        Type 'undefined' is not assignable to type 'string'.ts(2322)


        right: right === undefined ? undefined : `${right}px`,
        bottom: bottom === undefined ? undefined : `${bottom}px`,
        left: left === undefined ? undefined : `${left}px`,
    })}

Because of this, you have to @ts-ignore or conditionally assemble the object (ew)

const style: Record<string, string> = {};
if (top) style.top = `${top}px`;
if (right) style.right = `${right}px`;
if (bottom) style.bottom = `${bottom}px`;
if (left) style.left = `${left}px`;

You can't use Partial<CSSStyleDeclaration> because that has optionality.

Requires all strings

In React, numbers are interpreted as pixel values, which is nice for convenience. styleMap doesn't do this, so the resulting expressions can get awkward:

LitElement

style=${styleMap({
    top: top === undefined ? undefined : `${top}px`,
    right: right === undefined ? undefined : `${right}px`,
    bottom: bottom === undefined ? undefined : `${bottom}px`,
    left: left === undefined ? undefined : `${left}px`,
})}

React

style={{
    top,
    right,
    bottom,
    left,
}}

That's it for now.

Note: This page is mostly data, and mostly objective comparisons. Though I called some things "better" than others, I didn't express how much better, or whether the tradeoffs are worth it, etc. Thanks for reading. If you haven't already, please leave a comment!