Web platform streams

[raquo]

Hey @ajaychandran thanks for your #53 PR!

I applied some formatting to your commit, and couldn't force-push it to your branch so I opened this PR. There might be some github PR flow that I'm missing... Anyway, 31493bf is your original commit patched with my formatting changes. I just added you as collaborator, so next time feel free to just create a branch straight on raquo/Airstream.

If this looks good to you, I'll merge.

Closes #53

[ajaychandran]

LGTM.

Also, it would be nice to standardize formatting using the sbt-scalafmt plugin.

[raquo]

@ajaychandran Sadly scalafmt doesn't work for me. Its output is never what I want no matter how I configure it, especially its insistence on handling newlines instead of just letting the developer put whatever newslines wherever they want. The rules / options they have are not nearly flexible enough, and get in the way too much. I can tolerate scalafmt at work where there's a lot of collaboration going on, but on my own projects it's just easier for me to auto-format with intellij when a PR style doesn't match the codebase. Yes, it's stupid but it works. I wish Scala had something like eslint, which knows to get out of your way, but as far as I know there is no such thing.

[yurique]

@raquo there's this setting for scalafmt:

optIn.breaksInsideChains = true

it allows doing this:

  something.f()
    .f2() // it won't try collapsing these into one line
    .f3()

after I enabled this, I could live with what scalafmt does, but yeah, a few things remain that I don't like (but accepted :) ) — the biggest is it's inconsistency when formatting for blocks with <- and = like here:

  for {
    a    <- q()
    abcd <- p()
    something <- f {
                   someCode()
                   here
                 }
    dcb <- o()
    b = g()
  } yield ???

I want all <- and = to be alligned, but no.

[ajaychandran]

The consistency of formatting has significantly improved in recent versions. You may want to give it another try.

Source line breaks can be retained with

newlines.source=keep

Also, formatting can be turned off with

// format: off

Not having standard formatting is a real pain point.

[raquo]

Source line breaks can be retained with

newlines.source=keep

Thanks @ajaychandran that would actually be very nice if it works as expected. Looks like they added this option earlier this year. I'll give it a shot, but I have to prioritize clearing out all pending PRs first.

[raquo]

@yurique I've added support for progress events to AjaxEventStream. That prompted me to reevaluate my desire to keep the ajax integration minimal / unopinionated, because I realized how hard it would be for end users to add custom event listeners to the stream to e.g. distinguish timeouts / aborts / normal errors, so I decided to make the wrapper more opinionated but also more useful in Airstream. It's still pretty plain, but errors are now reported in a structured way.

Also I came up with a new, easier way to create custom streams and signals from external sources (be it ZIO, ajax, futures, etc.). I didn't actually end up using it for Ajax because I wanted that custom val responseEvents. I haven't actually documented this yet, but the API is available via CustomEventSource and CustomSignalSource. The basic idea is to take away some of the foot guns that are available when extending EventStream or Signal, and to provide a short guide for using the restricted CustomSource API. (that one is todo)

Also added a few nice things like val (callback, stream) = EventStream.withCallback[Foo] to simplify canonical use cases of EventBus, integrations with JS code, etc. (stream emits the events fired into callback)

[raquo]

FYI I haven't actually tested the new ajax stream yet. Not sure if adding live network tests is a good idea, but I'd love to have a page like http://plnkr.co/edit/ycQbBr0vr7ceUP2p6PHy?preview (but using AjaxEventStream) on Laminar website.

[ajaychandran]

Constructors such as EventStream.fromSeq require an emitOnce parameter.

Could such constructors be replaced with

object EventStream {

  def fromSeq[A](xs: Seq[A]): EventStream[A] = ???
  def repeatSeq[A](xs: Seq[A]): EventStream[A] = ???

  // or the names could be emitSeqOnce/emitSeq
}

This would improve ergonomics at call site.

// current
// standard code conventions require naming boolean parameters
val s1 = EventStream.fromSeq(List(1), emitOnce = true)
val s2 = EventStream.fromSeq(List(1), emitOnce = false)

// proposed
// smaller code, intent is much more clear
val s3 = EventStream.fromSeq(List(1))
val s4 = EventStream.repeatSeq(List(1))

[raquo]

I made a simple tester for Ajax requests here raquo/laminar-examples#6 and fixed some bugs that I found that way. I only tested simple GET requests so far.

To keep my sanity, I'm gonna merge this PR into next-0.12 now, it's grown too much beyond Ajax. That doesn't mean the work on Ajax is finished, further improvements should just happen in new PRs. The question of get/post/etc helper methods API is still open if anyone still wants to weigh in.