Unlocking the Insane Power of Effect.js

title

date

author

readTime

Back to School

Before we get into Effect, we must refresh ourselves briefly with the generator function. Many will not require this primer, but in my experience, generator functions are not typically seen in userland code, so the specific characteristics that they bring to Effect might not be immediately clear.

NOTE: If you are already familiar with generator functions, feel free to skip ahead to the next section.

function* genFunc () {
  const value1 = yield Promise.resolve(1);
  const value2 = yield Promise.resolve(2);
  return value1 + value2;
};

console.log(genFunc); // [GeneratorFunction: genFunc]

Looking at this above example, we can see that the genFunc is a generator function. It uses the function* syntax and the yield keyword to pause and resume execution. When called, it returns a generator object that can be iterated over.

It's the 'iterated' part that is important. The generator function can be paused at each yield statement, allowing us to control the flow of execution. When we call the next() method on the generator object, it resumes execution until it hits the next yield statement (or returns a value).

In a lot of ways, this is preferable to Promises because you have more control over the execution flow. You can pause, resume, and even throw errors into the generator. You'll see, in a somewhat paradoxical way, in Effect code almost behaves more like traditional synchronous code, which enhances both readability and error management.

What is an Effect?

The way that I would describe an Effect is that it's essentially a full-typed operation. The return value, the error(s), and the dependencies, are all type enforced.

So, at a super basic level you could declare an effect like so:

         ┌─── Represents the success type
         │        ┌─── Represents the error type
         │        │      ┌─── Represents required dependencies
         ▼        ▼      ▼
Effect<Success, Error, Requirements>

Getting Into It

Let's look at some actual code.

import { Effect } from "effect"

//      ┌─── Effect<number, never, never>
//      ▼
const success = Effect.succeed(42)

//      ┌─── Effect<never, Error, never>
//      ▼
const failure = Effect.fail(
  new Error("Operation failed due to network error")
)

We see that the difference between a non-Effect program and an Effect program is relavitely straightforward. Instead of throwing errors, you use Effect to manage them instead.

Let's explore another quick example from the docs.

import { Effect } from "effect"

// Define a User type
interface User {
  readonly id: number
  readonly name: string
}

// A mocked function to simulate fetching a user from a database
const getUser = (userId: number): Effect.Effect<User, Error> => {
  // Normally, you would access a database or API here, but we'll mock it
  const userDatabase: Record<number, User> = {
    1: { id: 1, name: "John Doe" },
    2: { id: 2, name: "Jane Smith" }
  }

  // Check if the user exists in our "database" and return appropriately
  const user = userDatabase[userId]
  if (user) {
    return Effect.succeed(user)
  } else {
    return Effect.fail(new Error("User not found"))
  }
}

// When executed, this will successfully return the user with id 1
const exampleUserEffect = getUser(1)

Again, as you can see in the above example, Effect isn't that different once you get your head around things.

Effect.gen Ties It All Together

This is where that generator primer pays off.

Effect.gen is the orchestrator function you want to run as close to the "edge" of your program as possible. It declares the pipeline.

Inside this generator, every yield* _ unwraps an effect, so you can sequence asynchronous work, propagate typed failures, and gather dependencies without losing clarity.

Here's an example from the docs:

import { Effect } from "effect"

const program = Effect.gen(function* (_) {
  const user = yield* _(getUser(1))
  const projects = yield* _(fetchProjects(user.id))
  return { user, projects }
})

The compiler tracks that program can fail with whatever errors getUser or fetchProjects declare, and it knows exactly which services must be provided. If you refactor either dependency, the types guide you to every call site.

In Conclusion

Effect allows you to model each code capability as a small, typed operation, then stitch each together declaratively. The result is code that reads like straightforward TypeScript but comes with the ergonomics of structured concurrency, resource safety, and composable error handling baked in.

Plus, one of the great things about Effect is that you can take whatever you need and leave the rest. If the above was enough to help solidify your Typescript code a bit, you can simply take it, use it, and profit.

Ultimately, we've barely scratching the surface when it comes to the power of Effect. What I've shown you is just the start.

So stay tuned.

For now, check out the docs: https://effect.website/

hew/index.md

Back to School

What is an Effect?

Getting Into It

Effect.gen Ties It All Together

In Conclusion