General questions should be asked on StackOverflow, not here. This room focuses on development of Binding.scala.
subview1 and subview2 accept Binding as parameters instead of raw values, in order to partially rendering subviews that when only parts of store are changed.
Var used in the entire application.
copy (which @atry mentioned the demo) is the killer feature (would it be a bold statement to claim that it is something JS/TS world never had?) and can implement redux very easily. and you don't code on the overly-async javascript, instead scala and execution order is not an issue afaik (once upon a time I was banging my head with promise chains). Then the redux is not necessary because the state is already there in a stable manner. In JS world keeping a global state would be very unstable and would be hard to detect and reason on who modifies what. But simply you don't have such language-originated deficiencies in ScalaJs. That's a summary of my overall impression so far.
@mcku
Using MutationObserver, I am able to use jQuery based semantic-ui components without rewriting them in binding.scala from scratch
Could you check something like this: https://gist.github.com/glmars/a597f7c28931a38e2e9b3262279889a9 ?
The main ideas are using Element based selector in jQuery instead of string based and initializing of control right after creation.
There is new one: https://github.com/jducoeur/jquery-facade
{t("hello").bind} gives the correct translation. The idea came from here: https://lingui.js.org/tutorials/react-patterns.html#id1 and i think it is good, and that idea can be ported to scalajs
watch/render/bind or something like this? In our case initialization after creation works well with https://getmdl.io/ and https://materializecss.com
@mcku "i have tried what you have suggested some time ago, and did not work" Are you sure what problem was in initialization and not in missing
watch/render/bindor something like this? In our case initialization after creation works well with https://getmdl.io/ and https://materializecss.com
@glmars I think my conclusion is wrong and jQuery can access the element. And your proposal is very elegant and valuable.
However, it's not done yet. dom.scala thinks it is inserting the element twice and throws an exception. But by tracing, i can confirm that the method is entered just once.
The element is here https://gist.github.com/glmars/a597f7c28931a38e2e9b3262279889a9#file-dropdown-initialize-scala-L17
And here is the exception: https://github.com/ThoughtWorksInc/Binding.scala/blob/v11.3.0/dom/src/main/scala/com/thoughtworks/binding/dom.scala#L106
message is: "Cannot insert SELECT twice!"
and it is successful if the element is not initially specified as a select and dynamically contructed, instead if specified as something already html div like this (which is as legit as the previous one)
val simple = <div class="ui selection dropdown">
<input type="hidden" name="gender"/>
<i class="dropdown icon"></i>
<div class="default text">Gender</div>
<div class="menu">
<div class="item" data-value="1">Male</div>
<div class="item" data-value="0">Female</div>
</div>
</div>yay, it works ;)
