Ben Bachem

Connected and presentational components

Thu, 10 Sep 2026 06:40:00 GMT

I’ve been meaning to write about this for ages. I believe for most applications splitting your React codebase into “Connected” and presentational components is most likely the single best architectural choice you can make. At Superchat we followed the pattern religiously. Now that I’m at Langfuse, code is not organized this way and it has made me a little uncomfortable with the codebase. I think it’s almost as strong as the feeling I remember having after using TypeScript for a while and then going back to an untyped JavaScript codebase, so I thought it was finally time to sit down and write about it.

The Pattern

What do I mean by “Connected” and presentational components? Quite simply, a connected component is allowed to interact with your API while a presentational component isn’t. If you think about components as functions, which they essentially are, this pattern means splitting your functions into pure functions and functions with side-effects. Well, not perfectly pure functions, since you’re not banning all side-effects, only API calls.

You might have read about this pattern before. Dan Abramov wrote about presentational and container components over a decade ago. What I’m arguing for here is really a subset of what he calls “Pure and Impure” components in his post, narrowed down to a single kind of impurity I care about: calling your API. Dan has since walked the broader pattern back, but I still believe this subset is one of the most useful ways of organizing a React codebase.

To actually differentiate them, I like to simply prefix component names with “Connected”, and enforce via ESLint that components without the prefix can’t make API calls, more on that later. At its core, it’s similar to function coloring¹, from the name alone, you know whether a component makes API calls or not. An example component directory in a project of mine might look like the following:

src/components/UserCard/ConnectedUserCard.tsx
src/components/UserCard/UserCard.tsx
src/components/UserCard/UserCard.stories.tsx

With the ConnectedUserCard being as simple as this:

import React from "react";
import UserCard from "./UserCard";
import { useUser } from "@repo/react-api-client";

type UserCardProps = React.ComponentProps<typeof UserCard>;

type ConnectedUserCardProps = Omit<UserCardProps, "user"> & {
  user: { id: string };
};

function ConnectedUserCard(props: ConnectedUserCardProps) {
  const userQuery = useUser(props.user.id);

  if (!userQuery.data) {
    return <UserCard isLoading />;
  }

  const user = userQuery.data;

  return (
    <UserCard
      username={user.username}
      bio={user.bio}
      location={user.location}
    />
  );
}

Predictability

Now looking at the example above, you might be wondering why I’d bother introducing this split. Why do I voluntarily add this additional boilerplate of a wrapping component over mixing the API with the presentation? What do I actually gain from lifting one API calling hook from the UserCard into the ConnectedUserCard wrapper? Let’s look at the benefits.

Let’s take the user card component from above and assume we don’t have a formalized split between connected and presentational components. Is the following a good idea?

{
  [alice, bob, simon, john].map((user) => (
    <UserCard key={user.id} user={user} />
  ));
}

I’d say if you are unsure whether the component does API requests, probably not. Let’s say the component fetches some metadata of the user and then renders the user’s name and a bio. This means the code above might now fire four API calls.² Now imagine dropping it into a table with hundreds of rows, oblivious to its network behavior. If, instead, I know the component is not doing an API call just by looking at its name, I can compose it any way I want as long as I am able to satisfy the prop types. This makes my component very predictable and thus leads to increased reusability.

Testing Without a Network

The next major benefit I see is that testing components that do network requests in isolation is a pain. Most likely it means setting up network mocks or spinning up a server that serves the real API. Maybe it also means you’re not going to bother with testing the component in isolation at all, instead you’re simply going to pop it in its slot in the real page.tsx, run the dev server, log in, and click around. I hope you’d at least do that. But let’s face it, the feedback loop of clicking around in the real application is slow. Maybe it’s not even possible to get to a component you want to test because it’s buried in step five of the billing form that only appears when upgrading from an IP address detected to be in Japan. Now what? Are you going to rewrite the outer conditions just to be able to see the component once? What if you forget to put the right conditions back after testing? Maybe instead you could click through the flow using a proxy routed through Japan? Or change some rows in the database to place the system in the desired state?

With a component that renders data received via props, I don’t need to do any of that. I just open it up in Storybook or place it on a temporary page and make sure to satisfy its prop types with a fixture. Compared to clicking around in the real application, this is easier, faster, and has the ability of being reliable when used in automated tests. That means people will actually do it. Not only that but coding agents will also have an easier time, as is often the case with tooling³.

Admittedly, the approach above wouldn’t test the data fetching itself; you’d verify that separately. But being able to test most of your UI without a network is powerful. If you have a well-defined API and know the types of your responses, you can basically build out most of the UI of a newly planned feature simply by passing fixtures as props and then wiring up the components at the end through a shallow layer of connected components that contain simple API fetching hooks. In the end, all of this leads to increased reliability as UI is actually looked at and tests are actually written.

Preview Deployments

As I mentioned above, my tool of choice for developing components in isolation is Storybook. It has the added benefit of being very simple and cost-effective to set up preview deployments as it can be compiled to static HTML, CSS, and JS which you can very cheaply serve. At Langfuse, we just push it to Vercel, and at Superchat, we uploaded it to S3 and pointed a CloudFront distribution at it. If I had to place preview deployment approaches in a quadrant of cost vs. usefulness, I think Storybook would generally come out as a no-brainer.

