Coming From ZIO
If you are coming to Effect from ZIO, there are a few differences to be aware of.
In Effect, we represent the environment required to run an effect workflow as a union of services:
Example (Defining the Environment with a Union of Services)
This may be confusing to folks coming from ZIO, where the environment is represented as an intersection of services:
The rationale for using a union to represent the environment required by an Effect
workflow boils down to our desire to remove Has
as a wrapper for services in the environment (similar to what was achieved in ZIO 2.0).
To be able to remove Has
from Effect, we had to think a bit more structurally given that TypeScript is a structural type system. In TypeScript, if you have a type A & B
where there is a structural conflict between A
and B
, the type A & B
will reduce to never
.
Example (Intersection Type Conflict)
In previous versions of Effect, intersections were used for representing an environment with multiple services. The problem with using intersections (i.e. A & B
) is that there could be multiple services in the environment that have functions and properties named in the same way. To remedy this, we wrapped services in the Has
type (similar to ZIO 1.0), so you would have Has<A> & Has<B>
in your environment.
In ZIO 2.0, the contravariant R
type parameter of the ZIO
type (representing the environment) became fully phantom, thus allowing for removal of the Has
type. This significantly improved the clarity of type signatures as well as removing another “stumbling block” for new users.
To facilitate removal of Has
in Effect, we had to consider how types in the environment compose. By the rule of composition, contravariant parameters composed as an intersection (i.e. with &
) are equivalent to covariant parameters composed together as a union (i.e. with |
) for purposes of assignability. Based upon this fact, we decided to diverge from ZIO and make the R
type parameter covariant given A | B
does not reduce to never
if A
and B
have conflicts.
From our example above:
Representing R
as a covariant type parameter containing the union of services required by an Effect
workflow allowed us to remove the requirement for Has
.
In Effect, there are no predefined type aliases such as UIO
, URIO
, RIO
, Task
, or IO
like in ZIO.
The reason for this is that type aliases are lost as soon as you compose them, which renders them somewhat useless unless you maintain multiple signatures for every function. In Effect, we have chosen not to go down this path. Instead, we utilize the never
type to indicate unused types.
It’s worth mentioning that the perception of type aliases being quicker to understand is often just an illusion. In Effect, the explicit notation Effect<A>
clearly communicates that only type A
is being used. On the other hand, when using a type alias like RIO<R, A>
, questions arise about the type E
. Is it unknown
? never
? Remembering such details becomes challenging.