Adding .map and .flatMap to trait Binding

[lxohi]

Map and FlatMap are now classes inside com.thoughtworks.binding.Binding which makes them a little bit difficult to use.

And Scala compiler also fails to do the type inference because upstream & f param are inside the same pair of parentheses.

So currently I have some code like this:

inkBar(new BMap[(Int, Int), Int](offsetWidth, _._1), new BMap[(Int, Int), Int](offsetWidth, _._2)).bind

Is it possible to add .map and .flatMap to trait Binding?

[Atry]

Try import scalaz.syntax.all._

[lxohi]

Works like a charm! Thanks!

[Atry]

Feel free to create a pull request for adding Scaladoc about this trick.

[lxohi]

I've found there are two issues when using import scalaz.syntax.all._ after having some experiences with them:

• If I have something that extends Binding, for example a Var. I need to use (var: Binding[Foo]).map to use these methods.
• These implicit conversions will interference with implicit conversion that from Binding[T] to BindingSeq[T]

What do you think about this two issues?

[Atry]

1. Try import com.thoughtworks.binding.Binding.BindingInstances.monadSyntax._ instead of import scalaz.syntax.all._.
2. There is no implicit conversion from Binding[T] to BindingSeq[T].

[lxohi]

Thank you so much for the reply!
I will use the first one from now 😀

And about the second one.
Yes, these is no implicit conversion default in Binding.scala. Meanwhile I've created one in my local scope for passing the Binding[Node] to children: BindingSeq[Node] param on a component method conveniently.
But before this implicit conversion interference thing, I'm actually not sure which type will be better for a children param. Is it should be a BindingSeq[Node] or a Binding[BindingSeq[Node]] or others? Which type do you prefer?

[glmars]

I'm actually not sure which type will be better for a children param

I suppose, there is no good answer. This is mentioned in #128 (please, see chapter "Containment" and the improvement 1)

[lxohi]

@glmars Yes. I have been through that amazing article completely!

In my understanding, what actually happens here to user defined tags is we first create a dom element and modifies its children attribute.

So if the component is multilayered and the children parameter will be used inside these layers. For example the content param here. We cannot just use current version implementation of user defined tags and let the framework to modify the children attribute on the most outside dom element.

We needs to use @dom functions in this scenario which leads to the question: what should the type of a children parameter be?