Support for `tap` to perform side effects

[jfvillablanca]

Is it possible to expose a tap method similar to EffectTS or rxjs?

[jstasiak]

Hey, can you clarify what use case do you have in mind, is it for sync (Option, Result) or async (AsyncOption, AsyncResult) and if the existing API doesn't satisfy your needs?

An example or examples would be great.

Option and Result can already be iterated for example to operate on the value inside, if present (https://ts-results-es.readthedocs.io/en/latest/reference/option.html#iterable).

[jfvillablanca]

I'm not really sure what the intended pattern of the library but I usually chain functions that return Result/AsyncResult with the andThen method

what I have in mind:

const result = await nonAsyncFunctionOne(someArgs)
  .toAsyncResult()
  .andThen((okayValue) =>
    asyncFunctionTwo(okayValue),
  )
  .tap((okayValue) => myLogger(okayValue)) // implicitly returns `okayValue`
  .andThen((okayValue) => nonAsyncFunctionThree(okayValue));

this still kinda works though

const result = await nonAsyncFunctionOne(someArgs)
  .toAsyncResult()
  .andThen((okayValue) =>
    asyncFunctionTwo(okayValue),
  )
  .andThen((okayValue) => {                // this is my "workaround" but for async functions it's hard to get the resolved values without the await which I only use at the edges of the computation
    myLogger(okayValue);
    return okayValue;
  })
  .andThen((okayValue) => nonAsyncFunctionThree(okayValue));

[jstasiak]

Oh yeah, this seems like a really useful pattern and I'd like to support it. Are you mostly interested in sync or async or both?

[jfvillablanca]

I'm interested in both sharing the same interface. I can also take a stab at this and make a PR

[jstasiak]

That would be most welcome.

One design thought I have is: should the transformations that come after the tap callback wait for the tap callback to finish?

Meaning should 2 wait for 1?

someAsyncResult
    .tap(sideEffects) // 1
    .andThen(whatever) // 2

My initial thinking is it should so that we avoid unintentional concurrency and don't proceed if there are errors. If the users wants to make it truly async or ignore errors they can do it explicitly.

Also regarding the name: I don't currently have better ideas, maybe tap is a good name.

[jfvillablanca]

Hey I made a PR, eager to hear your feedback. I skipped implementing it in AsyncResult since I also don't know what's the best way to go about the concurrency issue you raised.

As for the name, tap seems to be popular with other functional languages. I think peek is also nice but it kinda conflicts with how I think of peek in Rust