DEV Community: Joshua Amaju

Explicit Resource Management Has a Color Problem

Joshua Amaju — Mon, 16 Feb 2026 09:07:22 +0000

This is a condensed version of the full article.

The complete breakdown, including a refactor of the MDN using example and a comparison with structured lifetimes in Effection, is available here:

https://www.joshuaamaju.com/blog/the-pitfalls-of-explicit-resource-management

Effection Scope: Resource Lifetimes and Cleanup

Joshua Amaju — Fri, 02 Jan 2026 11:16:40 +0000

Effection Scope

In JavaScript, values and variables belong to a scope. When a function runs, its variables are automatically cleaned up once execution exits that scope. Effection takes this idea and applies it to concurrent operations, giving you control over how asynchronous work is scoped and cleaned up.

Problem

We want to double the value by the value provided to any previous call to setter.

function* setter(value: number) {
  let current = (yield* Provider.get()) ?? 0;
  const newValue = current + value;

  yield* Provider.set(newValue);

  try {
    return newValue;
  } finally {
    // clean up here because we don't want any sibling call to setter
    // to see the value of this scope instead of the parent.
    yield* Provider.set(current);
  }
}

main(function* () {
  const value = yield* setter(1);

  yield* (function* () {
    const value = yield* setter(2);

    yield* (function* () {
      const value = yield* setter(3);
      console.log("inner child", value);
    })();

    console.log("child", value);
  })();

  console.log("parent", value);
});

Output:

inner child 3
child 2
parent 1

Instead of:

inner child 6
child 3
parent 1

Why?

Because the cleanup happens immediately when we return, which means the current value is restored before any child operation can observe it.

First Attempt: Using a Resource

What we actually want is for setter to not immediately exit upon return. This is where an Effection resource comes in.

We can rewrite setter like this:

function setter(value: number) {
  return resource<number>(function* (provide) {
    let current = (yield* Provider.get()) ?? 0;
    const newValue = current + value;

    yield* Provider.set(newValue);

    try {
      yield* provide(newValue);
    } finally {
      yield* Provider.set(current);
    }
  });
}

Our setter no longer returns directly. Instead, it lifts its lifetime into the surrounding operation.

So what does the program now output?

Still:

inner child 3
child 2
parent 1

Why This Still Doesn’t Work

At this point, it’s reasonable to ask: why isn’t setter seeing the values from the parent and child scopes?

The key detail is that functions like resource, spawn, and similar helpers create their own scope that exists for the lifetime of the closed-over operation.

Each call to setter therefore gets its own scope, and those scopes are siblings, not nested according to call order.

So instead of this:

- parent
  └─ child
     └─ inner child

We actually get this:

- parent
- child
- inner child

This explains why the values do not accumulate as expected.

Explicitly Passing the Parent Scope

One way to solve this is to explicitly pass the desired parent scope into setter:

function setter(value: number, scope: Scope) {
  return resource<number>(function* (provide) {
    let current = (yield* Provider.get()) ?? 0;
    const newValue = current + value;

    scope.set(Provider, newValue);

    try {
      yield* provide(newValue);
    } finally {
      scope.set(Provider, current);
    }
  });
}

The program now outputs:

inner child 6
child 3
parent 1

This works, but threading scopes around like this is tedious and can easily become error-prone in more complex code.

A Cleaner Solution

A cleaner approach is to capture the scope before creating the resource:

function* setter(value: number) {
  const scope = yield* useScope();
  const current = (yield* Provider.expect()) ?? 0;

  const val = value + current;
  scope.set(Provider, val);

  return yield* resource<number>(function* (provide) {
    try {
      yield* provide(val);
    } finally {
      scope.set(Provider, current);
    }
  });
}

Here, we explicitly capture the scope using useScope() and then create the resource within that scope. By yielding the resource directly, we also avoid ending up with an Operation<Operation<number>>.

This preserves the intended parent-child relationship between calls while keeping the code simpler and easier to reason about.

Avoiding Memory Leaks in JavaScript

Joshua Amaju — Mon, 03 Mar 2025 09:43:00 +0000

In JavaScript, it's easy to unintentionally create memory leaks and dangling promises, especially when dealing with asynchronous operations. This is often due to the way errors and non-blocking tasks are handled. Unfortunately, the tools available don't address or provide straightforward solutions to these problems.

Let's take a look at an example that illustrates this issue:

function operation_might_throw() {
  // Simulates an operation that may throw an error
  throw new Error("An unexpected error occurred");
}

