port library to effect v4

[fiws]

No description provided.

[fiws]

useless change i think.

[fiws]

duno..

[fiws]

Ai says:

Yes, we absolutely need the queue because of a core architectural change in how Effect v4 handles asynchronous callbacks.

1. The v3 vs v4 API change

In Effect v3, eventStream used Stream.asyncPush, which provided an emit object. You had to call emit.single(value) to push a
value and emit.end() to close the stream:

  // v3 (asyncPush)
  Stream.asyncPush((emit) => {
    context.on(event, emit.single);
    context.once("close", emit.end);
  })

In Effect v4, Stream.asyncPush was deprecated and unified into Stream.callback. Its callback f no longer receives a custom
emit object; instead, it receives a standard Effect Queue (Queue.Queue<A, E | Cause.Done>):

  // v4 (callback)
  Stream.callback((queue) => { ... })

2. Why did Effect make this change?

In v3, emit was an ad-hoc, proprietary object interface created specifically for async streams.

By changing this to a standard Queue in v4, Effect:

1. Consolidated APIs: Unified the stream-callback protocol with the standard Queue primitive.
2. Improved Customizability: Allows you to leverage standard Queue operations (such as capacity bounds, backpressure, custom
   drop/slide strategies, and safety utilities) directly inside callbacks.
3. Optimized Performance: The underlying fiber runtime can pipe the Queue directly into channels under-the-hood without
   wrapping it in an extra intermediate adapter.

3. How we interact with the Queue

To push event values onto the queue safely from the Playwright event-emitter context (which is synchronous/non-effectful), we
use Effect's fast, synchronous push APIs:

• Queue.offerUnsafe(queue, value): Instantly pushes an event down the stream without requiring an Effect context.
• Queue.endUnsafe(queue): Signals that the event stream is finished (e.g. when a page or browser context closes).

[fiws]

getOrThrow is not effecty

[fiws]

ignoreLogged no longer a thing? investigate