Here’s my rundown of alternatives:

Full application preview
By this I mean full preview environments that include a real backend and database. This is very powerful as in theory it allows you to test any kind of change, but is complicated to set up and can be expensive. It’s what we are currently doing at Langfuse.

Client-only previews
By this I mean deploying the client-only, pointing it to a single staging or preview environment API. It’s much easier to do and generally cheaper since you don’t need separate API server and database instances, but you lose the ability to make changes that span both client and API in the same PR. This is what we used to do at Superchat.

Frontend with mocked backend
You can do this with tools such as Mock Service Worker. I have not done this myself as I always had both Storybook with the pattern described in this post and some sort of preview environment with a real API available, but I’ve read about Oxide doing this well for their console. This can be done as a Storybook-only deployment that feels interactive, but you cannot test features end-to-end as the server is fake.

Storybook-only previews
By this I mean, no API at all, just components with fixtures as props living in Storybook. I’d argue this is easiest and cheapest. Downside being it’s less interactive, you cannot test auth or API interactions etc. Especially with smaller changes that touch existing UI, a Storybook-only preview might be enough to verify a change is safe to merge.

This is also not necessarily an either/or question. Both now at Langfuse and previously at Superchat, we simply do both, having Storybook previews in addition to a way of testing the application in a more end-to-end manner.

Now the usefulness of Storybook scales with the amount of code it can cover and this is what the principle described here really gets to, sticking to it increases the share of the code that is easy to cover. I’d estimate at Superchat around 70% of the frontend code was not reliant on the API and could be tested in isolation, we could have probably pushed that to above 90% but sometimes took the slightly lazy route of prefixing a component with “Connected” and not bothering to split it up. This is another thing I like about this practice, it does not get in your way and there’s an out for when you have to deliver fast.

Loading States

The last advantage I wanted to highlight is that following the pattern gives you a natural boundary for loading states. Every connected component can return a skeleton version of the wrapped component. Because the presentational component is right there and driven purely by props, rendering a placeholder that mirrors its shape is easy, so more often than not the default loading state ends up being a skeleton rather than a spinner. The skeleton tells the user roughly what’s coming and often can already match the final shape and dimensions so the page doesn’t jump around when the data arrives. Spinners are a lazy default, and connected components make this obvious.

Enforcing the Pattern

Now you might have read up to here and thought to yourself: “This sounds all nice in theory but I could never teach my team to stick to this in practice.” Don’t worry, I don’t think coming up with principles like this without an automated way of enforcing them is any good either. To be honest, in the five years I was leading our frontend development at Superchat, I probably would have introduced my fair share of rule violations without being reminded of it and that was before the age of 10k LOC PRs from coding agents. Here’s how we enforced the pattern:

We used ESLint with eslint-plugin-boundaries which is a plugin meant to enforce architectural boundaries in your projects. It allows you to divide files into what it calls “elements” and then enforce the relationship of said elements. In the case of Superchat, we split components according to their filepath into connected and presentational components, then disallowed imports of our api-client in presentational components. We also disallowed importing the api-client from hooks. We then configured the boundaries plugin to disallow importing components whose names started with “Connected” in a component whose name didn’t, effectively enforcing our way of function coloring.

To make this work, we exclusively used TanStack Query to make API calls. All the querying and mutation logic was abstracted into an internal @superchat/api-client package within our monorepo. This meant there was a single entry point that we could check for.

Here’s a sample ESLint configuration on how this could be done:

import boundaries from "eslint-plugin-boundaries";

export default [
  {
    plugins: { boundaries },
    settings: {
      // Only look at boundary types within `src`
      "boundaries/include": ["src/**/*.{js,jsx,ts,tsx}"],

      // Define the "elements" boundaries knows about.
      "boundaries/elements": [
        {
          type: "hooks",
          mode: "file",
          pattern: "src/hooks/*.{js,ts}",
        },
        {
          type: "connected-components",
          mode: "file",
          pattern: "src/components/**/Connected*.{jsx,tsx}",
        },
        {
          type: "presentational-components",
          mode: "file",
          pattern: "src/components/**/*.{jsx,tsx}",
        },
      ],
    },
    rules: {
      // Keep the API client out of presentational components and out of hooks.
      "boundaries/external": [
        "error",
        {
          default: "allow",
          rules: [
            {
              from: ["presentational-components", "hooks"],
              disallow: ["@repo/react-api-client"],
              message:
                "Do not import @repo/react-api-client here. Only connected components may talk to the API client directly.",
            },
          ],
        },
      ],

      // Enforce the "function coloring" convention
      "boundaries/element-types": [
        "error",
        {
          default: "allow",
          rules: [
            {
              from: ["presentational-components"],
              disallow: ["connected-components"],
              message:
                "Presentational components cannot import connected components. Pass data down as props instead.",
            },
          ],
        },
      ],
    },
  },
];

