Airstream semantics update – RFC

[raquo]

Airstream semantics update – RFC

[raquo]

Unfortunately KeepAlive mechanics won't make it into 0.15.0. I've looked into it, and it's very doable, but it's just too much work for this iteration. Current status as follows:

Done:

• No more == checks in signals
• Signals will re-evaluate their current value after being re-started
• Observables will stop resetting their internal state when they're stopped
• Split operator will always return a Signal (not a stream)
• Take / drop / distinct operators
• Lots of other small stuff

I'm currently wrapping up raquo/Laminar#95. Really happy with how that feature worked out. Now onto "the second 90%"...

TODO for v0.15.0:

• Fix ergonomics issues with the new sync-on-restart logic
• Finish raquo/Laminar#95 and the corresponding revamp of SDT styles API (shaping up nicely so far)
• Other, minor Laminar things like composeEventsFlat
• If I can implement splitByIndex in a couple hours, I'll do that
• Extract my scala-overhead-free JsMap / JsArray interfaces into a separate library
• Rename all event stream classes – drop "event" from the names
• Upgrade my own Laminar app to unreleased versions to make sure the migration is relatively smooth
• Update documentation and website examples
• Write blog post / migration guide
• Release an RC and collect feedback

So, the hard parts are done, but quite a lot of work still ahead. All of that will probably take me a few weeks.

[raquo]

@ngbinh That's the plan, currently I have the following methods drafted:

  /** Distinct events (but keep all errors) by == (equals) comparison */
  def distinct: Self[A] = distinctBy(_ == _)

  /** Distinct events (but keep all errors) by reference equality (eq) */
  def distinctByRef(implicit ev: A <:< AnyRef): Self[A] = distinctBy(ev(_) eq ev(_))

  /** Distinct events (but keep all errors) by matching key
    * Note: `key(event)` might be evaluated more than once for each event
    */
  def distinctByKey(key: A => Any): Self[A] = distinctBy(key(_) == key(_))

  /** Distinct events (but keep all errors) using a comparison function
    *
    * @param fn (prev, next) => isSame
    */
  def distinctBy(fn: (A, A) => Boolean): Self[A] = distinctTry {
    case (Success(prev), Success(next)) => fn(prev, next)
    case _ => false
  }

  /** Distinct errors only (but keep all events) using a comparison function
    *
    * @param fn (prevErr, nextErr) => isSame
    */
  def distinctErrors(fn: (Throwable, Throwable) => Boolean): Self[A] = distinctTry {
    case (Failure(prevErr), Failure(nextErr)) => fn(prevErr, nextErr)
    case _ => false
  }

  /** Distinct all values (both events and errors) using a comparison function
    *
    * @param fn (prev, next) => isSame
    */
  def distinctTry(fn: (Try[A], Try[A]) => Boolean): Self[A]

[pbuszka]

follow-up on rest of the points.

• Signals will re-evaluate their current value after being re-started, Observables will stop resetting their internal state when they're stopped
  same experience as @phfroidmont changes are definitly worth it
• KeepAlive:
  I had occassional issues that would be solved by this (async request cancelling and error handling with a "fast clicker" user)
• Split operator will always return a Signal (not a stream)
  the only case I considred stream out of a split was to solve problems coming from == in Signal semantics which will be fixed.
• Observable completion
  I had one use case where it would be useful. At the moment I use EventStream.merge which kind of works as one stream is just a single sync value. Other then that I did not encounter the need for EventStream.concat

[Dennis4b]

I have 2 questions/comments regarding the signals (using Airstream in the context of Laminar):

1. A common usecase for me is:

child <-- someBoolean.signal.map{
    case false => emptyNode
    case true => div(.. /* some expensive component */ ..)
}

(perhaps with some laminext sugar or similar, but to show the idea)

Here I really only want to trigger when the signal changes, as it's inefficient to redraw for no reason, and any state in the big component is lost.

I'm not sure under what circumstances the signal would fire twice though? If I do someBoolean.set(true), can that result in multiple true events? If the price of this change is to modify this to someBoolean.signal.distinct.map{ that would be fine.

2. Something that is perhaps not too related to this issue:

I often unintentionally start with something like:

child <-- bigCollection.map(_.size).signal.map{
     case 0 => emptyNode
     case _ => div(... /* some expensive component */ ..)
}

and then realise that this redraws for any change in bigCollection.size.. so I need to use bigCollection.map(_.size > 0).map{ in order to have a signal that only fires when relevant.

I guess this is the correct and expected behaviour though, and something I should just learn to keep in mind.

[raquo]

If I do someBoolean.set(true), can that result in multiple true events?

In the new system if you set true N times in a row, you will get N events. In the old system you would only get one event because the subsequent ones would be auto-deduplicated And yes, in the new system you'll need to say `someBoolean.signal.distinct` to avoid redundant renders in case you emit true twice in a row Regarding scenario number 2 - Yes, that is expected, currently if you want a signal that emits when the map's emptiness changes, you need bigCollectionSignal.map(_.nonEmpty), and in the new system you ALSO need to add `.distinct` to it to avoid redundant renders when collection size changes Also just FYI with this kind of logic it sounds like you would benefit from https://github.com/raquo/airstream#splitone in some cases. It's like split but for cases when you don't have a list, only single values. It does `==` checks internally and will continue doing so, just like split itself.

[pbuszka]

I think the new semantics for signals is a very good choice. It gives back control over == / distinct aspect which would be very useful for performance and/or complexity management. I found myself more then a few times in a limbo where I needed at the same time both a stream to handle the event semantics and signal to handle view aspect for the same data. In simple use cases you can go around this but in more complex scenarios (i.e. state mapping, multiple data sources combine, error handling, chains of async calls) it gets messy very quickly and sooner or later you come to the problem of "converting" streams to singals and vice-versa which is not sound at all.

[raquo]

Yes, same here, I do not appreciate having to shoehorn big states into streams just to avoid the cost of `==`. The choice should be based on the concept, not on performance characteristics.

[phfroidmont]

Here are my thoughts:

• No more == checks in signals:
  This will require a thorough review of my existing code but it will be worth it. The added control will simplify some places and require to be more explicit in others.
• Signals will re-evaluate their current value after being re-started:
  I'm very excited for this, I've spent quite a bit of time hacking around this one.
  For instance, I have a text area which is resized automatically based on its content. Since it also needs to be hidden/displayed, the size must be computed again when it gets displayed. Simply using onMount doesn't work as the Signal feeding it is out of date.
• Observables will stop resetting their internal state when they're stopped:
  Makes complete sense for the same reasons.
• KeepAlive:
  I didn't run into a case where un-mounting the owner before getting a response was required
• Split operator will always return a Signal (not a stream)
  I never felt the need for something else than a Signal from a split
• Observable completion
  I didn't encounter a use case for this.

[raquo]

@phfroidmont Good feedback, thanks!

[ngbinh]

• No more == checks in signals:
  I think this makes sense. Additionally, we can add a distinctUntilChanged simlar to monix Observable to get back the old behavior

[fgoepel]

That sounds like a good change to me. I just got bit by the Signal deduplicating events issue, because I didn't pay sufficient attention to the return type of 'startWith' and its implications.

[raquo]

I've implemented most things here in Airstream 15. Did not have time for observable completion and keepalive yet.