The issue with using Sodium on Scala.js is that Sodium requires Java finalizers for its memory management, and Javascript does not allow for these to be implemented. They are impossible to implement in Javascript, so (unless I am wrong) Scala.js can't possibly have done it. Note that this will only leak memory if you use the Sodium 'switch' primitive, because the issue is in cleaning up Sodium objects that are no longer used, and this can only happen when you use 'switch'.
What do you think about this @sjrd ?
is this really an issue ?
" Java finalizers for its memory management"
Hi, a long question: there is a fairly large third-party library of UI components built with Node.js and a templating language (Nunjucks). At our shop we would like to reuse those components from Scala (JVM) frontends using Play. We attempted to reuse the third party lib with a Play module that essentially runs Node on the JVM to render the components. It is terribly slow as expected. Could scalajs help here?
so I am using the scalajs for the first time and trying to create a tcp server using node net lib: https://millermedeiros.github.io/mdoc/examples/node_api/doc/net.html
using
js.Dynamic.global.require("net") to import the library
my question is if you look at the above example for
createServer whats the scalajs way of passing a promise to it?
We are hiring a Scala/ScalaJs software developer, at the EPFL Swiss university.
Let me know if you are interested, or if you know someone else.
https://lnkd.in/ec_XvPS
The job ad does not say it explicitly, but the platform is written 100% in Scala/ScalaJs.
Let me know if you are interested, or if you know someone else.
https://lnkd.in/ec_XvPS
The job ad does not say it explicitly, but the platform is written 100% in Scala/ScalaJs.
@dabd would be a bunch of work :-) if performance is that critical and you have to use nunjucks, probably a "nunjucks rendering microservice" along side the jvm service would be cleanest. I just scanned the latest graal and it looks like it would work but its probably harder to setup.
@aappddeevv wouldn't that have a bit of overhead? Why not as @OlegYch suggests having the client run the Nunjucks library? I'm not sure how can you achieve that to be honest but it would be a matter of having the Play controllers (ScalaJVM) communicating with the client in ScalaJs. Is there an example of such an application I could take a look at?
You can have the client (js or scalajs) run templating for some standard UI rendering vs email server-side rendering that I mentioned earlier. Depending on the volume of templating though, rendering on the client may not make sense. I'm not sure I uderstand what you are trying to do though and the constraints you face. If the templating is for the UI exclusively, then rendering on the client is fine and I've done that as well using the exact same rendering library as I did for the server side emails. Based on your initial description, it sounded like you wanted rendering server side so the client is not impacted.
@aappddeevv We have a bunch of Play frontend microservices which are doing server-side rendering and they are all using Twirl. Howeve,r soon we will have to use this js library built on Nunjucks which provides standardised UI components for the organisation. I think moving to client-side rendering would have some security implications. Sticking with server-side rendering seems to be the most likely acceptable solution.
That's what I thought. I think that my three "server-side" options are valid unless you rewrite the templating engine. You can skip rewriting the entire server in scala.js as that's probably not feasible. scala.js does not help you per se as you need to run a js-based templating library and scala.js requires a js engine to run on. graal jvm/node is probably too much work to get working and may have ops implications. So if you have to run those js-based templates server side, a small, templating microservice based on nodejs is conceptually easy and callable by your primary play server. It's not clear the overhead from calling a second server is significanlly less than the "slow" rendering though.
i started to use FRP sodium with scalajs-react
val titleS=STextArea(title)
val button=SButton()
button.sClickedSink.snapshot(titleS.cell).listen(println)
<.div(
titleS.component(),
button.getVDOM()
)
this code prints the content of a text area to the console when the button is pressed
titleS does not know nothing about SButton
or the other way around
and of SButton :
here runs the code... right now ... for a while ... until i change it
I'd also be very happy to have such a thing. I started to implement it using scalameta, then I realised that I actually need SemanticDB but didn't have/take the time to learn it deep enough. I could try to start again if there is demand... There was also this talk at the last scala days that could be of interest to you. I don't know where that project stands now though.
MouseEvent.target returns an EventTarget instead of a HTMLElement when clicked inside an iframe.
val iframe = document.createElement("iframe")
document.body.appendChild(iframe)
val iframeWindow = iframe.asInstanceOf[HTMLIFrameElement].contentWindow
iframeWindow.document.body.innerHTML = "<h1>iframe</h1>"
val clicked: js.Function1[MouseEvent, Unit] = (e: MouseEvent) => {
e.target match {
case e: HTMLElement => console.log("clicked an HTMLElement", e)
case e: EventTarget => console.log("clicked an EventTarget", e)
}
}
iframeWindow.document.addEventListener("click", clicked)When I click inside the iframe on the <h1>iframe</h1>, I get an EventTarget instead of an HTMLElement. Why and how to solve it?
i dont even know what this pattern match doing
case e: HTMLElement
why not
case HTMLElement ?
you are pattern matching on the type ?
also
things
are a bit shadowy
why
e
why not
e1 ?