The one downside we saw was that we could not abstract complicated API logic into hooks, but we got around it by either doing the data fetching first and then passing the data to hooks, or using components with render props such as a <UserPreferenceProvider>{(user) => ...}</UserPreferenceProvider> over a useUserPreference(). We thought about introducing the connected / non-connected split also to hooks but never had a compelling enough argument to justify the additional complexity.

Coming back to Dan’s original post from earlier, there are two places where I explicitly disagree with him. The first is his later update claiming the split is an implementation detail, that you should be able to replace a presentational component with a container without touching any call sites. I think that’s exactly backwards: in our case the value of the split lives at the call site, you can tell from the component’s name whether it will do network requests. Make it an implementation detail and you lose that. It’s also why I don’t follow his relaxed take on nesting, in my version a presentational component is never allowed to contain a connected one. The second is his view on logic: he originally argued to keep as much of it out of the presentational components, I’d argue the opposite, pack as much logic as you want into presentational components, all of it can then be easily tested in Storybook, just don’t put any API calls in.

Adopting the Pattern

If I were to go about adopting this in a greenfield project, I would actually be stricter than the version described so far. At Superchat, non-connected components were still allowed to access context, access session- or local storage or interact with the URL state, although the latter was discouraged and often discussed in code reviews. If I were starting from scratch I would consider restricting some of these too. Regarding URL state, for example, I’ve come to believe that components should ideally never read or modify URL state and the access should always be lifted to the framework boundary, e.g. a page. But I’ll make that argument another time.

If you are not building a new application but are thinking about adopting this in your existing app, depending on the amount of existing code, this could be difficult. Normally, when adopting eslint rules you can grandfather existing violations by adding disable comments to them or using bulk suppressions but in this case this would not be a good idea, as it would not improve the predictability of the component. You still couldn’t tell if it was doing an API request from looking at the component name alone. If you want to adopt this pattern in an existing app, I’d probably do one of the following:

Adopt it for a newly built domain and scope the ESLint configuration to its folder.
The downside here is that you’re not really getting the predictability of components or would at least always need to check where a component is imported from.

Reverse it and use a file extension prefix.
Instead of marking connected components, mark presentational ones and instead of using the component name, you could use their filepath, e.g. UserCard.presentational.tsx. Then you could set up ESLint to enforce that presentational components cannot do API calls. This way you should be able to adopt this for newly written code only and keep the existing code you have untouched. Then over time, you could go through the application renaming files that already uphold the guarantees of presentational components and refactoring components that should but aren’t. The downside here is that you cannot tell from the component name alone, which reduces the amount of information you get when reading JSX as you’d always need to cross-reference it with the import section at the top of the file. I’d not use the component’s name for conveying the restrictions because this would lead to very ugly component names. Ideally you want most of your application’s components to be pure, say ~90%. When prefixing the 10%, this feels natural - a Button keeps its name, same with a UserCard. When you’re not prefixing the 10% connected components but the 90%, you’d also have to prefix components that obviously were not doing any network requests in the first place. Your Button would become PresentationalButton, your Input would become PresentationalInput, etc.

Just rename every component and prefix it with “Connected”.
Over time, you could then remove the prefix from components that don’t need it. This would be a huge single change in git and I would not enjoy merging this beast of a PR, causing conflicts for everyone but if you’re a solo developer, this might be the most pragmatic way to adopt this if actually cleaning up the code according to the original rule is too much work for a single PR.

Where the Pattern Breaks Down

I’ll close this post by looking at types of applications where I think this pattern might be difficult to apply. At Superchat we struggled with it when we started building our Automations feature, which is similar to Zapier or n8n. In Automations, we had a lot of complicated logic for rendering nodes in an interactive canvas and the API calls would generally only happen quite far down in the component tree. This meant that following the principle laid out here, most of the components had to be prefixed with “Connected” since using a connected component as a child of a non-connected component is not allowed. You could get around this a bit by using render functions in props but it can get unwieldy quickly and the effort of working around the pattern might outweigh the benefits. Generally, if you’d need most of the components in your application to be connected, the pattern might not be worth it. But let’s face it, many of us are not building these kinds of applications but rather traditional SaaS where most of the application is a collection of forms and tables. Even if you are building an application akin to Figma or Zapier, you might still have large parts of your application where this could be applied (think about all the settings pages). The nice thing about the pattern is that if splitting the components is too difficult, just prefix all of them with “Connected” and be done with it, you can always come back later and split components once you want to reuse them somewhere else.

I have used the term function coloring for a while, but never really knew where it originated from. While writing this post, I went looking for a suitable reference and What Color is Your Function? came up as the source that apparently coined the term. The concept as I know it is about async functions and is generally considered a design flaw. I’m borrowing the term and applying it to components: a component’s color is determined by whether it makes network calls, and, like async’s color, decides where the component can be used. Instead of a flaw, I see the color as a feature and embrace the coloring rather than trying to design it away. ↩
I’m aware that if you are using GraphQL, queries might be merged and batched. ↩
If you’re interested, Steve Klabnik argued for a similar point in The most important thing when working with LLMs. ↩

Switching from Backblaze to resticprofile

Sat, 30 May 2026 16:00:00 GMT

