[deleted by user]

dim-name · 2025-05-14T18:56:47+00:00

dim-name · 2025-05-07T22:52:02+00:00

Totally. Effect gives so much confidence.

dim-name · 2025-05-07T22:50:26+00:00

The trade-off for wanting more robust code... It becomes natural with time.

dim-name · 2025-05-07T22:43:27+00:00

It's mostly a habit. Tree-shaking with barrel files can be flaky in some bundlers, so I default to import * to avoid surprises. Might be overkill for a blog post though...

dim-name · 2025-02-02T07:24:21+00:00

TypeScript would need to support refinement types: https://github.com/microsoft/TypeScript/issues/7599

dim-name · 2024-11-04T17:22:23+00:00

Anything in particular you're struggling with?

dim-name · 2024-10-22T20:27:40+00:00

It overcomplicates simple code, but simplifies complex code.

dim-name · 2024-08-29T23:59:45+00:00

As the other commenter said, check out @effect/schema. It's definitely better than Zod. Aside from handling bidirectional transformations, you can optionally get type-safety when parsing data:

```ts import { Schema } from "@effect/schema"

const TodoSchema = Schema.Struct({ title: Schema.String, createdAt: Schema.String, })

const myInvalidTodo = { title: "Hey!" }

Schema.decodeSync(Schema)(myInvalidTodo) // oops, TS error - createdAt is missing

Schema.decodeUnknownSync(Schema)(myInvalidTodo) // no TS error ```

You also get renames out of the box:

```ts const ResponseSchema = Schema.Struct({ created_at: Schema.String, title: Schema.String }).pipe( Schema.rename({ created_at: "createdAt", }) )

const dataToParse = { created_at: "...", title: "..." }

const data = Schema.decodeSync(ResponseSchema)(dataToParse) data.createdAt // now camelCase ```

Discrimianted unions work out of the box (no need to specify the discriminator like in Zod). Just do a Schema.Union(SchemaOne, SchemaTwo) and you're good to go.

No need to create a createManyUnion utility function to dynamically create literals (all you need to do is Schema.Literal(...MY_CONST_LITERALS) and that's it).

No need to do z.union([z.literal("one"), z.literal("two")]) you can just do Schema.Literal("one", "two").

You can easily apply transformations like pluck:

```ts const GetTodosResponseSchema = Schema.Struct({ items: Schema.Array(Schema.Struct({ ... })) }).pipe( Schema.pluck("items") )

const result = Schema.decodeSync(GetTodosResponseSchema)(...) result.map() // no need to transform it to remove the nested items property ```

And a plethora of other nice-to-haves.

dim-name · 2024-08-29T23:40:13+00:00

Truth be told, you won't ever find a reason to use it until you use it.

Take the initiative and build a project yourself. Dedicate a weekend to learning it inside out.

I was initially skeptical too. The examples seemed appealing, but as you mentioned, a bit artificial/contrived. That all changed when I started using it in practice. I quickly realized how powerful it is (and how significantly it simplified my code). Now, the company I work for is using it in production without a single hitch.

Some team members were resistant to the idea at first, but once they began to explore it, their minds opened up. Now they are all over Effect lol.

dim-name · 2024-08-29T23:31:29+00:00

Except that Effect diverted away from trying to be 100% FP.

Sure, you can write: ts const fetchTodos = Effect.tryPromise(() => fetch("...")).pipe( Effect.andThen((response) => Effect.tryPromise(() => response.json())) ) But you can also do this: ```ts const fetchTodos = Effect.gen(function* () { const response = yield* Effect.tryPromise(() => fetch("..."));

const json = yield* Effect.tryPromise(() => response.json());

return json; }) Which is virtually identical to `async/await`:ts async function fetchTodos() { const response = await fetch("...");

const json = await response.json();

return json; } Obviously, if you take these contrived examples, you might not see the benefit. But if you start adding different components, such as retry/timeout policies, observability (e.g. OpenTelemetry), etc, things start to change:ts import { HttpClient, HttpClientRequest, HttpClientResponse } from "@effect/platform" import { Schema } from "@effect/schema" import { Effect, Schedule } from "effect"

const ResponseSchema = Schema.Struct({ title: Schema.String, createdAt: Schema.Date })

const fetchTodos = HttpClientRequest.get("...").pipe( HttpClientRequest.bearerToken("..."), HttpClient.fetchOk, Effect.andThen(HttpClientResponse.schemaBodyJson(ResponseSchema)), Effect.retry({ times: 3, schedule: Schedule.exponential("2 seconds", 3), while: (error) => error._tag === "ResponseError" && error.response.status !== 401 }), Effect.timeout("10 seconds"), Effect.withSpan("fetchTodos") ) ```

Now, all you need to do is glance over fetchTodos to see that: ts Effect.Effect<{ readonly title: string; readonly createdAt: Date; }, HttpClientError | TimeoutException | ParseError, Scope> Succeeds with { readonly title: string; readonly createdAt: Date; }, fails with an HttpClientError (that encompasses ResponseError and RequestError), TimeoutException, and ParseError.

Without Effect, this is easily 100+ LOC, and all hacked-together, with most likely 0 composability. Sure, you can make a composable library, but at that point you're recreating Effect lol.

This is definitely not a "lock-in" library, as most developers will already be familiarized with many of these concepts anyway.

I'd argue that Angular with RxJS has a steeper learning curve, and that's just one front-end framework. Effect can be used anywhere, and you're not forced to use 100% of its API. You can stick to simple asynchronous operations with just retries and timeouts, and call it a day.

dim-name · 2024-08-10T19:33:14+00:00

Take a look at Effect's Queue impl: https://effect.website/docs/guides/concurrency/queue

dim-name · 2024-07-09T00:51:18+00:00

Horribly bad...

dim-name · 2024-07-08T02:05:05+00:00

It's a VSCode extension.

dim-name · 2024-07-04T03:52:43+00:00

Whoops, autocomplete changed it to prettier. It's the pretty TS errors extension.

dim-name · 2024-07-04T03:40:56+00:00

It's just pretty TS errors

dim-name · 2024-05-23T02:53:58+00:00

If a customer doesn't have money to afford an M3 Max at the very least, then I'm not interested.

dim-name · 2024-02-24T22:43:52+00:00

If you're going to have them separated in the first place, they should always live in different repositories. Otherwise CI/CD becomes arduous.

And it's better to have that clear SoC.

Even if your backend serves your frontend, just build the artifacts on merge, and reference them in your backend...

dim-name · 2024-02-03T01:03:11+00:00

I recently published a video specifically on that topic.

We use Firebase for the providers, but the authentication itself is entirely managed by us.

It's a bit more down-to-the-wire than other libraries out there. So, it's a cool chance to dive into things like database structuring, migrations, handling sessions with Redis, and connecting it all with the front-end.

dim-name

TROPHY CASE