Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Mar 31 17:46

    mergify[bot] on master

    Update sbt to 1.3.9 (#413) (compare)

  • Mar 31 17:46
    mergify[bot] closed #413
  • Mar 31 17:39
    mergify[bot] labeled #413
  • Mar 31 17:39
    scala-steward opened #413
  • Mar 29 18:33

    cornerman on master

    Update sbt-sonatype to 3.9.2 (compare)

  • Mar 29 18:33
    cornerman closed #411
  • Mar 28 12:56
    cornerman closed #410
  • Mar 28 12:55
    cornerman synchronize #412
  • Mar 28 12:55
    cornerman opened #412
  • Mar 27 22:08
    mergify[bot] labeled #411
  • Mar 27 22:07
    scala-steward opened #411
  • Mar 27 10:13
    mergify[bot] labeled #410
  • Mar 27 10:13
    scala-steward opened #410
  • Mar 24 14:59
    busti added as member
  • Mar 24 13:12

    cornerman on master

    Mention outwatch-libs repositor… (compare)

  • Mar 24 13:12
    cornerman closed #409
  • Mar 24 12:48
    cornerman opened #409
  • Mar 24 12:48

    cornerman on cornerman-patch-1

    Mention outwatch-libs repositor… (compare)

  • Mar 24 12:46

    cornerman on cornerman-patch-1

    Mention outwatch-libs repositor… (compare)

  • Mar 24 11:18
    cornerman closed #408
moritz bust
@busti
It is in the new docs
@elyphas They do not have all that much in common.
James Cosford
@jamescosford
Thanks @busti :)
elyphas
@elyphas
@busti , yes, I see the docs, thank you
moritz bust
@busti
One is the api for incoming dom events, and the other one is one to couple subscriptions to the dom lifecycle.
They cross over when building an emitter from a managed element.
That allows you to create a custom emitter based on some element of the dom tree.
elyphas
@elyphas
ah ok, that clear me the things, thanks
moritz bust
@busti
Here is an example
  lazy val size = EmitterBuilder.ofModifier[AARect] { sink =>
    managedElement { elem =>

      val observer = new ResizeObserver({ entries =>
        val entry = entries.head
        import entry.contentRect._

        val result = AARect(
          Vec2(x + width / 2, y + height / 2),
          Vec2(width, height)
        )

        sink.onNext(result)
        // sink.onNext((entry.contentRect.width, entry.contentRect.height))
      })

      observer.observe(elem)

      Cancelable(() => {
        observer.disconnect()
      })
    }
  }
This creates an emitter of the size of an element in the dom tree that emits whenever the size of that element changes.
elyphas
@elyphas
cool!, :)
moritz bust
@busti
So you can just do
div(size.mapTo(s => s"my size is $s") --> textContent)
And when the element is removed, all the subscriptions are cancelled automatically.
Please Note that the API has changed, so the above code won't work anymore.
elyphas
@elyphas
I see, the advantages now!
moritz bust
@busti
I really need to update
elyphas
@elyphas

Please Note that the API has changed, so the above code won't work anymore.

ok, I get it

Markus Appel
@markusa380
@cornerman Sorry for my late response, thanks for the reply!
I do have a short question, why exactly does the standard Handler.create implementation rely on SyncIO instead of IO?
Really curious as I am still trying to understand the practical differences.
johannes karoff
@cornerman
@markusa380 Hej! The distinction was made because in javascript, we cannot just run IO sync (and also do not want to). So IO are actually supposed to be run async. But for the handler construction, we actually want to run the effect sync (at the time the element should be rendered) . To make this explicit, we decided to return SyncIO in the handler-factory. For SyncIO, see: https://typelevel.org/cats-effect/datatypes/syncio.html
I was even thinking about shifting an IO modifier to assure it is run async, but currently this is not done - we just call runAsync.
Though, the end result will always be the same, whether you have IO[Handler] or SyncIO[Handler] .
I am a bit in a hurry now - but if you have further questions about this, please feel free to comment on this and I will try to explain more about the motivation.
Markus Appel
@markusa380
Thanks, so far it does make sense.
swoogles
@swoogles
Hey Folks, what's the status of a ScalaJS 1.0 release? Is it planned to happen when Outwatch itself releases 1.0?
swoogles
@swoogles

Also, if I download the seed project, I can't use anything in the outwatch.reactive package. Nothing on the Github page tells what imports are needed to start using that.
I see these bits:

libraryDependencies += "com.github.cornerman.colibri" %%% "colibri-monix" % "master-SNAPSHOT"
libraryDependencies += "com.github.outwatch.outwatch" %%% "outwatch-monix" % "master-SNAPSHOT" // for handler factories

But the seed uses the hashed a332851 version for outwatch itself, and there are no a332851 versions for these extra dependencies.

johannes karoff
@cornerman
@swoogles we are definitely planning on adding support for scalajs 1.0! Any help would be appreciated, but i will try to find some time this week.
Oh for the example project, we need to update the Version to the current master commit!
johannes karoff
@cornerman
@swoogles I just updated the seed project to the new version.
johannes karoff
@cornerman
I have started a PR to add helpers for javascript-libraries (OutWatch/outwatch#408). What do you think about this? There will be separate projects for each library, but should they live in the main outwatch repo or should we create another repo just for library-helpers?
johannes karoff
@cornerman
I have created a new repository for the mentioned javascript-helpers, you can check it out here: https://github.com/OutWatch/outwatch-libs
We will add more helpers as we go :)
Anthony Cerruti
@srnb_gitlab
Does outwatch have fs2 streaming support? I see it has monix streaming support and that it "supports 3rd party streaming libraries"
johannes karoff
@cornerman
@srnb_gitlab Currently fs2 is not supported. Afaik fs2 streams are pull-based, but for rendering reactively we would need a pub-sub kind of interface. I understand this would be a topic in fs2, is that correct?
I would be happy to support it, but I am not really knowledgable with fs2. We would need a way to subscribe to a stream (so a callback is called whenever a new value arrives) and a way to push values/errors into a stream (like a reactive observer).
And also a way to cancel the subscription.
Anthony Cerruti
@srnb_gitlab
Hmm
Markus Appel
@markusa380
Hey guys, something's wrong with Jitpack:
Gives 404
@cornerman
johannes karoff
@cornerman
moritz bust
@busti
@cornerman Was there a point when outwatch had no VDom backing it?
johannes karoff
@cornerman
@busti what do you mean?
moritz bust
@busti
Was there a point before snabbdom was introduced?
I guess the VDomModifier also technically is a VDom...
I am just asking because some issues make it feel like that.
johannes karoff
@cornerman
No, it is been like this since i joined which was in 2017 after seeing a Präsentation from luka at a conference. And even before it was based on snabbdom.
You are right, in a way our modifiers are Kind of an abstracted virtual Dom AS well.
For me snabbdom is an implementation Detail that renders our modifiers (or Dom description). It has advantages and disadvantages over literal element Manipulation.