I have three Mac computers: one work laptop, one personal laptop, and one Mac mini that runs my homelab. The Mac mini has a 4-bay Terramaster D4-320 attached to it with some external storage and a large hard drive used for backing up the Mac and the external drives locally through Time Machine. I do not back up any data from the work or personal laptops as they don’t store anything that I couldn’t lose. All my code lives on GitHub and my personal repositories are being mirrored to my homelab. I have my photos and notes in iCloud, mirrored as well, and additional files such as an archive of RAW photos from my camera or old backups from my phones simply live on external drives connected to my Mac mini. So effectively, anything that is important to me is stored on the Mac mini.

For the past few years, I was using Backblaze Personal Backup as an offsite backup. After recently reading that Backblaze stopped backing up the iCloud folder on macOS¹, I decided to take the time to switch to resticprofile backing up to a Hetzner Storage Box.

While the Backblaze Personal Backup price at $99 / year or $123 / year with 1-year version retention is very hard to beat, a Hetzner Storage Box is €156 / year for 5TB or €46 / year for 1TB if you have less data. For me, the slight increase in price was worth the additional control.

I think it is worth noting, though, that unlike a cloud storage host like Dropbox or iCloud, or object storage like S3, data on a Hetzner Storage Box is not mirrored onto multiple servers. This means there is a higher chance of data loss. I would probably not advise using it to store a singular copy of critical data. Since I have two local copies of my data in addition to the data on the storage box, I think this is a very acceptable risk considering the cost savings over B2, S3, or Wasabi.

Switching turned out to be easier than I expected and I’m genuinely happy with the outcome. I wanted to take the time to document the process so I have a resource that might help others in a similar position and to direct people to when talking about my own setup.

The general setup of buying the Hetzner Storage Box and setting up resticprofile was very straightforward and something I’m going to skip over.

I am using 1Password and am a big fan of their SSH Agent, so I initially tried using that but noticed I couldn’t run restic unattended since the 1Password vault would need to be unlocked. Instead, I settled on just storing the SSH key and restic password on the filesystem.

After setting everything up, my first complete restic run took a while. I didn’t have a comprehensive exclusions list in the first run, so restic was backing up a lot of irrelevant directories, of which many contained tiny files. Fortunately, restic handled interruptions well. I canceled it several times to tweak the config (the SSH connection also dropped on me a couple of times), and it always picked up right where it left of. One tweak I discovered was increasing the restic_read_concurrency to 5, which seems to be configured by default to a value of only 2, you can probably push it even further.

After the initial snapshot succeeded, I listed all the included files using resticprofile ls latest and checked the list, updating my exclusions config. I then reran restic with only a few hours between runs a handful of times, comparing snapshots to further tweak my exclusion list. You can find my full config at the bottom of this post. Since it might be useful, a list of all snapshots can be shown by running resticprofile snapshots, and two snapshots can be compared using resticprofile diff [snapshot_id] [snapshot_id].

Now, after the initial setup, daily runs tend to back up only a few hundred megabytes and typically complete within less than five minutes, while the load on the computer is almost unnoticeable.

The final thing I did was set up a Grafana dashboard to monitor everything. I had Grafana already set up anyway; otherwise, I would have likely skipped this.

The entire process was pretty straightforward, and there are a few things I really like. The first being that running this setup makes me feel that I am in full control. Second, having the all the configuration be text-based instead of hidden in some GUI is great as I can check it into git. I had previously looked into setting up additional exclusions for Backblaze a few times but always put it off due to it being a little more complicated to configure. Lastly, also like that restic is encrypted by default. I saw that for a long time it was not even possible to run it without a password, and even now it’s a little annoying, nudging people into secure defaults. Filippo Valsorda, who has done cryptography work at Google and Cloudflare, published a detailed analysis of restic’s cryptographic design in 2017 and came away satisfied. That’s a meaningful endorsement, with the caveat of the post being almost ten years old.

With everything said, there are a few small things that I think could be better. The Hetzner Storage Box web interface is very limited. It doesn’t even include a file browser; in order to see the contents, I need to connect via SSH or using an FTP client. This is not a big issue for me, since I only use the storage box for restic at the moment and I interact with it through the CLI anyway, but might be good to know.

Another very minor annoyance I had was that while there is a hosted manual for restic, the resticprofile docs only contain information about the existence of a help command without actually including its full output. ²

For reference, here’s my final setup script:

# Install resticprofile
brew install restic
brew tap creativeprojects/tap
brew install resticprofile

# Symlink resticprofile config
ln -sfn "$SCRIPT_DIR/../resticprofile" ~/.config/resticprofile

# Create restic credential file
op read "op://Personal/Restic Password/password" > "$SCRIPT_DIR/../resticprofile/credentials"

# Save restic SSH key to avoid 1password prompts
op read -f --out-file ~/.ssh/restic-key.pub "op://Personal/Hetzner Storage Box SSH Key/public key"
op read -f --out-file ~/.ssh/restic-key.pem "op://Personal/Hetzner Storage Box SSH Key/private key?ssh-format=openssh"

# Associate key with host
PATTERN="*.your-storagebox.de"
KEY="~/.ssh/restic-key.pem"
if ! grep -q "^Match host[[:space:]]\+.$PATTERN" ~/.ssh/config; then
  cat > /tmp/ssh-match.tmp << EOF
