You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 10, 2024. It is now read-only.
But this is bad because a) it leaves the filtered stream with the possibility of having no >initial value and b) it doesn't make a ton of sense in terms of signals.
Filtering a stream results in a Signalof Options
def filter(f: T => Boolean): Signal[Option[T]]
This kind of works, but it's different from the usual semantics of filter, and that could be >confusing.
Signal's value is always optional
Where there exists some ADT for the signal's now, along the lines of
sealed trait State[+T]
case object Undefined extends State[Nothing]
case class Defined[T](value: T) extends State[T]
And where a filtered signal's parent changed to a value that its filter didn't accept, its own value would go to Undefined
I am of the opinion that using the State data type under the hood is the best idea, though it would bring about some necessary changes:
//in the Signal trait...
def changes: EventStream[State[T]]
def definedChanges: EventStream[T] = changes collect {
case Defined(t) => t
}
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Some discussion in #59 led to talk about Signal.filter, which ended with a question:
what needs to happen to a Signal when you filter it?
I posted:
I am of the opinion that using the
State
data type under the hood is the best idea, though it would bring about some necessary changes:The text was updated successfully, but these errors were encountered: