Sodium seems to work with scala.js

jhegedus42 2019-10-24 01:56:17 UTC #1

Dear Sodium Community,

I have only tried one test, but it worked just fine, out of the box.

jhegedus42/irie/blob/2c56812358993e73f0024533451b4de0558471de/modules/client/src/test/scala/sodium/NodeTester.scala#L8-L8


class NodeTester extends FunSuite {

Hope this helps for people who want to try Sodium for the web.

Other alternative is monix.

But I'd prefer Sodium for a start - if it does not work with Scala.js then I switch to monix - the problem with monix
though is that it is bloated, overkill, difficult to see the forest for the trees. Monix OTOH works well with scala.js.

I just run the memory leak test on Node.js : http://github.com/jhegedus42/irie/blob/master/modules/client/src/main/scala/sodium/MemoryTest1.scala#L25-L25

It might leak a bit of memory, the above code increased memory consumption by 15 M, from

to something like :

or a bit more, top consumption was 111M, or so.

I cannot really tell if this leaks memory or not... the experts here can say that.

In any case, if this memory leak issue can be dealt with then Sodium might be a nice FRP for Scala.js (real FRP, with transactions, without glitches, unlike monix, which has glitches and has not concept of transaction - AFAIK).

Cheers,

Jozsef

the-real-blackh 2019-10-24 08:06:48 UTC #2

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'.

In the Typescript/Javascript version of Sodium we solved this properly by tracking Sodium objects with a usage count + a cycle detection algorithm.

All FRP systems for Javascript will face this issue, so it's possible that Monix leaks. Rx.JS had no proper solution to it the last time I looked.

The easiest way to properly solve the memory issue for Scala.js would be to wrap the Typescript/Javascript version - which has the proper memory management for Javascript - in a thin Scala wrapper.

jhegedus42 2019-10-25 23:20:10 UTC #3

Thanks @the-real-blackh,

Would it not be possible to do the same trick in scala ? The count + cycle detection algorithm ?

Or, maybe https://github.com/oyvindberg/ScalablyTyped could generate the wrapper from typescript.

Still... a nice pure scala implementation vs JS ... not happening ... is a bit ... well "life".

So, here is an example I wrote :

Before button press:

After button press:

Sodium widget code :

React comp. code :

Code:

github.com

jhegedus42/irie/blob/58a0aaa2732211f0bda11bfd900aeeb76ae23ee8/modules/client/src/main/scala/app/client/ui/components/mainPages/userHandling/userList/UserListComp.scala#L35-L35


val label = SodiumLabel(sbutton.sClickedSink.map(x=>"bello").hold("hello"))

github.com

jhegedus42/irie/blob/58a0aaa2732211f0bda11bfd900aeeb76ae23ee8/modules/client/src/main/scala/app/client/ui/components/sodium/SodiumWidgets.scala#L37-L37


case class SodiumButton(name:String) {

Cheers
Jozsef

jhegedus42 2019-10-25 23:29:47 UTC #4

@the-real-blackh , where are these java finalizers ?

are they really not implemented in scala.js ?

https://gitter.im/scala-js/scala-js?at=5db3847414d55a37857807f1

I started a discussion on this topic here ^ .

Cheers,

Jozsef

the-real-blackh 2019-10-29 02:29:06 UTC #5

Yes, it's definitely possible to use the count + cycle detection approach in pure Scala. A Scala version of Sodium written that way would work correctly on both the Java VM and in Javascript.

It wouldn't be a huge amount of work. Most of the changes are confined to the Node module. The code for this is in the Typescript implementation of Sodium. The module is called Vertex.ts because the word 'Node' has some special meaning in Javascript.

jhegedus42 2019-10-29 22:14:56 UTC #6

Nice !

So I just keep using Sodium now for my project and deal with the memory leaking issues when they start to be the issues

Cheers,

Jozsef

jhegedus42 2019-10-30 05:34:57 UTC #7

I will keep posting here stuff that is related to Scala.js + React + Sodium combo.

So far, it's pretty neat.

I managed to achieve compositionality.

https://gitter.im/scala-js/scala-js?at=5db91d9de886fb5aa21e16ed

        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 STextArea to console... when the button is clicked
6 lines of code for the core logic (+ the widgets, which are reusable, and completely independent
from each other)

I don't think it is possible to write this kind of composition more elegantly in React + Scala.js only.

the generated HTML looks like this:

it's pretty fantastic that all the event handling logic is captured in one single line :

button.sClickedSink.snapshot(titleS.cell).listen(println)

and that's it...

so far... this is pretty nice.

here runs the code, for now... until i change it ...

http://commserver.asuscomm.com:8080/#NoteEditorPageRoute/be53a7a6-0a66-452a-b71e-591b651b120e

here is the JS console output :

it captures whatever is in the text area :

jhegedus42 2019-10-30 15:56:59 UTC #8

I am writing some more widgets.

Here is a widget that saves some data to the server:
http://github.com/jhegedus42/irie/blob/origin/master/modules/client/src/main/scala/app/client/ui/components/sodium/SodiumWidgeSaveEntityToServer.scala#L19-L19

case class SodiumWidgeSaveEntityToServer[V <: EntityType[V]](
  stream:    Stream[UpdateReqPar[V]],
  val cache: Cache
)(
  implicit
  c:       WriteRequestHandlerTC[WriteRequest, UpdateReq[V]],
  decoder: Decoder[UpdateReq[V]#ResT],
  encoder: Encoder[UpdateReq[V]#ParT],
  ct:      ClassTag[UpdateReq[V]],
  ct2:     ClassTag[UpdateReq[V]#PayLoadT]) {

  def saveEntity(
    par: UpdateReqPar[V]
  ): WriteRequestHandlerStates.WriteHandlerState[UpdateReq[V]] =
    cache.writeToServer[WriteRequest, UpdateReq[V]](par)

  stream.listen((x: UpdateReqPar[V]) => saveEntity(x))

}

It seems that Sodium can get rid of event handlers/listeners, etc...
I just connect the button to this widget and that's it. One line of code.
All the data flow can be written down using a few lines of code...

and what is more important : those lines are next to each other.

So it's like a drawing of the dataflow pipeline.

If I can make this work... with react... then that will take away a huge amount of pain.

Wow.

jhegedus42 2019-10-30 16:34:35 UTC #9

i think it makes sense to use Sodium+React

Sodium creates the VDOM, and fast.
React uses the VDOM to update the real DOM, and fast.

React also has the concept of "Components" which can be stateful, React detects the state changes
and only updates where something needs to be updated. So react is fast.

If I were to use Sodium to generate the real DOM, then I would loose referential transparency.

With Sodium, I get a state-machine, that produces a VDOM, which is "immutable", and the VDOM is used
to update the real DOM, which is mutable. So Sodium widgets are simply functions that are used to create
VDOM and they don't have to worry about actually updating the real DOM - efficiently. React takes care of
that.

For example think about a List with 1000 Sodium widgets in it. If there was no React then the Sodium widget
would be responsible for updating the DOM in an efficient way. It would need to do the diffing itself and only
update what has changed and re-generate the whole list from scratch.

So Sodium widget's simply output VDOM, and that VDOM can contain Sodium Widgets ... and then there
we also have switch... so the VDOM generating graph can be dynamic. The VDOM generating Widgets and their connections can depend on the state of the system and can change in response to events.

For example this could be used to implement a router in an SPA, with a few lines of code.

Well, I won't spend much time "fixing what works already", unless I will need to change it - but new things I will
try to write using Sodium.

For example this : https://github.com/jhegedus42/irie/blob/3b734ccffa5b0b8161288f856285d2aff0e6ef29/modules/client/src/main/scala/app/client/ui/components/mainPages/noteHandling/noteEditor/NoteEditorComp.scala#L85

also, FRP can be used very nicely for cache invalidation, since it is by default a cache invalidator machinery,
so I might replace my caches with Cell's and describe cache invalidation logic using Sodium.

But for now, my caches seem to work fine, but if it gets too complex to write cache invalidation code, then I might refactor the caches in be just simple Sodium cells.

Need to see. In theory it sounds pretty decent idea to use Sodium with React, and for now, it seems to work on simple examples. Let's see how far I can push it.

the-real-blackh 2019-10-31 21:19:15 UTC #10

That's totally brilliant!