@elyphas They do not have all that much in common.
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.
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.
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.
I do have a short question, why exactly does the standard
Really curious as I am still trying to understand the practical differences.
Handler.create implementation rely on SyncIO instead of IO?Really curious as I am still trying to understand the practical differences.
@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.
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 factoriesBut the seed uses the hashed a332851 version for outwatch itself, and there are no a332851 versions for these extra dependencies.
Oh for the example project, we need to update the Version to the current master commit!
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?
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 :)
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.
Gives 404
@cornerman
@markusa380 try "com.github" in your dependency. So the url would be: https://jitpack.io/com/github/outwatch/outwatch/outwatch-reactive_sjs0.6_2.13/08bc0bf6af/outwatch-reactive_sjs0.6_2.13-08bc0bf6af.pom
I am just asking because some issues make it feel like that.
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.