Host $PATTERN
  IdentityFile $KEY
  IdentitiesOnly yes
  IdentityAgent none

EOF
  cat /tmp/ssh-match.tmp ~/.ssh/config > /tmp/ssh-config.new && mv /tmp/ssh-config.new ~/.ssh/config && rm /tmp/ssh-match.tmp ~/.ssh/config.new
  echo "Added Match block at top."
fi

# Setup resticprofile schedule
# Schedule can be manually triggered via "/bin/launchctl start local.resticprofile.default.backup"
resticprofile schedule --all

and here’s resticprofile configuration, with a few minor edits to allow publishing it online:

#:schema https://creativeprojects.github.io/resticprofile/jsonschema/config-1.json

version = "1"

[global]
prevent-sleep = true

[default]
verbose = true
exclude-caches = true
priority = "background"
repository = ""
password-file = "${HOME}/.config/resticprofile/credentials"
prometheus-push = "http://localhost:9091/"
prometheus-push-job = "resticprofile-backup"

[default.backup]
source = ["${HOME}", "/Library", "/Volumes/Disk 2"]
compression = "max"
read-concurrency = 5
exclude = [
  # Temporary & cache files
  "*.tmp",
  "*.temp",
  "*.swp",
  "*.bzvol",
  "*.DS_Store",
  ".Trash",
  ".Trashes",
  ".TemporaryItems",
  ".Spotlight-V100",
  ".DocumentRevisions-V100",
  "**/tmp/",

  # MacOS default folders
  "/Applications",
  "${HOME}/Downloads",
  "${HOME}/.Trash",
  "${HOME}/Library/Caches/",
  "${HOME}/Library/Developer/",
  "${HOME}/Library/Updates/",
  "${HOME}/Library/Metadata/",
  "${HOME}/Library/AppleMediaServices",
  "${HOME}/Library/Application Support/com.apple.wallpaper",
  "${HOME}/Library/Application Support/FileProvider",
  "${HOME}/Library/Application Support/Animoji",
  "${HOME}/Library/Application Support/CloudDocs",
  "${HOME}/Library/Application Support/Knowledge",
  "${HOME}/Library/Application Support/com.apple.ProtectedCloudStorage",
  "${HOME}/Library/Application Support/com.apple.sharedfilelist",
  "${HOME}/Library/Accessibility/com.apple.personalaudio.sqlite-wal",
  "${HOME}/Library/Assistant",
  "${HOME}/Library/Daemon Containers",
  "${HOME}/Library/Group Containers",
  "${HOME}/Library/Containers",
  "${HOME}/Library/HTTPStorages",
  "${HOME}/Library/HomeKit",
  "${HOME}/Library/IdentityServices",
  "${HOME}/Library/IntelligencePlatform",
  "${HOME}/Library/LanguageModeling",
  "${HOME}/Library/MediaAnalysis",
  "${HOME}/Library/Safari",
  "${HOME}/Library/Spelling",
  "${HOME}/Library/Suggestions",
  "${HOME}/Library/Trial",
  "${HOME}/Library/WebKit",
  "${HOME}/Library/com.apple.AppleMediaServices",
  "${HOME}/Library/com.apple.bluetooth.services.cloud",
  "${HOME}/Library/com.apple.bluetoothuser",
  "${HOME}/Movies/TV/TV Library.tvlibrary",
  "${HOME}/Music/Music/Music Library.musiclibrary",
  "${HOME}/Pictures/Photos Library.photoslibrary/private/com.apple.mediaanalysisd/caches",
  "${HOME}/Pictures/Photos Library.photoslibrary/resources/caches",
  "/Library/Apple",
  "/Library/Bluetooth",
  "/Library/Caches",
  "/Library/Documentation",
  "/Library/Image Capture",
  "/Library/Trial",
  "/Library/User Template",
  "/Library/Keychains",
  "/Library/LaunchDaemons",
  "/Library/Application Support/Apple",
  "/Library/Application Support/BTServer",
  "/Library/Application Support/ApplePushService",
  "/Library/Developer/CommandLineTools",
  "/Library/Developer/CoreSimulator",
  "/Library/Developer/PrivateFrameworks",
  "/Library/Application Support/com.apple.idleassetsd",
  "/Library/Application Support/iLifeMediaBrowser",
  "/Library/WebServer/share/httpd",
  "/Library/Preferences/SystemConfiguration",
  "/Library/Preferences/OpenDirectory",
  "/Library/Preferences/com.apple.apsd.plist",
  "/Library/Preferences/com.apple.wifi.known-networks.plist",

  # User level dotfiles
  "${HOME}/.*",

  # Application specific folders
  # ... excluded from the example

  # Build artifacts
  "node_modules",
  ".pnpm-store",
  "__pycache__",
  "*.pyc",
  "*.pyo",
  ".venv",
  "venv",
  ".tox",
  ".nox",
  ".rustup/toolchains",
  ".cargo/registry",
  ".cargo/git",
  ".gradle",
  "target",
  "dist",
  "build",

  # Large media / disk images
  "*.iso",
  "*.img",
  "*.hdd",
  "*.qcow2",
  "*.vmdk",
  "*.vdi",
  "*.bzpkg",
]