function long_operation() {
  return new Promise(resolve => {
    setTimeout(() => {
      console.log("This will still log to the console");
      resolve(null);
    }, 1000);
  });
}

async function main() {
  // Start a non-blocking asynchronous operation
  const promise = long_operation();
  // Perform another operation which might throw an error
  operation_might_throw();
  // Await the non-blocking operation
  await promise;
}

What's Happening Here?

In this example:

operation_might_throw() throws an error, halting further execution of the main function.
However, the long_operation() continues to run in the background and logs to the console even after the error.
This happens because the promise is non-blocking and isn't aware of the error in the parent scope.

The Problem

This example demonstrates how easy it is to write memory-unsafe and hard-to-debug asynchronous code in JavaScript. Here, the long_operation() continues to run even though it's no longer needed.

The challenge is: How do we ensure that long-running operations clean up once they're no longer needed? In this case, the cleanup should happen because of an error in the parent scope.

JavaScript's native async/await doesn't provide a straightforward way to handle this scenario. This is where Effection comes in.

What is Effection?

Effection is a library that enables structured concurrency in JavaScript, ensuring that asynchronous tasks are managed within a clear and predictable scope.

Rewriting the Example with Effection

Here's how we can rewrite the previous example using Effection:

import { spawn, call, ensure, main } from "effection";

function* long_operation() {
  let timeout: number;

  // Ensure the timeout is cleared, preventing memory leaks
  yield* ensure(() => clearTimeout(timeout));

  const promise = new Promise(resolve => {
    timeout = setTimeout(() => {
      console.log("This will NOT log to the console if an error occurs");
      resolve(null);
    }, 1000);
  });

  // Yield to the promise, allowing other tasks to run
  return yield* call(promise);
}

main(function*() {
  // Start a non-blocking long operation as a child task
  const task = yield* spawn(long_operation);
  // Perform another operation which might throw an error
  operation_might_throw();
  // Await the completion of the child task
  yield* task;
});

What's Different with Effection?

In this version:

The long_operation() is spawned as a child task using spawn().
If operation_might_throw() throws an error, Effection automatically cleans up the child task.
This prevents the console log from occurring, as the long-running operation is canceled.
ensure() guarantees that clearTimeout() is called, preventing memory leaks.

Why Use Effection?

Effection's structured concurrency model ensures that:

Asynchronous operations are organized in a predictable hierarchy.
Child tasks are automatically canceled when the parent goes out of scope (fails or completes).
Memory leaks and dangling promises are prevented by automatically cleaning up resources.

Self Closing Browser Tab with JavaScript

Joshua Amaju — Mon, 02 Dec 2024 08:45:42 +0000

Did You Know You Can Close a Browser Tab Using JavaScript?

It might surprise you to learn that you can close a browser tab programmatically with JavaScript. Yes, it’s possible—using the window.close() method.

This method is typically used only with popup windows, so I was just as surprised as you might be when I first discovered that you can also use it on regular tabs when a page I visited unexpectedly closed after I submitted a form. It felt strange—almost like something you'd expect from a mobile app crashing due to a bug. But on the web, things don’t work that way.

Unlike mobile applications, web pages or browser tabs don’t simply "crash" and close due to a fatal error. At worst, the page may freeze, or you’ll encounter an error message. So, how was this tab closing itself? Intrigued, I decided to dig deeper into the mechanics behind this behaviour.

If you’re curious to see this in action, you can try it right now using your browser's developer tools. Here’s how:

Open the Developer Tools on this page (usually by pressing F12 or Ctrl+Shift+I on Windows, or Cmd+Option+I on macOS).
Navigate to the Console tab.
Type the following command and press Enter:

window.close();

Live demo

Accordion with 0 JS

Joshua Amaju — Mon, 18 Nov 2024 12:45:19 +0000

Did you know you can create an accordion with zero JavaScript? Let’s explore how.

The secret lies in using the HTML <details> element combined with a name attribute. This attribute ensures that when you open one item, any previously open item will automatically close, creating the accordion effect.

Example Code

Below is a simple implementation of a multi-item accordion using only HTML:

<details name="faq">
  <summary>Graduation Requirements</summary>
  <p>
    Requires 40 credits, including a passing grade in health, geography,
    history, economics, and wood shop.
  </p>
</details>
<details name="faq">
  <summary>System Requirements</summary>
  <p>
    Requires a computer running an operating system. The computer must have some
    memory and ideally some kind of long-term storage. An input device as well
    as some form of output device is recommended.
  </p>
