Service members from Effect.Tag not behaving like normal effects
arekmaz opened this issue · comments
What version of Effect is running?
3.1.4
What steps can reproduce the bug?
given this initial code:
import { Effect } from "effect";
class LoaderArgs extends Effect.Tag("@services/LoaderContext")<
LoaderArgs,
{ context: number }
>() {}
the LoaderArgs.context
is correctly typed as an effect in typescript, and in runtime is present (a function is shown)
however, I cannot do LoaderArgs.context.pipe(...
as it throws a runtime exception ("cannot find 'pipe' in undefined")
also this code fails:
Effect.runSync(
Effect.map(LoaderArgs.context, (ctx) => console.log({ ctx })).pipe(
Effect.provideService(LoaderArgs, { context: 5 }),
),
);
also this code fails:
Effect.runSync(
Effect.flatMap(LoaderArgs.context, (ctx) => {
console.log({ ctx });
return Effect.void;
}).pipe(Effect.provideService(LoaderArgs, { context: 5 })),
);
my small repro is in bun, but I first encountered it with node
also, the following ways of expressing the same code work:
Effect.runSync(
Effect.map(LoaderArgs, ({context: ctx}) => console.log({ ctx })).pipe(
Effect.provideService(LoaderArgs, { context: 5 }),
),
);
and
Effect.runSync(
LoaderArgs.pipe(
Effect.map(({ context: ctx }) => console.log({ ctx })),
Effect.provideService(LoaderArgs, { context: 5 }),
),
);
What is the expected behavior?
the code should work (not throw) as with Effect.Tag member services should just be plain effects which work with every mode of map, flatMap etc...
What do you see instead?
Additional information
No response
It would appear that property names that clash with the tag class (so context
, of
, etc.) are prohibted here.
Merely changing the name from context
to something else should work.
./cc @mikearnaldi
Yeah it is a name clash, unfortunately Tag already have some members, wondering if we can issue a type error in such cases