# Schedule can be manually triggered via "/bin/launchctl start local.resticprofile.default.backup"
schedule = "*-*-* 10:00:00"
schedule-permission = "user"
schedule-priority = "background"
schedule-log = '${HOME}/.logs/resticprofile/logs/backup-{{ .Now.Format "2006-01-02T15-04-05" }}.log'
schedule-lock-mode = "default"
schedule-lock-wait = "15m00s"

[default.retention]
keep-last = 5
keep-daily = 5
keep-weekly = 4
keep-monthly = 6
keep-yearly = 2
prune = true
after-backup = true

[default.check]
read-data-subset = "5%"
# Once a week on monday at 12:00
schedule = "Mon *-*-* 12:00:00"
schedule-permission = "user"
schedule-priority = "background"
schedule-log = '${HOME}/.logs/resticprofile/logs/check-{{ .Now.Format "2006-01-02T15-04-05" }}.log'
schedule-lock-mode = "default"
schedule-lock-wait = "15m00s"

Don't pass className to your components

Mon, 06 Apr 2026 11:22:00 GMT

I believe that not passing className or style props to components is an important principle for building scalable React applications. This post explains why, and what to do instead.

It should be clear that what is written here does not apply to headless components.

The most apparent issue that can arise from passing these props is conflicting classes or properties.

const Button = ({
  children,
  className,
  onClick,
}: {
  children: React.ReactNode;
  className: string;
  onClick: () => void;
}) => {
  return (
    <button
      onClick={onClick}
      className={`bg-primary font-semibold text-center ${className}`}
    >
      {children}
    </button>
  );
};

<div>
  <Button className="bg-green-500">Buy Now</Button>
</div>;

The button in this example will end up having the className bg-primary font-semibold text-center bg-green-500 in the DOM. What background color will the button in the above code sample take on?

The answer depends on the order the classes appear in the compiled CSS, not the order they appear in the className string. This is almost certainly not what you intended, and not something you can reason about reliably at a glance.

Libraries like tailwind-merge exist precisely to address this problem, but needing a workaround is a signal that the underlying design has a flaw.

Now, assuming you run into the above issue, how do you know how many conflicting classes you have across the rest of the codebase? How about the question: “Which background colors can our button component currently use?” - would you be able to answer that?

This brings me to my next point: allowing a className or style prop to be passed makes it impossible to understand all states of a component without looking at every place it is used. Explicit props and TypeScript discriminated unions or enums make the full surface area of a component obvious at a glance.

type ButtonProps = React.ComponentProps<{
  variant: "primary" | "secondary";
  size: "small" | "medium" | "large";
  onClick: () => void;
}>;

Looking at this type definition alone, you know the button has two variants, three sizes, and does exactly one thing on interaction. Compare that to a className prop, which tells you nothing: any string is valid, and the only way to know what strings are actually in use is to search every usage of the component.

The problem goes deeper than legibility, though. Programmatically reacting to the className prop is infeasible too. This is the last issue I want to highlight.

Say you have a <SearchBar> component that shows match counts when navigating through search results in a long document. When enough space is available, you want to show “2 / 18 occurrences”. When space is tight, you want to shorten it to “2 / 18”.

<SearchBar
  query={query}
  onChange={setQuery}
  position={position}
  total={total}
  onMove={handleMove}
  className="max-w-96"
/>

How should the component react to the max-w-96 class being passed? To the component, max-w-96 is just a string. Trying to parse it and then calculate what pixel size it might correspond to sounds far too complex a solution for such a simple problem.

It would be easier to simply have a size prop and set the max width inside the component.

const SearchBar = ({
  query,
  onChange,
  position,
  total,
  onMove,
  size,
}: SearchBarProps) => {
  return (
    <div className={size === "large" ? "max-w-96" : "max-w-48"}>
      <input value={query} onChange={(e) => onChange(e.target.value)} />
      <span>
        {position} / {size === "large" ? `${total} occurrences` : total}
      </span>
      <button onClick={() => onMove(-1)}>Previous</button>
      <button onClick={() => onMove(1)}>Next</button>
    </div>
  );
};

<SearchBar
  query={query}
  onChange={setQuery}
  position={position}
  total={total}
  onMove={handleMove}
/>;

Yes, CSS container queries can also solve the responsive part of this. But they are not ideal when the component needs to change its content based on available space, and they hide from the call site the fact that there is a meaningful difference between a “small” and a “large” search bar.

I hope these three examples illustrate my reason for this principle. So, what should you do instead of passing style or className props?

Alternatives

The alternatives I would reach for are the following:

Explicit variants. Model the visual states of your component as named props, as shown in the Button and SearchBar examples above.
Full-width components with external constraints. Make the component fill all available space, then control that space from the outside. Tools for constraining could be a wrapper div with a max-width, a grid column, or a flex container. The component doesn’t need to know anything about its layout context; the parent handles that.

In all the years I’ve spent building React-based applications, these two alternatives have pretty much always worked for me. To be honest, I cannot recall a single non-headless component where I had to resort to passing a className or style prop instead.