</details>
<details name="faq">
  <summary>Job Requirements</summary>
  <p>
    Requires knowledge of HTML, CSS, JavaScript, accessibility, web performance,
    privacy, security, and internationalization, as well as a dislike of
    broccoli.
  </p>
</details>

How It Works

Each <details> element can be expanded or collapsed by clicking on its <summary> child. Adding a name attribute to each <details> element groups them together, so only one item can be open at a time. This technique enables a fully functional accordion without any JavaScript or external libraries.

Benefits

Simpler Codebase: No need for JavaScript, making the code easier to read and maintain.
Accessibility: Native browser support ensures better accessibility out-of-the-box.
Performance: Eliminates the overhead of running JavaScript for basic UI interactions.

Live Demo

Check out this live demo.

The Right Way to Add Images to Emails in Next.JS

Joshua Amaju — Thu, 24 Oct 2024 09:13:38 +0000

If you're building features like authentication or transactional emails in your Next.js app, chances are you’ll need to include images in your emails. But wait—before you assume you can add images the same way you do for regular web pages, there's a small twist when it comes to email clients.

You might think this works:

import Image from 'next/image';

export default function Page() {
  return (
    <Image
      src="/email-image.png" // From your public folder
      // Other props...
    />
  );
}

Or maybe this:

import Image from 'next/image';
import img from '../email-image.png';

export default function Page() {
  return (
    <Image
      src={img}
      // Other props...
    />
  );
}

