rtimush/scalatags-rx

Integration between scalatags and scala.rx

scalatags-rx

ScalaTags-Rx is a small integration layer between ScalaTags and Scala.Rx. It provides a set of type class instances for Rx[T] values that allows you to use them directly in a ScalaTags DSL with changes automatically propagated to the resulting DOM:

import scalatags.rx.all._

object Example extends JSApp {

  val c = Var("blue")
  val text = Rx(s"It is a ${c()} text!")

  def toggle(): Unit = {
    c() = if (c.now == "blue") "green" else "blue"
  }

  override def main(): Unit = {
    document.body.appendChild(
      div(
        color := c, onclick := toggle _,
        text
      ).render
    )
  }

}

Getting Started

ScalaTags-Rx is hosted on Maven Central, to get started, simply add the following to your build.sbt:

libraryDependencies += "com.timushev" %%% "scalatags-rx" % "0.4.0"

For the latest development version use:

resolvers += Resolver.sonatypeRepo("snapshots")

libraryDependencies += "com.timushev" %%% "scalatags-rx" % "0.4.1-SNAPSHOT"

scalatags-rx's Issues

Publish newer releases to Maven

Over at maven central, the newest version is still 0.1 ( http://search.maven.org/#search%7Cga%7C1%7Cscalatags-rx ). Perhaps you could publish the newer versions so that it's easy for new projects to depend on scalatags-rx?

It's an awesome library; and the missing link between scalatags and rx. It really takes things to the next level. It's like the ELK stack - it's when you combine the three that things get interesting.

Also, could you have a look at my PR (and publish it if it looks good)? Thanks
#6

update readme.md

To include the import statements needed to bring scalatags-rx's goodies into scope.

Support 2.13

Hi! Do you have some roadmap for 2.13 support? Thanks!

update scalarx 0.2.8 -> 0.3.1

In newer version of scalarx API has been changed which is not backwards compatible. This causes compatibility issues of scalatags-rx.

consider using outerHTML in tests

In tests assertions are made using node.innerText.
Stronger assertions would be when comparing results on outerHTML level.

Consider below example:

val c = Var("")
val d = Var("")
val node = span(c, d).render
assert(node.textContent == "") //this assertion is weaker than the below one
assert(node.outerHTML == "<span></span>")

Asserting assert(node.outerHTML == "<span></span>" will tell much more about what happened.
Are there any particular reasons for not using it? Sorry, I don't have much experience with "DOM API" ...

Introduce special cases for updating input(value := someRx)

Have a look at this example:

val inputValue = Var("test")

document.body.appendChild(
  div(
    input(value := inputValue),
    button(onclick := { () => inputValue() = inputValue.now + "!" }, "append !")
  ).render
)

This produces an input field with initial value test. When clicking the button, it appends a ! to the end of the value. This works well until the value of the input field has been changed manually by the user. This is because the attribute value on the input field can only be used to set the initial value, but not overwrite values set by the user. For updates, the value property of the rendered input DOM-Node needs to be set.

I propose to introduce special cases for this behavior:
input(value := someRx) should update the value property instead of setting the attribute.

I would contribute this change but need some hints on how/where to do this.

Efficient view updates with diffs

Like in MetaRx:
https://github.com/MetaStack-pl/MetaWeb#diffs
http://metastack.pl/metarx/latest.html#buffers

stealing nodes

Priwiet :)

I discovered supprising feature.
Bindings:
bindRxElement[T <: dom.Element](e: Rx[T]) ... and
bindRxElements(e: Rx[immutable.Iterable[Element]]) ...
expect dom.Elements. This means that it's easy to lost nodes in html because such node can be appended to only one parent. Every time when appended to new parent, the relation with old parent is lost. Of course developer can watch every time when playing with nodes, nevertheless it would be beneficial if library won't support such desings.

Here is simple demo of sealing nodes:

val abcDiv = Var(div("abc").render)
val p1 = p(abcDiv).render
println("p1: ", p1.outerHTML)
assert(p1.outerHTML == "<p><div>abc</div></p>")

val s1 = span(abcDiv).render //this will steal abcDiv node and bind it into new place
println("p1: ", p1.outerHTML) // <p/>
println("s1: ", s1.outerHTML) // <span><div>abc</div></span>
assert(p1.outerHTML == "<p><div>abc</div></p>") //Boom p1.outerHtml is <p/>

More iteresting things happen when abcDiv changes, or when abcDiv is declared as Rx[Iterable[dom.Element]].

As solution to this I propose to rewrite:
implicit class bindRxElement[T <: dom.Element](e: Rx[T]) ...
implicit class bindRxElements(e: Rx[immutable.Iterable[Element]])... accordingly to

implicit class bindRxFrag[T <: Frag](e: Rx[T]) ...
implicit class bindRxFrag[T <: Frag](e: Rx[T]) ...

How do you think?

Compile issues and compatibility with recent scalatags library

Hi there,

If I try to upgrade the scalatags version in my Scala 2.13.11 project from 0.9.4 to 0.12.0 I get the following error:

[backend] $ compile
[info] Compiling 42 Scala sources to /home/baueran/Development/Scala/oorep/project/shared/.js/target/scala-2.13/classes ...
[error] /home/baueran/Development/Scala/oorep/project/shared/src/main/scala/org/multics/baueran/frep/shared/frontend/MateriaMedicaView.scala:6:8: Symbol 'type org.scalajs.dom.package.Element' is missing from the classpath.
[error] This symbol is required by 'value scalatags.rx.RxNodeInstances.e'.
[error] Make sure that type Element is in your classpath and check for conflicting dependencies with `-Ylog-classpath`.
[error] A full rebuild may help if 'RxNodeInstances.class' was compiled against an incompatible version of org.scalajs.dom.package.

It seems, I need a "matching" scalatags-rx version (see last line of the error). Or is there something else I can try and do?

Many thanks!