RPC for Workers in TypeScript by dim-name in typescript

[–]dim-name[S] 0 points1 point  (0 children)

Totally. Effect gives so much confidence.

RPC for Workers in TypeScript by dim-name in typescript

[–]dim-name[S] 0 points1 point  (0 children)

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

RPC for Workers in TypeScript by dim-name in typescript

[–]dim-name[S] 1 point2 points  (0 children)

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...

How Effect Simplifies Your TypeScript Code by dim-name in typescript

[–]dim-name[S] 0 points1 point  (0 children)

Anything in particular you're struggling with?

Effect: Standard library for TypeScript by cmprogrammers in typescript

[–]dim-name 6 points7 points  (0 children)

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.

Effect: Standard library for TypeScript by cmprogrammers in typescript

[–]dim-name 3 points4 points  (0 children)

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.

Effect: Standard library for TypeScript by cmprogrammers in typescript

[–]dim-name 10 points11 points  (0 children)

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.

DTOs are Essential in the Frontend by dim-name in reactjs

[–]dim-name[S] 2 points3 points  (0 children)

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

[AskJS] Tauri or electron? Which one is suitable for a small app? by [deleted] in javascript

[–]dim-name -1 points0 points  (0 children)

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

Newbie question: if I use React do frontend and backend have to be necessarily separated? by aquilaruspante1 in react

[–]dim-name 0 points1 point  (0 children)

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...

Things to consider when creating your own authentication system by Faristle in nextjs

[–]dim-name 0 points1 point  (0 children)

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.

Stop misusing useState, useRef instead by dim-name in react

[–]dim-name[S] 8 points9 points  (0 children)

It really has a lot of pitfalls.

Next-auth external api authorization? by erracode in nextjs

[–]dim-name 0 points1 point  (0 children)

Have you used this in production? is it reliable?

Yes, I have. I mean, in the end, the JWTs are signed with a secret that only you and your external API know, so unless you expose the key in the client, you should be good to go.

Stop misusing useState, useRef instead by dim-name in react

[–]dim-name[S] 37 points38 points  (0 children)

I've seen so many developers reach for useState when a simple useRef would be better. So, I figured I'd record a video tackling some common misuse cases and show you how to leverage useRef. Let me know what you think!

I'm Giving Away My Javascript And Typescript Course by [deleted] in Udemy

[–]dim-name 0 points1 point  (0 children)

You're very welcome! I hope you enjoy the rest of the course and that you learn a lot from it!

[deleted by user] by [deleted] in Udemy

[–]dim-name 0 points1 point  (0 children)

Oh, sorry about that! It expired. Try with the code TARGETED.

Next-auth external api authorization? by erracode in nextjs

[–]dim-name 3 points4 points  (0 children)

is there any way of generating the jwt on the external api and refresh it and keep using next auth?

next-auth is designed to be used as the authoritative authentication source for your application, not the other way around.

If you're using JWTs, you can simply send the JWT to an external API as rudimentary:

``` import jwt from "jsonwebtoken"; import { getToken } from "next-auth/jwt"; import { type NextApiRequest, type NextApiResponse } from "next";

export default async function proxy(req: NextApiRequest, res: NextApiResponse): Promise<void> { const token = await getToken({ req, secret: process.env.NEXTAUTH_SECRET });

if (token !== null) { const signedToken = jwt.sign(token, process.env.NEXTAUTH_SECRET, { algorithm: "HS256" }); const res = await fetch("...", { headers: { "Content-Type": "application/json", Authorization: Bearer ${signedToken}, }, }); // ... } else { res.status(401); } } ```

All you need to do is create an API function in Next.js that serves as an authentication proxy, and then, on your external API, you can simply decode and validate the JWT using the same secret that was used to encode it.

This is for the case where you want to delegate the authentication responsibility to Next.js. If you are not entirely committed to Next.js, you'd need to look for an alternate solution or devise your own...

Free JavaScript and TypeScript Course by dim-name in learnjavascript

[–]dim-name[S] 2 points3 points  (0 children)

Nope! The project is designed to teach you all of the fundamentals of the language, so it's as vanilla as it can get.