.iterator.
def renderItems(property: ModelProperty[MenuNode]): Modifier = {
val seqProp = property.subSeq(_.subNodes)
produceWithNested(seqProp) { (nodes, nested) =>
div(nodes.iterator.zipWithIndex.flatMap { case (node, i) =>
val nodeProp = seqProp.elemProperties(i)
Seq(
button(cls := "menu-button",
onclick := { () => handleClick(nodeProp) },
nested(produce(nodeProp)(_.item.label.render))
)
) ++ node.subNodes.nonEmpty.option {
div(cls := "sub-menu", renderItems(nodeProp))
}
}.toSeq: _*).render
}
}
repeat + get (as opposed to repeatWithNested + produce), the binding only reacts to structure changes, not to property value changes. Your example is fine as you're doing patches (insert, replace, set), but if you ever need to pass slot property somewhere for mutation and someone changes only its value (via .set), the callback is not going to be called. This is also explained in the repeat scaladoc.
Hello, @hughgearse! The simplest solution in my opinion is to wrap your showIfElse with a renderable DOM element and produce such an element each time your value changes:
val booleanProperty = Property(true)
val valueProperty = Property("first")
produceWithNested(valueProperty)((value, nested) => div(
nested(showIfElse(booleanProperty)(
div(backgroundColor := "green")(s"$value component").render,
div(backgroundColor := "yellow")(s"$value component").render
))
).render)You can naturally place showIfElse on top and use produce inside:
showIfElse(booleanProperty)(
div(produce(valueProperty)(value => div(backgroundColor := "green")(s"$value component").render)).render,
div(produce(valueProperty)(value => div(backgroundColor := "yellow")(s"$value component").render)).render
)Please note a subtle difference in those two snippets. If yourbooleanProperty toggles more often than valueProperty changes, the first solution is better since it does not impose re-appending the top level div to your DOM unnecessarily. However if displayed component is pretty constant and values change frequently, the second solution is preferred for the same reason.
Also, it should be mentioned that both produce(WithNested) and showIfElse returns Binding which should be handled to avoid memory leaks. Hence I like the first solution more because you can deal with your showIfElse binding lifecycle usingNestedInterceptor provided by outerproduceWithNested.
*.css file and ScalaCSS code provided AFAIK. The most seamless way I could think of to use custom stylesheets in your Scala code is to:- attach your
*.cssfile to theindex.htmlheader (just below themain.csssheet, like presented in this Guide section), - gather all your style class names using regular expressions, simple script or whatever you wish,
- create
io.udash.css#CssStyleNameinstance for each of the aforementioned classes, referring your custom styles in Scala code, - (optional) migrate your global (unnamed) styles manually to the ScalaCSS DSL.
That's the way we have implemented integration with Bootstrap styles in Udash - please take a look atio.udash.bootstrap.utils.BootstrapStylesimplementation and sample usage. I think it's a good starting point for large CSS files migration. Please let us know if you encounter any problems.
@hughgearse You can't achieve your goal by dealing with SeqPropertyAPI because it's "element-oriented". Since each SeqProperty[T] is a Property[Seq[T]], you can handle SeqProperties like standard Properties filled with sequences:
val seq1: ReadableSeqProperty[Int] = Seq(1, 2, 3).toSeqProperty
val seq2: ReadableSeqProperty[Int] = Seq(4, 5, 6).toSeqProperty
val combined = (seq1: ReadableProperty[Seq[Int]]).combine(seq2)(_ ++ _)However combined is of type ReadableProperty[Seq[Int]] since you treat seq1 and seq2 as ReadableProperties. In order to turn output ReadableProperty back to the ReadableSeqProperty, use transformToSeq:
val transformed = combined.transformToSeq(identity)
I do have one more question and this one about i18n.
Let example that I'd like to have string like:
<p>Some text, <strong>with strong part</strong>, and more regular text.</p>Right now I can do it by spliting text to three parts but it is a bit crazy and very wordy in term of code.
Do you know better solution?
About i18n. I've created: https://gist.github.com/catap/697cb5545c0eaebd3925fbed4ba4d255
@bgrochal would you like to have a pull request with this code?
io.udash.wrappers.jquery.JQuery similarly to how io.udash.wrappers.jquery.JQuery.JQueryWrapper does it to extend it with the .spinner method. If you need more methods, use an auto-generated wrapper, e.g. https://github.com/oyvindberg/ScalablyTyped/tree/master/j/jqueryui
commons-mongo in our internal projects for MongoDB integration and org.scalajs.dom.ext.Storage for Local/Session Storage integration.
Presenter#handleState is usually the best place to deal with model changes, but please remember it should be called by RoutingEngine when resolving states (use Application#goTo instead of calling handleState explicitly). Web browser local storage is referred by org.scalajs.dom.ext.LocalStorage - usage is pretty straightforward. Feel free to ask if you have more doubts.
@hughgearse Please take a look at io.udash.Bindings.AttrOps#bind. It is an extension method available for each Attr - just import io.udash._ to access it. Then, you can do the following:
val className = Property("myClass")
div(cls.bind(className))
className.set("myOtherClass")If you want to handle attributes by name or deal with custom attributes, simply import scalatags.JsDom.all.attr and use:
val attributeName = "my-attribute"
val attributeValue = Property("my value")
div(attr(attributeName).bind(attributeValue))Finally, if you want to manage the class attribute only, please take a look at io.udash.CssView.StyleOps and StyleFactoryOps - there are numerous utils to apply and unapply style classes without handling the attribute directly.
bind extension method is however pretty straightforward, all you need is to call it on your attribute with a ReadableProperty[String] holding the attribute's value.
SeqProperty[B] as below. So that when a property A changes the relevant node is updated automatically. case class A(i: Int)
case class B(a: Property[A]) {
def render = div(bind(a))
}
def render(bs: SeqProperty[B]) = {
val node = div(bs.get.map(_.render))
bs.listenStructure { patch =>
// Add/remove the B nodes accordingly
}
node
}
val seq = SeqProperty[A](Seq(A(3), A(4)))
// How to call render(bs)?
seq.append(A(5))
seq.replace(0, 1, A(2)) implicit class SeqPropTransformer[A](seqProp: ReadableSeqProperty[A) {
def transformProps[B](f: ReadableProperty[A] => B): SeqProperty[B] = {
val seq = SeqProperty(seqProp.elemProperties.map(f(_)))
seqProp.listenStructure { patch =>
seq.remove(patch.idx, patch.removed.size)
seq.insert(patch.idx, patch.added.map(f(_)): _*)
}
seq
}
}@hughgearse You don't have to track SeqProperty structure changes manually in this case. If all what you need is to add/remove/change DOM nodes according to SeqProperty updates, use the io.udash.Bindings#repeat method (enabled by the io.udash._ import). Then, your render method could be:
def render(bs: ReadableSeqProperty[B]) = {
div(
repeat(bs)(item => span(
// use produce(item) instead of item.get to react on item model changes as well
// since produce returns a Binding, we need to wrap it inside a renderable element (span in this case)
produce(item)(_.render.render)
).render)
)
}If you want to render each node in response to a SeqProperty update, just use produce instead of repeat. The difference between those two is presented in Udash Guide under the "repeat" section. Both produce and render require DOM Nodes to be returned by corresponding builders, hence rendering is required.
If you also need to convert SeqProperty[A] to SeqProperty[B], use the transform method, which takes an A => B function converting each element of the input property into a corresponding element of the output property. In your case:
val seq = SeqProperty(Seq(A(3), A(4)))
val transformedSeq = seq.transform((elem : A) => B(Property(elem)))
render(transformedSeq)Using elemProperties is a little bit tricky since it's a "one-shot" method, which does not track input property changes. That's why you need to set a structure listener on the seqProp and to call your f function manually during each update. The transform method is way more readable and convenient in my opinion.
listenStructure approach. But the implicit class I outlined above seems to do the job for me.
listenStructure registration with your approach if called repeatedly, as you don't seem to handle that anyhow. Anyway, since your B is basically Property[A], you're getting a SeqProperty[Property[A]], which is quite a complex representation of anything (as it can mutate both the containers (properties) and the content within them). It's easier to understand when considering Property[Property[A]]. Mutating just the nested property content won't trigger listeners on the outer property with this approach. Still, it might be what you need.
listenStructure returns Registration, which allows to to control the lifecycle of your callback. When you spawn the listeners dynamically, there's no way to determine when they're invalid automatically, so they would never GC. This can be a small or a big issue depending on how many times you call this method ;)