`mapEffect`

Exactly like map — a naming convention for when the function is really there for its side effect.

Iterable<B> mapEffect<A, B>(B Function(A a) f, Iterable<A> iterable) FxAsyncIterable<B> mapEffectAsync<A, B>(FutureOr<B> Function(A a) f, FxAsyncIterable<A> iterable) Fx<R> Fx.mapEffect<R>(R Function(T a) f) // chain FxAsync<R> FxAsync.mapEffect<R>(FutureOr<R> Function(T a) f)

Lecture

Look at the source and you'll find mapEffect is literally B mapEffect(f, iterable) => map(f, iterable); — same function, same laziness, same signature. It exists purely to document intent at the call site: reach for mapEffect when the callback's return value matters less than what it does along the way (writing to a log, saving to a database, incrementing a counter), and reach for map when the return value is the point.

Because it's a plain alias, everything you know about map carries over unchanged: it is lazy, it composes with .concurrent(n) on the async side, and it has no special error handling of its own. There's no behavioral reason to pick one over the other — it's a readability signal for the next person (often you) reading the pipeline.

Demo 1 · Basics

The callback both records a side effect and returns a transformed value — same shape as map, different intent at the call site:

Demo 2 · Async, with concurrency

mapEffectAsync runs on the exact same engine as mapAsync, so .concurrent(n) parallelizes it the same way — handy for "process and persist" pipelines:

Try it yourself

Exercise: use mapEffect to print a 'billing $<dollars>' line for each amount while converting cents to dollars.

Related: map — the function mapEffect delegates to · peek — observe without changing the value at all · flatMap — map + flatten · concurrent — parallel evaluation