Both approaches will result in your image being loaded at [host]/email-image.png or /_next/static/[hash].png in a browser. The browser knows what to do here—it infers the host (like https://acme.org), grabs the image, and displays it.

But here’s the kicker: Email clients don’t know your host. Instead of seeing a nice image, your users see... nothing. Because /_next/static/[hash].png doesn’t resolve to a valid resource, it doesn’t know what host the image should come from. Essentially, there's no complete URL that points to a real resource on the internet, so the image breaks.

What's the Fix?

Simple: Use a CDN. Upload the images you need for emails to a content delivery network (CDN) like Cloudinary. Then, reference the generated URL in your emails. Here's how it looks:

import { Img } from '@react-email/components';

export default function Page() {
  return (
    <Img
      src="https://cdn.acme.org/email-image.png"
      // Other props...
    />
  );
}

Boom! Now the email client knows where to find your image. Crisis averted.

Hosting Your Entire `public` Directory on a CDN

If you want to be thorough (or you're loading many images), you can configure Next.js to serve all your static assets from a CDN.

Here's how you'd set it up in your next.config.ts:

import type { NextConfig } from 'next';
import { PHASE_DEVELOPMENT_SERVER } from 'next/constants';

export default (phase) => {
  const isDev = phase === PHASE_DEVELOPMENT_SERVER;

  const nextConfig: NextConfig = {
    assetPrefix: isDev ? undefined : 'https://cdn.acme.org',
  };

  return nextConfig;
};

This tells Next.js to prepend the CDN's URL to all static files in production. For more details, you can check out the official Next.js documentation.

Now, when you use an image in your email component like this:

import { Img } from '@react-email/components';
import img from '../email-image.png';

export default function Page() {
  return (
    <Img
      src={img}
      // Other props...
    />
  );
}

It’ll automatically generate a URL like https://cdn.acme.org/_next/static/[hash].png, and your email images will load without a hitch.

fetch + interceptors

Joshua Amaju — Wed, 28 Aug 2024 08:32:19 +0000

No more untyped network or interceptor errors. Know exactly where errors might happen and what type of error.

Introduction

Popular HTTP libraries like axios provide request/response interceptors but lack a robust way to capture and type errors that may occur within the interceptor chain. This leaves you uncertain about potential errors ahead of time—yet, with TypeScript, we have the power to thread error information throughout our applications.

fetch-prime solves this by ensuring errors are properly typed and handled, making your network requests more predictable and resilient.

Setup

npm i fetch-prime

Example

// features/users.ts

import {fetch, andThen, Fetch} from "fetch-prime/Fetch";

export function getUser(adapter: Fetch) {
  return (user: string) => {
    const res = await fetch(adapter)(`/users/${user}`);
    const users = await res.ok(res => res.json());
    // or get the raw response
    const users = await andThen(res.response, res => res.json());
    return users;
  }
}

// main.ts
import {pipe} from "fp-ts/function";

import Fetch from "fetch-prime/Adapters/Platform";
import * as Interceptor from "fetch-prime/Interceptor";
import BaseURL from "fetch-prime/Interceptors/Url";

import {getUsers} from "./features/users";

// ...

const baseURL = "https://myapi.io/api";

const interceptors = Interceptor.add(
  Interceptor.empty(),
  BaseURL(baseURL)
);

const interceptor = Interceptor.make(interceptors);

const adapter = interceptor(Fetch);

const users = await getUser(adapter)(user_id);

Error handling

class Custom {
  constructor(message: string) {}
}

const error_interceptor = async function (chain: Interceptor.Chain) {
  await chain.proceed(chain.request);
  return E.left(new Custom("Boom 💣"));
};

const interceptors = pipe(
  Interceptor.empty(),
  Interceptor.add(error_interceptor)
);

const adapter = Interceptor.make(interceptors)(PlatformAdapter);

//      ┌─── Either<HttpError | InterceptorError | Custom, Response>
//      ▼
const result = await fetch(adapter)(base_url + "/users/2");

The `Either` Type

Either<Error, Success>

The Error channel represents all possible errors, from your application code, to interceptors, down to the network layer.
While the Success channel represents the final response, either directly from the network call or returned by an interceptor.

Writing your own interceptor

import {pipe} from "fp-ts/function";
import * as Interceptor from "fetch-prime/Interceptor";
import { HttpRequest } from "fetch-prime/Request";

const TokenInterceptor = function (chain: Interceptor.Chain) {
  const { url, init } = chain.request.clone();
  const headers = new Headers(init?.headers);
  headers.set("Authorization", `Token ${token}`);

  // call next interceptor or network request if last
  return chain.proceed(new HttpRequest(url, { ...init, headers}));
};

// ...

const interceptors = pipe(
  Interceptor.empty(),
  Interceptor.add(BaseURL("https://myapi.io/api")),
  Interceptors.add(TokenInterceptor)
);

You can find fetch-prime on GitHub. If you find it useful, please give it a ⭐!

✨ Simple trick for printing a div

Joshua Amaju — Thu, 01 Aug 2024 07:52:48 +0000

Advantages

Your page retains interactivity after print
Plays nice with frameworks
Doesn't require duplicating your UI for print

Steps

Hide every content of the page when in print mode
Make your target element visible in print mode

Step 1

@media print {
  body {
    visibility: hidden;
  }
}

Step 2

@media print {
  #section-to-print {
    top: 0;
    left: 0;
    position: absolute;
    visibility: visible;
  }
}

Then print

const button = document.querySelector('print-page');

button.addEventListener('click', () => window.print());

This method avoids the pitfall of loosing interactivity, other methods replace the entire page content with the static HTML thereby loosing interactivity.

const printContents = document.getElementById(divId).innerHTML;
const originalContents = document.body.innerHTML;

document.body.innerHTML = printContents;

window.print();

document.body.innerHTML = originalContents;

A Proposal to Add Signals to JavaScript: A Mistake?

Joshua Amaju — Wed, 08 May 2024 08:52:20 +0000

Recently, there's been a buzz about a proposal to introduce Signals to JavaScript. But before diving in, what exactly is a signal?

In simple terms, a Signal is like a data cell that can change over time. It can either hold a static value (what we call "state") or compute its value based on other Signals ("computed").

Now, why would anyone want to add Signals to JavaScript? The big idea is that it could make sharing UI logic across different frameworks much easier. Imagine having a single source of truth for your application state, accessible no matter which framework you're using. Sounds pretty neat, right?

But here's the catch: Signals alone won't cut it. To really harness their power, you'd need an effect system. And guess what? That's not part of the proposal. So, if Signals become a thing in JavaScript, you'd still need to rely on libraries or frameworks to handle effects.

And that's where things could get messy. Let's say you build your app using Signals with Framework X. All's well until you need to switch to Framework Y for some reason. But what if Framework Y decides not to support Signals? Suddenly, you're stuck rewriting your logic from scratch.

Okay, you decide going forward you will not use any framework that doesn't use the standard signals API. But how do you find out? You have to scan the entire codebase to find out. Compared to if it were a standard library, you can just check the package.json to see if it has the standard library installed.

Sure, you could argue, "Just use a library that provides an effect system." But what if we flipped the script? What if Signals were left to userland, and frameworks could build on top of a standard Signal library? That way, switching frameworks wouldn't be such a headache.

Moreover, if Signals become part of JavaScript itself, they will rely on polluting the global scope

In my opinion, Signals are powerful, but they should stay in userland. Take s-js, for example. It's been my go-to for handling state for a while now, and it does the job just fine.

I'm not aware of any web API that's exclusive to library and framework authors. Web standards shouldn't bend over backward for frameworks, no matter how popular they are. Let's keep JavaScript clean and focused on what it does best, without cluttering it with unnecessary bells and whistles.

Automatic Application Versioning

Joshua Amaju — Fri, 19 Apr 2024 11:32:39 +0000

Learn how to setup versioning with in your CI/CD workflow

Benefits

Easy rollback to last working release
Automatic release workflow

Setup

npm install @changesets/cli && npx changeset init

Make sure your package.json includes the version field i.e version: "0.0.0" and private: true.

Then set privatePackages to { version: true, tag: true } in your .changesets/config.json

To create a version bump

npx changeset

which should prompt you to specify the type of change

patch - when you fix issues with an exiting release
minor - when you modify features that do not impact application function
major - when you've made changes that add new features or change exiting application functionality

See here for more information on semantic versioning

You'll then be prompted to provide a message for the change.

To create a new version

npx changeset version

To publish the new version

npx changeset publish

Release setup

We'll use the changeset github action. I'll be using firebase for hosting in this example.

Github action

name: Release to Firebase
"on":
  push:
    branches:
      - master
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install dependencies
        uses: ./.github/actions/setup

      # run tests before release
      - run: pnpm test

      - name: create release pull request
        id: changesets
        uses: changesets/action@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      # This step can be replace with your build script i.e `npm run build`, then push to your hosting provider
      - uses: FirebaseExtended/action-hosting-deploy@v0
        # only create a release to firebase if we have changes
        if: steps.changesets.outputs.hasChangesets == 'true'
        env:
          FIREBASE_CLI_EXPERIMENTS: webframeworks
        with:
          repoToken: "${{ secrets.GITHUB_TOKEN }}"
          firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT }}"
          channelId: live
          projectId: <project-id>