If this principle feels familiar, it should. At its core, it addresses the same problem that CSS Modules and scoped styles solve: preventing unintended style bleed by eliminating the global, cascading nature of CSS¹. Passing className into a component reintroduces that problem, just one layer up and through props instead of selectors.

“The End of Global CSS” by Mark Dalgleish ↩

Prefer explicit discriminators over "x" in y in TypeScript

Sat, 14 Feb 2026 11:07:00 GMT

In TypeScript, using the if ("x" in y) syntax alters the definition of y, since the compiler understands it as a guard statement, it will permit all subsequent property accesses of x. In practice this can lead to dead code. Often, a better approach is using explicit discriminator properties instead.

Let me give you an example:

type Strawberry = {
  acidity: number;
};

type Mango = {
  acidity: number;
};

type Fruit = Strawberry | Mango;

function printMetadata(fruit: Fruit) {
  if ("acidity" in fruit) {
    console.log(fruit.acidity);
  }

  if ("sweetness" in fruit) {
    console.log(fruit.sweetness);
  }
}

This code snippet is valid and does not produce any compile-time issues, but according to the definition of the Fruit type, it never has a “sweetness” property, so the if("sweetness" in fruit) condition doesn’t make much sense. TypeScript will not warn about the condition itself and it will also not complain about the subsequent use of the checked-for property. The compiler is doing what it’s told: since you checked for the property, so it assumes it might be there. This might seem logically incorrect but since TypeScript was meant to be incrementally adopted and type definitions used to often be incorrect, especially when many external libraries still used to be written in pure JavaScript with type definitions provided after the fact.

In practice, this means using the "x" in y syntax will often produce undetectable dead code. The most common scenario I’ve personally noticed is using the "x" in y syntax to check for discriminated unions, then later deciding to remove one of the variants, forgetting to remove the condition.

A better approach uses an explicit discriminator:

type Strawberry = {
  type: "strawberry";
  acidity: number;
};

type Mango = {
  type: "mango";
  acidity: number;
};

type Fruit = Strawberry | Mango;

function printMetadata(fruit: Fruit) {
  if (fruit.type === "strawberry" || fruit.type === "mango") {
    console.log(fruit.acidity);
  }
}

Now, it’s impossible to construct an if fruit.type === condition that would allow you to access fruit.sweetness and the compiler will complain anytime you try to.

While the in operator has its place, especially when dealing with truly unknown or untyped data from external sources, it should be avoided when working with well-defined union types. Using an explicit discriminator property in these cases leads to more robust and refactor-friendly code, letting the compiler do its job of catching errors for you.

Getting Wezterm + Zellij to Open Files in VS Code

Sat, 12 Apr 2025 19:00:00 GMT

Edit from 2026-07-01: Zellij v0.44.0 now contains built-in functionality for opening links. I also maintain a fork of the builtin plugin with extended capabilities. I am no longer using the method described below.

For the past year and a half, I’ve been using WezTerm¹ and Zellij² as my terminal and multiplexer of choice. Zellij has some hiccups here and there but the discoverability of shortcuts feels great, making it much easier to pick up than something like tmux in my opinion. Plus, both tools are written in Rust, which is always a bonus!

Over the years, my terminal setup has evolved a bit. I started with iTerm2³, which I liked for its features but found a bit slow when handling rapid screen updates (e.g., scrolling through large files in Nvim). I then switched to Alacritty⁴ for its speed but eventually moved on because it lacked support for ligatures. Now, WezTerm + Zellij feels like the perfect balance for my workflow.

The Missing Link

Despite being happy with my current setup, there was one feature I missed from iTerm2: the ability to open files in VS Code by simply clicking on their paths in the terminal.

VS Code’s integrated terminal does this seamlessly, and it’s very handy when I want to quickly jump to a file mentioned in various contexts, such as:

Failing test reports
Linting warnings
Compilation errors
And more…

Selecting and copying file paths (or worse, typing them out manually) felt like a step backward in productivity. So I set out to get this functionality back in my WezTerm + Zellij setup.

WezTerm supports custom hyperlink_rules⁵, which allow you to define how file paths are handled. However, the default implementation assumes you’re using WezTerm’s built-in tabs and panes so it can determine the current working directory. Unfortunately, this doesn’t work when using Zellij as the multiplexer.

I couldn’t find a way to programmatically get the current working directory from a Zellij pane when clicking on a file path. So, I decided to take a more naive approach: search for the file in my development folder using fd⁶.

Here’s the relevant part from my WezTerm config file:

-- Pull in the wezterm API
local wezterm = require "wezterm"

-- This table will hold the configuration.
local config = {}

local function find_absolute_file_path(relative_path)
    local search_dir = wezterm.home_dir .. "/Documents/Dev"

    local success, stdout, stderr = wezterm.run_child_process {"/opt/homebrew/bin/fd", "-p", relative_path, search_dir}

    if success then
        local first_line = stdout:match("[^\n]+")
        if first_line then
            return first_line
        end
    end

    return false
end

