Add Effect.whenLogLevel
#4342
Add Effect.whenLogLevel
#4342
Conversation
🦋 Changeset detectedLatest commit: 8a1f47d The changes in this PR will be included in the next version bump. This PR includes changesets to release 35 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| <A, E, R>(effect: Effect.Effect<A, E, R>, level: LogLevel.LogLevel) => Effect.Effect<Option.Option<A>, E, R> | ||
| >(2, (effect, level) => { | ||
| return core.withFiberRuntime((fiberState) => { | ||
| const currentLogLevel = FiberRef.currentMinimumLogLevel.pipe(fiberState.getFiberRef) |
There was a problem hiding this comment.
No need for the .pipe here
There was a problem hiding this comment.
fixed in 1dce660, I've also taken care of aligning the code used to filter with the one used in FiberRuntime.log just to keep it consistent (e.g. moving from LogLevel.lessThanEqual to LogLevel.greaterThan and doing an early return.
| @@ -948,6 +948,20 @@ export const logAnnotations: Effect.Effect<HashMap.HashMap<string, unknown>> = c | |||
| core.currentLogAnnotations | |||
| ) | |||
|
|
|||
| /** @internal */ | |||
| export const whenLogLevel = dual< | |||
| (level: LogLevel.LogLevel) => <A, E, R>(effect: Effect.Effect<A, E, R>) => Effect.Effect<Option.Option<A>, E, R>, | |||
There was a problem hiding this comment.
I think we should support passing a string literal too.
|
Hmm will need to move the implementation into the fiberRuntime file to prevent the circular dependency. |
accept literals as well
Type
Description
This is the result from the following Discord discussion: https://discord.com/channels/795981131316985866/1332442902629978132, it implements a new function
Effect.whenLogLevel, for which the specified effect is only executed whenever the log level is enabled.I am unsure if the return type here is okay, currently it permits the effect to return a value, and wrap the return value in
Option.Option. The other possibility would be to simply say the return must be (like forEffect.tap) to bevoid. I could imagine scenarios in which it could be helpful to get the return value, but also feel like that it could be abused in a sense, 95% of usecases would likely justyield*without considering the return value (but one could for example use the return value to determine if other diagnostics should be generated, etc.)Related