This step does the following:

triggers your github action when you merge to master
creates a release PR based on your changesets, which when merged pushes to your desired hosting provider
then creates a tag that's pushed to github.

cover image by Roman Synkevych on Unsplash

Manipulating dates in Typescript

Joshua Amaju — Sun, 07 Apr 2024 09:28:48 +0000

The correct way to subtract or add dates when using Typescript

const diff = new Date().valueOf() - date.valueOf();

valueOf gives you the date as number which satisfies Typescript.

Doing the following produces a warning

const diff = new Date() - date;
// Error: The left-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint' or an enum type.ts(2362)

What is a Promise

Joshua Amaju — Tue, 26 Mar 2024 11:10:04 +0000

In JavaScript, Promises act as containers for values that will be available in the future, regardless of whether they signify success or failure.

Essentially, a Promise guarantees the delivery of a value at a specified time in the future. The type of value within the Promise doesn't matter much; what's crucial is grasping the essence of this essential feature.

While other languages like Dart use the term "Future" for similar constructs, "Promise" provides a more intuitive mental model. It reflects the uncertainty inherent in waiting for future outcomes—perpetual execution represents a potential flaw, akin to a task endlessly leaking resources.

DEV Community: Joshua Amaju

Explicit Resource Management Has a Color Problem

Effection Scope: Resource Lifetimes and Cleanup

Effection Scope

Problem

First Attempt: Using a Resource

Why This Still Doesn’t Work

Explicitly Passing the Parent Scope

A Cleaner Solution

Avoiding Memory Leaks in JavaScript

What's Happening Here?

The Problem

What is Effection?

Rewriting the Example with Effection

What's Different with Effection?

Why Use Effection?

Self Closing Browser Tab with JavaScript

Accordion with 0 JS

Example Code

How It Works

Benefits

Live Demo

The Right Way to Add Images to Emails in Next.JS

What's the Fix?

Hosting Your Entire public Directory on a CDN

fetch + interceptors

Introduction

Setup

Example

Error handling

The Either Type

Writing your own interceptor

✨ Simple trick for printing a div

Advantages

Steps

Step 1

Step 2

A Proposal to Add Signals to JavaScript: A Mistake?

Automatic Application Versioning

Benefits

Setup

To create a version bump

To create a new version

To publish the new version

Release setup

Github action

Manipulating dates in Typescript

What is a Promise

Hosting Your Entire `public` Directory on a CDN

The `Either` Type