General questions should be asked on StackOverflow, not here. This room focuses on development of Binding.scala.
One more question. Let's say we have a single page app (SPA) and would like to use a legacy library that is jQuery based, such that some random elements need to be initialized by some jQuery plugin. The SPA renders totally different layouts depending on some conditions (like authentication), therefore it is not guaranteed after the first page load the elements are attached to the DOM. Is there a way to attach an initializer to a
div just for this purpose, so that wherever the div is being used, it is going to get the initializer invoked? (If you know an answer and are willing to answer on SO, I can enter a question there, too.)
Just to make things clear, even workarounds like this after where
dom.render() gets called did not helpdef applyOnMount(selector: String, f: () => Unit):Unit = {
val elemFound: Boolean = org.scalajs.dom.document.body.querySelectorAll(selector).length > 0
if (!elemFound) {
println(s"waiting for elem $selector")
js.timers.setTimeout(Duration.seconds(1000).milliseconds) {
println(s"recursing for $selector")
applyOnMount(selector,f)
}
} else {
println(s"applying on elem $selector")
f
}
}
Thanks for the recommendation, @kahliburke, although i was trying to stay within the binding.scala tooling like watch(),.. Would it be possible to implement it using watch()? I have not tested MutationObserver before, i will consider using it instead of re-implementing some existing components in binding.scala.
@Atry got your point. A similar example I was following was @sadhen's here: http://sadhen.com/blog/2017/01/02/binding-with-semantic.html
When things build up including routing, ui navigation, authentication, working with local and remote data and futurebindings, social media logins, google/leaflet maps, etc, some sort of best practices become necessary. It may be a good idea to keep a binding.scala starter project with up to date best practices for reference and building shared experience. I don't mind offering a starter skeleton for going through common scrutiny if it helps...
@nakedcity here I always have to reference my little blog;) https://pme123.github.io/scala-adapters/development/binding-scala-redux/
@kahliburke thanks for the idea. Here is a gist. https://gist.github.com/mcku/9c360d39dba7915391207f84d1bd0680 . Using MutationObserver, I am able to use jQuery based semantic-ui components without rewriting them in binding.scala from scratch.
I dont mind to switch to anything that does some state management I was even thinking about https://github.com/suzaku-io/diode
when it comes to redux the only that I really like of it is the dev tools which I have found very handy for following the state of the app
I was just asking what is the common practice when you work with Scala.Binding
There is a DEMO that demonstrates how to build a center state tree similar to Redux https://scalafiddle.io/sf/o5fWdS3/3
Note that
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.
In the above example, there is only one
Var used in the entire application.
@nakedcity I also switched from a react+redux app to binding.scala. For keeping alignment with the old project, I am maintaining an actions.scala and a reducers.scala. I think the type safe
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.
The redux middlewares have changed multiple times within the last 2 years. There was redux-thunk 2 years ago now they have some other thing (I can't remember). Now if you start you completely start with a different paradigm, and I don't expect a stable approach to develop there in the short or middle term.
@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.
And if I my guess is correct you are using outdated jQuery facade (https://github.com/sjrd/scala-js-jquery)
There is new one: https://github.com/jducoeur/jquery-facade
There is new one: https://github.com/jducoeur/jquery-facade
I agree. I should admit that I never wanted to enter the jQuery zone. Because there already existed a separate semantic-ui project called stardust, which avoids jQuery completely. It is possible to inspire from that (which i did, too) and rewrite the components, as they did for the stardust. (http://react.semantic-ui.com, and for the dropdown, https://github.com/Semantic-Org/Semantic-UI-React/blob/master/src/modules/Dropdown/Dropdown.js ) But the rewrite can be an exhaustive task.
But the problem with the jQuery part is it only answers to queries after the element is on the dom. Therefore in a binding method, the element is still not mounted on the actual dom, if i understand it correctly. Nevertheless, i did not know this before and i have tried what you have suggested some time ago, and did not work and this is the conclusion i got after inspecting at the browser debugger.
btw, i am using udash i18n for migrating existing translations from lingui. but modified it a little bit, so that
{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
i think part of the work would be to write a sbt plugin that includes a macro to preprocess the code and extract messages, (lingui js uses babel for that), and a translating function that can utilize udash's translation provider and combining that with binding.scala. the result is very efficient and readable.
but i don't have the plugin yet. just the idea and a similar concept for the plugin of scalingua (https://github.com/makkarpov/scalingua) unfortunately i could not make it work in scalajs
for the udash translation wrapper, most of it is here https://gist.github.com/mcku/dd71065a93bf409e8688e75734fde6ce
@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/bind or something like this? In our case initialization after creation works well with https://getmdl.io/ and https://materializecss.com
I still find really handy Leonid to have one state than a bunch of objects across the app
but maybe I’m not seeing clear the approach that you have
for example in this example
data has to be passed which I dont think it’s easy to manage in big projects
I have been working in programing for 20 years I know that but that no changes the fact that the pattern of having a store where you can select just partitions is more manageble than having to control a bunch of raw objects which as you mention was the main cause in the past of memory leaks