github Effect-TS/effect @effect/platform@0.44.0

latest releases: @effect/typeclass@0.29.14, @effect/vitest@0.13.14, @effect/sql-sqlite-wasm@0.20.5...
9 months ago

Minor Changes

  • #2006 9a2d1c1 Thanks @github-actions! - With this change we now require a string key to be provided for all tags and renames the dear old Tag to GenericTag, so when previously you could do:

    import { Effect, Context } from "effect";
    interface Service {
      readonly _: unique symbol;
    }
    const Service = Context.Tag<
      Service,
      {
        number: Effect.Effect<never, never, number>;
      }
    >();

    you are now mandated to do:

    import { Effect, Context } from "effect";
    interface Service {
      readonly _: unique symbol;
    }
    const Service = Context.GenericTag<
      Service,
      {
        number: Effect.Effect<never, never, number>;
      }
    >("Service");

    This makes by default all tags globals and ensures better debuggaility when unexpected errors arise.

    Furthermore we introduce a new way of constructing tags that should be considered the new default:

    import { Effect, Context } from "effect";
    class Service extends Context.Tag("Service")<
      Service,
      {
        number: Effect.Effect<never, never, number>;
      }
    >() {}
    
    const program = Effect.flatMap(Service, ({ number }) => number).pipe(
      Effect.flatMap((_) => Effect.log(`number: ${_}`)),
    );

    this will use "Service" as the key and will create automatically an opaque identifier (the class) to be used at the type level, it does something similar to the above in a single shot.

  • #2006 1a77f72 Thanks @github-actions! - change Effect type parameters order from Effect<R, E, A> to Effect<A, E = never, R = never>

  • #2006 af47aa3 Thanks @github-actions! - move where platform worker spawn function is provided

    With this change, the point in which you provide the spawn function moves closer
    to the edge, where you provide platform specific implementation.

    This seperates even more platform concerns from your business logic. Example:

    import { Worker } from "@effect/platform"
    import { BrowserWorker } from "@effect/platform-browser"
    import { Effect } from "effect"
    
    Worker.makePool({ ... }).pipe(
      Effect.provide(BrowserWorker.layer(() => new globalThis.Worker(...)))
    )
  • #2006 a34dbdc Thanks @github-actions! - - Schema: change type parameters order from Schema<R, I, A> to Schema<A, I = A, R = never>

    • Serializable: change type parameters order from Serializable<R, I, A> to Serializable<A, I, R>
    • Class: change type parameters order from Class<R, I, A, C, Self, Inherited> to Class<A, I, R, C, Self, Inherited>
    • PropertySignature: change type parameters order from PropertySignature<R, From, FromIsOptional, To, ToIsOptional> to PropertySignature<From, FromIsOptional, To, ToIsOptional, R = never>
  • #2006 b1e2086 Thanks @github-actions! - remove re-exports from platform packages

  • #2006 02c3461 Thanks @github-actions! - With this change we remove the Data.Data type and we make Equal.Equal & Hash.Hash implicit traits.

    The main reason is that Data.Data<A> was structurally equivalent to A & Equal.Equal but extending Equal.Equal doesn't mean that the equality is implemented by-value, so the type was simply adding noise without gaining any level of safety.

    The module Data remains unchanged at the value level, all the functions previously available are supposed to work in exactly the same manner.

    At the type level instead the functions return Readonly variants, so for example we have:

    import { Data } from "effect";
    
    const obj = Data.struct({
      a: 0,
      b: 1,
    });

    will have the obj typed as:

    declare const obj: {
      readonly a: number;
      readonly b: number;
    };
  • #2006 6361ee2 Thanks @github-actions! - fix for encoding of Transferable schemas

  • #2006 86f665d Thanks @github-actions! - use Context for collecting tranferables

    This changes the platform Transferable module to use Effect context to collect
    tranferables when using schemas with workers etc.

    You can now use a tranferable data type anywhere in your schema without having
    to wrap the outermost schema:

    import { Transferable } from "@effect/platform";
    import { Schema } from "@effect/schema";
    
    const structWithTransferable = Schema.struct({
      data: Transferable.Uint8Array,
    });
  • #2006 9a2d1c1 Thanks @github-actions! - This change enables Effect.serviceConstants and Effect.serviceMembers to access any constant in the service, not only the effects, namely it is now possible to do:

    import { Effect, Context } from "effect";
    
    class NumberRepo extends Context.TagClass("NumberRepo")<
      NumberRepo,
      {
        readonly numbers: Array<number>;
      }
    >() {
      static numbers = Effect.serviceConstants(NumberRepo).numbers;
    }

Patch Changes

Don't miss a new effect release

NewReleases is sending notifications on new releases.