Let's talk about end streams

[c-dante]

Currently, a flyd stream has a companion end stream which dictates the "end state". This is a powerful concept as you have full control over action and reaction to stream endings, and can rewire when a stream ends with the flyd.endsOn function.

My goal with this issue is to give concrete, predictable rules to how streams should work with regard to ending, how an ended stream effects the dependency graph, and most of all, document every module with what cases the stream ends on by default.

In the current implementation, when a stream's end stream fires with ANY value, it ends the stream which detaches itself from all parents (triggered here).

However, the code that skips updating a stream if it is ended checks for strict true (see here).

---

I'm of the opinion that once a stream has ended, you cannot change its value (for either end or main stream), or its end stream value, and attempting to use that stream as a dependency should throw errors.

[jordalgo]

@c-dante I agree about not being able to change a stream's value or it's end stream's value once a stream has ended.

In terms of error throwing, I'm not sure if that should happen if you use an ended stream as a dependency. Maybe just warn in the console? I guess I worry about having to write try/catches when combining streams or always checking if a stream hasn't ended before combining, which seems like a pain. To use a bad analogy: it's totally legit to connect a pipe to a faucet that may never turn on. I'd almost rather see errors thrown if you try to update an ended stream's value and it's end stream's value.

[c-dante]

I'm totally up to talk about pluses and minuses for how things should be handled -- my worry about using ended streams is you basically have a dead graph.

There might be space for an argument of hooking up ended streams just push their last value and end immediately -- so you get 1 fire and that's it. IE:

s = stream(1)
s.end(true)

x = map((n) => n + 1, s)
// x === 2, x.end() === true

Depends how we want to think about these streams.

My main goal is to formalize the stream structure, give good expectations, and have documented what conditions a stream ends.

[jordalgo]

There might be space for an argument of hooking up ended streams just push their last value and end immediately -- so you get 1 fire and that's it.

I believe this is how it works now and is also congruent with how streams can hold an initial value when they are created and map on this value even if it never changes.

[c-dante]

Reviving this topic.

Are we okay with early-out ending when combining on an end stream? How can we have the following behavior work:

const myS = getStream().map(x => x * 2);
// If getStream is ended, myS is NOT ended

I'd expect that if I do:

endedStream.map()

that the result would be an ended stream.

We can still discuss what the value of the mapped stream should be, however (ended, or run the map fn with the final value of the ended stream the end)