-- Update open uri function to open find:// links in vscode
wezterm.on(
    "open-uri",
    function(window, pane, uri)
        local start, match_end = uri:find("find://")

        if start == 1 then
            local file_path = uri:sub(match_end + 1)
            local line_number = ""
            local column_number = ""

            local position_start = string.find(file_path, ":")
            if position_start ~= nil then
                position = file_path:sub(position_start + 1)
                file_path = file_path:sub(1, position_start - 1)

                local position_end = string.find(position, ":")
                if position_end ~= nil then
                    column_number = position:sub(position_end + 1)
                    line_number = position:sub(1, position_end - 1)
                else
                    line_number = position
                end
            end

            local absolute_file_path = find_absolute_file_path(file_path)

            if absolute_file_path then
                local vscode_url = "vscode://file" .. absolute_file_path
                if line_number ~= "" and column_number ~= "" then
                    vscode_url = vscode_url .. ":" .. line_number .. ":" .. column_number
                elseif line_number ~= "" then
                    vscode_url = vscode_url .. ":" .. line_number
                end

                wezterm.open_with(vscode_url)
                return false
            end

            return true
        end

        return true
    end
)

-- Use the defaults as a base
config.hyperlink_rules = wezterm.default_hyperlink_rules()

table.insert(
    config.hyperlink_rules,
    {
        -- This regex can be tested at https://rustexp.lpil.uk/. Make sure to check `fancy-regex`
        regex = "[/.A-Za-z0-9_-]+\\.[A-Za-z0-9]+(:\\d+)?(:\\d+)?",
        format = "find://$0"
    }
)

-- and finally, return the configuration to wezterm
return config

How It Works

I define a custom URI scheme find:// that gets triggered by my hyperlink rule
When a path is clicked, WezTerm captures it and passes it to my handler
The handler extracts line and column numbers if present
It then uses fd to search for the file in my development directory
If found, it constructs a VS Code URL with the proper format and opens it.

The regex captures file paths that include extensions and optional line/column numbers (e.g., src/main.rs:10:5).

There’s definitely room to improve this approach. The most obvious enhancement would be to narrow the search directory to the current project rather than searching my entire development folder. If anyone has insights on how to get the current working directory from a Zellij pane in WezTerm, I’d love to hear about it!

For those interested in my complete setup, check out my dotfiles: https://github.com/bezbac/dotfiles

Don't use an app for that!

Tue, 23 Apr 2024 06:14:00 GMT

Friends of mine know that I’m somewhat obsessive regarding tracking the media I consume. Over the past nearly ten years, I’ve written down almost every movie I’ve seen, every episode of every TV show I watched, and every book I’ve read, for some periods, even which pages on which dates. I keep track of all of this data in spreadsheets.

I believe the reason I’ve been able to stick to the habit for this long is because it’s easy. If I spend two hours watching a movie, spending 30 seconds to jot down some info in a spreadsheet row feels fine.

Now, I could’ve used a service like Goodreads, librarything, Letterboxd, trakt.tv, serializd. There’s no shortage of apps that aim to do this for you. However, companies get sold or go bankrupt, and open-source projects get abandoned. Sure, most of the time, this is not a big deal; you can export and migrate your data. Sure, it might be in a weird format, and you might need to wrangle it a little to make it fit, but that’s easy, right? Sure, it might be on short notice, and you’ll need to shift your priorities a little, but it’s no biggie, right?

Do you really want to spend time migrating your data? I’m confident I’ll still be able to open my CSV file in 10 years.

When establishing a process, I try to think about the total cost of ownership. You wouldn’t buy the cheapest car when you already know it requires constant repairs. “If you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. […] Apps are ephemeral, but your files have a chance to last.”¹

https://stephango.com/file-over-app ↩

My First Post

Sat, 18 Mar 2023 12:33:00 GMT

After a long time of tweaking this site, I finally sat down to create this first blog post. And, since I’ve wanted to have a blog since forever, I could never really put my finger on “why”, so I thought it might be a good idea to start with that as the topic of my first post.

Like many others, I’ve been captivated by the personal websites of all the talented individuals on the web. There are a lot of personal websites I look at in awe, sometimes I envy them for their seemingly perfect style¹, sometimes for the creativity behind the presentation² or, of course, for their content³. To me, these websites represent the best of the internet - a space for people to express themselves and share their interests.

Growing up in a world where the internet was already abundant, I’ve always been drawn to the stories of creators, innovators, and entrepreneurs. I wanted to be part of that world, and now with me working in a startup feel closer to that goal than ever. But there was one thing missing – my little corner of the web.

This blog should be my digital business card - my digital introduction - a place where I can proudly direct people when they ask about my work, my passions, and who I am as a person.

Plus, I just really like building websites.

Ben Bachem

Connected and presentational components

The Pattern

Predictability

Testing Without a Network

Preview Deployments

Loading States

Enforcing the Pattern

Adopting the Pattern

Where the Pattern Breaks Down

Footnotes

Switching from Backblaze to resticprofile

Footnotes

Don't pass className to your components

Alternatives

Footnotes

Prefer explicit discriminators over "x" in y in TypeScript

Getting Wezterm + Zellij to Open Files in VS Code

The Missing Link

How It Works

Footnotes

Don't use an app for that!

Footnotes

My First Post

Footnotes