The once FlattenStrategy.

[andersio]

Related: #423

This is a convenience that has been using in our codebase for a while, implemented as take(first: 1).race(). There are a lot of circumstances that we need only one value from a continuous producer (e.g. property).

For example, we can fold this:

property.producer
    .take(first: 1)
    // Since we have just one value, any strategy is irrelevant.
    .flatMap(.latest) { value in
        // Spawn a network request from the value.
    }

into:

property.producer
    .flatMap(.once) { value in
        // Spawn one network request from the first value received.
    }

While it doesn't add substantial functionality, it offers a sensible choice for flattening single-value stream of streams, that also reduces verbosity, from an API consumer POV.

Checklist

• Updated CHANGELOG.md.

[RuiAAPeres]

On the description you explain it's equivalent to flatMap(.latest), but internally you are using race. Which one is true?

[mdiep]

Since there's only one signal, all the strategies are functionally equivalent. The only difference is the performance characteristics.

[andersio]

We do not have a case for performance here yet, just the room for optimization.

Since there's only one signal, all the strategies are functionally equivalent.

race propagates interrupted from the inner stream to the flattened stream. The other strategies do not.

[andersio]

Hmm, so the strategy is more or less relevant. race gives the closest semantic to then (which is essentially flatMapCompleted).

[mdiep]

I'm pretty ambivalent about this addition. 😕

[Qata]

I'm a fan of this addition, the app I most use ReactiveSwift with has a lot of cases that'd benefit from this readability.
I've had to do a workshop to explain why all of our single value streams use .latest.

[andersio]

@mdiep I think now it has a case of performance, despite not practically relevant, in the sense that the take-once constraint enables simpler implementation. 😛

8cccb07#diff-c949eaeac664030204497a79420aaef3R866

[mdiep]

Maybe it's time to reconsider adding a Single type of some sort. It seems like that's the real issue here: it's cumbersome to deal with a stream of n events when you know there will only be 1. #201

[andersio]

I am not quite convinced to have it as a dedicated type, since there is barely a compile time advantage AFAICT. From the static enforcement PoV, Single cannot do better than SignalProducer since it is impossible to statically guarantee an escaping closure to be invoked only once.

To facilitate it, we would also have to replicate the entire API of SignalProducer given the lack of HKT. In the end, all we gain for all these work and on going maintenance are probably just a strategy-less flatMap, perhaps a specialised input observer API that accepts value or error, and a dedicated type name that benefits from a doc PoV. Dynamic enforcement in debug builds could also be a feature.

[andersio]

a dedicated type name that benefits from a doc PoV

I guess this alone could be the primary driver though, since that's also how the division between Signal and SignalProducer started despite having minimal distinction at static time.

[mdiep]

Yeah, I think there are benefits to documentation/reasoning. Many common tasks could be represented as a observable of one value. It would be easy to have APIs to convert between them as well.

The biggest issue is coming up with a good name.