From 0e5e84884f7ab48681d6801af021889842dcd335 Mon Sep 17 00:00:00 2001 From: Giulio Canti Date: Fri, 9 Feb 2024 15:44:01 +0100 Subject: [PATCH] main branch: more fixes after upgrading to latest effect (#452) --- pages/docs/coming-from-zio.mdx | 2 +- pages/docs/concurrency/deferred.mdx | 12 +++++------ pages/docs/context-management/layers.mdx | 6 +++--- pages/docs/context-management/services.mdx | 2 +- pages/docs/data-types/data.mdx | 2 +- pages/docs/data-types/either.mdx | 2 +- pages/docs/data-types/option.mdx | 2 +- pages/docs/essentials/creating.mdx | 24 +++++++++++----------- pages/docs/essentials/effect-type.mdx | 11 +++++----- pages/docs/essentials/running.mdx | 16 +++++++-------- pages/docs/faq.mdx | 2 +- 11 files changed, 41 insertions(+), 40 deletions(-) diff --git a/pages/docs/coming-from-zio.mdx b/pages/docs/coming-from-zio.mdx index a4a7508f5..3f250f791 100644 --- a/pages/docs/coming-from-zio.mdx +++ b/pages/docs/coming-from-zio.mdx @@ -44,4 +44,4 @@ In Effect, there are no predefined type aliases such as `UIO`, `URIO`, `RIO`, `T 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` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging. +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` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging. diff --git a/pages/docs/concurrency/deferred.mdx b/pages/docs/concurrency/deferred.mdx index 5911d3945..7092f0409 100644 --- a/pages/docs/concurrency/deferred.mdx +++ b/pages/docs/concurrency/deferred.mdx @@ -1,6 +1,6 @@ # Deferred -A `Deferred` is a special subtype of `Effect` that acts as a variable, but with some unique characteristics. It can only be set once, making it a powerful synchronization tool for managing asynchronous operations. +A `Deferred` is a special subtype of `Effect` that acts as a variable, but with some unique characteristics. It can only be set once, making it a powerful synchronization tool for managing asynchronous operations. A `Deferred` is essentially a synchronization primitive that represents a value that may not be available immediately. When you create a `Deferred`, it starts with an empty value. Later on, you can complete it exactly once with either a success value (`A`) or a failure value (`E`). Once completed, a `Deferred` can never be modified or emptied again. @@ -24,7 +24,7 @@ A `Deferred` in Effect is conceptually similar to JavaScript's `Promise`. The ke ### Creating -You can create a `Deferred` using `Deferred.make(){:ts}`. This returns an `Effect>`, which describes the creation of a `Deferred`. Note that `Deferred`s can only be created within an `Effect` because creating them involves effectful memory allocation, which must be managed safely within an `Effect`. +You can create a `Deferred` using `Deferred.make(){:ts}`. This returns an `Effect>`, which describes the creation of a `Deferred`. Note that `Deferred`s can only be created within an `Effect` because creating them involves effectful memory allocation, which must be managed safely within an `Effect`. ### Awaiting @@ -36,14 +36,14 @@ To retrieve a value from a `Deferred`, you can use `Deferred.await`. This operat ### Completing -You can complete a `Deferred`[E, A] in different ways: +You can complete a `Deferred` in different ways: There are several ways to complete a `Deferred`: - `Deferred.succeed`: Completes the `Deferred` successfully with a value of type `A`. - `Deferred.done`: Completes the `Deferred` with an `Exit` type. -- `Deferred.complete`: Completes the `Deferred` with the result of an effect `Effect`. -- `Deferred.completeWith`: Completes the `Deferred` with an effect `Effect`. This effect will be executed by each waiting fiber, so use it carefully. +- `Deferred.complete`: Completes the `Deferred` with the result of an effect `Effect`. +- `Deferred.completeWith`: Completes the `Deferred` with an effect `Effect`. This effect will be executed by each waiting fiber, so use it carefully. - `Deferred.fail`: Fails the `Deferred` with an error of type `E`. - `Deferred.die`: Defects the `Deferred` with a user-defined error. - `Deferred.failCause`: Fails or defects the `Deferred` with a `Cause`. @@ -67,7 +67,7 @@ Here's an example demonstrating the state change of a `Deferred`: Sometimes, you may want to check whether a `Deferred` has been completed without causing the fiber to suspend. To achieve this, you can use the `Deferred.poll` method. Here's how it works: -- `Deferred.poll` returns an `Option>`. +- `Deferred.poll` returns an `Option>`. - If the `Deferred` is not yet completed, it returns `None`. - If the `Deferred` is completed, it returns `Some`, which contains the result or error. diff --git a/pages/docs/context-management/layers.mdx b/pages/docs/context-management/layers.mdx index 233482cb7..733a4472b 100644 --- a/pages/docs/context-management/layers.mdx +++ b/pages/docs/context-management/layers.mdx @@ -48,7 +48,7 @@ Layers are a way of separating implementation details from the service itself. service level. -A `Layer` represents a blueprint for constructing a `Context`. It takes a value of type `RIn` as input and may potentially produce an error of type `E` during the construction process. +A `Layer` represents a blueprint for constructing a `Context`. It takes a value of type `RIn` as input and may potentially produce an error of type `E` during the construction process. In our case, the `ROut` type represents the service we want to construct, while `RIn` represents the dependencies required for construction. @@ -93,9 +93,9 @@ And because the service has no dependencies, we can create the layer directly us Looking at the type of `MeasuringCupLive` we can observe: -- `RIn` is `never`, indicating that the layer has no dependencies -- `E` is `never`, indicating that layer construction cannot fail - `ROut` is `MeasuringCup`, indicating that constructing the layer will produce a `MeasuringCup` service +- `E` is `never`, indicating that layer construction cannot fail +- `RIn` is `never`, indicating that the layer has no dependencies Note that, to construct `MeasuringCupLive`, we used the `MeasuringCup.of` diff --git a/pages/docs/context-management/services.mdx b/pages/docs/context-management/services.mdx index f71000942..1d9139739 100644 --- a/pages/docs/context-management/services.mdx +++ b/pages/docs/context-management/services.mdx @@ -46,7 +46,7 @@ Map Here, the Tag acts like the "key" to the service implementation within the context. -Additionally, you need to specify an identifier (in this case, the string "Random") to make the `Tag` global. This means that two tags with the same `key` must refer to the same instance. +Additionally, you need to specify an identifier (in this case, the string "Random") to make the `Tag` global. This means that two tags with the same identifier must refer to the same instance. This feature comes in handy in scenarios where live reloads can occur, and you want to preserve the instance across reloads. It ensures that there is no duplication of instances (although it should not happen in the first place, some bundlers and frameworks can behave strangely, and we don't have control over them). diff --git a/pages/docs/data-types/data.mdx b/pages/docs/data-types/data.mdx index 4d5e535b8..c6820cd5b 100644 --- a/pages/docs/data-types/data.mdx +++ b/pages/docs/data-types/data.mdx @@ -50,7 +50,7 @@ Let's start by creating a case class using `Case` and `case`. This combination a ``` -Here, we define a `Person` data type by extending `Data.Case`. We then create a constructor for `Person` using `Data.case`. +Here, we define a `Person` data type, we then create a constructor for `Person` using `Data.case`. The resulting `Person` instances come with built-in equality checks thanks to the Data module, making it simple to compare them using `Equal.equals`. If you prefer working with classes instead of plain objects, you can explore the use of [`Data.Class`](#class). diff --git a/pages/docs/data-types/either.mdx b/pages/docs/data-types/either.mdx index 91e98b7e7..2e3176cb6 100644 --- a/pages/docs/data-types/either.mdx +++ b/pages/docs/data-types/either.mdx @@ -87,7 +87,7 @@ The `Either` type is a subtype of the `Effect` type, which means that it can be In the context of `Effect`, the two members of the `Either` type are treated as follows: - `Left` is equivalent to `Effect` -- `Right` is equivalent to `Effect` +- `Right` is equivalent to `Effect` To illustrate this interoperability, let's consider the following example: diff --git a/pages/docs/data-types/option.mdx b/pages/docs/data-types/option.mdx index e6783f89a..63e4b2a37 100644 --- a/pages/docs/data-types/option.mdx +++ b/pages/docs/data-types/option.mdx @@ -171,7 +171,7 @@ The `Option` type is a subtype of the `Effect` type, which means that it can be In the context of `Effect`, the two members of the `Option` type are treated as follows: - `None` is equivalent to `Effect` -- `Some` is equivalent to `Effect` +- `Some` is equivalent to `Effect` To illustrate this interoperability, let's consider the following example: diff --git a/pages/docs/essentials/creating.mdx b/pages/docs/essentials/creating.mdx index 5d551f937..b40d5b1d5 100644 --- a/pages/docs/essentials/creating.mdx +++ b/pages/docs/essentials/creating.mdx @@ -209,18 +209,18 @@ Let's explore some common scenarios where `Effect.suspend` proves useful: The table provides a summary of the available constructors, along with their input and output types, allowing you to choose the appropriate function based on your needs. -| **Function** | **Given** | **To** | -| ----------------------- | --------------------------------------- | ------------------------------------ | -| `succeed` | `A` | `Effect` | -| `fail` | `E` | `Effect` | -| `sync` | `() => A` | `Effect` | -| `try` | `() => A` | `Effect` | -| `try` (overload) | `() => A`, `unknown => E` | `Effect` | -| `promise` | `() => Promise` | `Effect` | -| `tryPromise` | `() => Promise` | `Effect` | -| `tryPromise` (overload) | `() => Promise`, `unknown => E` | `Effect` | -| `async` | `(Effect => void) => void` | `Effect` | -| `suspend` | `() => Effect` | `Effect` | +| **Function** | **Given** | **To** | +| ----------------------- | ---------------------------------- | ----------------------------- | +| `succeed` | `A` | `Effect` | +| `fail` | `E` | `Effect` | +| `sync` | `() => A` | `Effect` | +| `try` | `() => A` | `Effect` | +| `try` (overload) | `() => A`, `unknown => E` | `Effect` | +| `promise` | `() => Promise` | `Effect` | +| `tryPromise` | `() => Promise` | `Effect` | +| `tryPromise` (overload) | `() => Promise`, `unknown => E` | `Effect` | +| `async` | `(Effect => void) => void` | `Effect` | +| `suspend` | `() => Effect` | `Effect` | You can find the complete list of constructors [here](https://effect-ts.github.io/effect/effect/Effect.ts.html#constructors). diff --git a/pages/docs/essentials/effect-type.mdx b/pages/docs/essentials/effect-type.mdx index 301dacf87..dd02ab6b2 100644 --- a/pages/docs/essentials/effect-type.mdx +++ b/pages/docs/essentials/effect-type.mdx @@ -2,15 +2,15 @@ import { Info } from "@/components/Callout" # The Effect Type -The `Effect` type represents an **immutable** value that **lazily** describes a workflow or job. +The `Effect` type represents an **immutable** value that **lazily** describes a workflow or job. It encapsulates the logic of a program that requires a collection of contextual data `Context` to execute. This program can either fail, produce an error of type `Error`, or succeed, yielding a value of type `Value`. -Conceptually, you can think of `Effect` as an effectful version of the following function type: +Conceptually, you can think of `Effect` as an effectful version of the following function type: ```ts -type Effect = ( +type Effect = ( context: Context ) => Error | Value ``` @@ -31,8 +31,9 @@ The `Effect` type has three type parameters with the following meanings: In the Effect ecosystem, you may often encounter the type parameters of - `Effect` abbreviated as `R`, `E`, and `A` respectively. This is just shorthand - for **R**equirements, **E**rror, and the success value of type **A**. + `Effect` abbreviated as `R`, `E`, and `A` respectively. This is just + shorthand for **R**equirements, **E**rror, and the success value of type + **A**. `Effect` values are immutable, and all Effect functions produce new `Effect` values. diff --git a/pages/docs/essentials/running.mdx b/pages/docs/essentials/running.mdx index 1d821d8e9..fed026074 100644 --- a/pages/docs/essentials/running.mdx +++ b/pages/docs/essentials/running.mdx @@ -16,8 +16,8 @@ If you check the console, you will see the message `"Hello, World!"` printed. `runSync` will throw an error if your Effect fails or performs any - asynchronous tasks. In the latter case, the execution will not proceed beyond - that asynchronous task. + asynchronous tasks. In the latter case, the execution will not proceed + beyond that asynchronous task. ```ts file=/src/essentials/running/runSync-throws.ts @@ -76,11 +76,11 @@ The `runPromiseExit` function is used to execute an Effect and obtain the result The table provides a summary of the available `run*` functions, along with their input and output types, allowing you to choose the appropriate function based on your needs. -| **Name** | **Given** | **To** | -| ---------------- | --------------------- | --------------------- | -| `runSync` | `Effect` | `A` | -| `runSyncExit` | `Effect` | `Exit` | -| `runPromise` | `Effect` | `Promise` | -| `runPromiseExit` | `Effect` | `Promise>` | +| **Name** | **Given** | **To** | +| ---------------- | -------------- | --------------------- | +| `runSync` | `Effect` | `A` | +| `runSyncExit` | `Effect` | `Exit` | +| `runPromise` | `Effect` | `Promise` | +| `runPromiseExit` | `Effect` | `Promise>` | You can find the complete list of `run*` functions [here](https://effect-ts.github.io/effect/effect/Effect.ts.html#execution). diff --git a/pages/docs/faq.mdx b/pages/docs/faq.mdx index 71f702d5b..e732082ba 100644 --- a/pages/docs/faq.mdx +++ b/pages/docs/faq.mdx @@ -75,7 +75,7 @@ flatMap: (fa: Array, f: (a: A) => Array) => Array 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` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging. +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` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging. ## Layer