Dynamically creating new FRP-Widgets - do I need switch for that?

[jhegedus42]

Suppose I want to allow the user to create new FRP-Widgets at runtime, for example a new SButton here.

Questions:

• For that I need some sort of switch right ? I mean, there is no other solution for that than using switch. If I understand correctly such a situation (adding/removing widgets) is one of the main use cases of switch because GUIs change dynamically all the time, so the graph needs to change.

• Is this use case discussed in the book ? If yes where ? I read it quickly through last evening, looking for this, but did not find it. The closest thing I found was the screen switching in Zombicus.

[the-real-blackh]

Hi,

Yes, a switch is absolutely require to achieve this. To cut a long story short, this is the philosophically correct way to do it and it would work well. We are breaking the law slightly, pretending that widget creation is not I/O. Basically we are pretending we are working with an imaginary functional GUI library.

The only discussion of this in the book is in Chapter 7, and the screen switching is the closest to that use case.

Steve

[jhegedus42]

Basically we are pretending we are working with an imaginary functional GUI library.

React is pretty functional in this respect. React "widgets" (without state, having only props) are described purely by virtual dom, which is referentally transparent, immutable.

So I have the gut feeling that it could fit nicely with FRP.

[dakom]

Yes, a switch is absolutely require to achieve this. To cut a long story short, this is the philosophically correct way to do it and it would work well.

Is it possible to post a super barebones code sample of how to do this? I'm biased to the Typescript implementation but any language is fine... I feel like switch is something I don't really get yet

[the-real-blackh]

I may have given you the wrong advice, actually. Creating new widgets can be done any time. It's only if you want their output to be used in existing FRP logic that you'll need a switch - but the need for this should be obvious.

What's your use case?

[dakom]

Interesting!

I don't really have a specific use-case with code yet, but I'm hoping to migrate some stuff over to FRP which is basically like a drawing app.

In particular, the ability to add/remove stickers from the scene. I'd imagine each sticker is its own cell, rather than a Cell<Array<Sticker>> holder, but I'm not sure yet.

More generally it would be helpful to have more examples of switch to look at, which I guess is related to the overall recipes/wiki thing

[dakom]

I'm playing around with this, and adding stickers is pretty easy...either accum or collect can simply push new Cells onto a List.

For removing stickers though - I'm not sure how to go about it. I'm trying to keep everything as pure so there's no pointers/references to hold onto... how is something like this done in Haskell (or more specifically, how should it be done in FRP)? Do you give each item an auto-incremented counter/id and then cull the list by that?

[the-real-blackh]

The usual pattern is to have a cell along the lines of Cell<ImmutableMap<Int,Cell>>, which is defined a hold of the merge of two streams: one for adding items, and one for removing them. When adding items, you have to allocate a unique number. When removing them, your logic has to remember the number that was allocated.

Basically in real functional programming, there is no such thing as a reference to an object. Because of that, you have to use unique keys - usually integers - to reference things. You might find it useful to use Supply - which is in the book and will be somewhere in the examples directory - to allocate unique numbers. Alternatively, you can just get the highest key in the ImmutableMap data structure and add 1 to it.

Another way to view this is that in functional programming, data structures (the word "objects" isn't really used) do not have any identity other than their value. If they contain functions, then they don't have any identity at all, because functions are opaque: there is no way to ask if one function equals another. Cells and streams are the same. There is no equality operation for them. Java will let you compare the references to them, but in FRP/FP that is a totally invalid thing to do.

[dakom]

Oh man... I forgot how much fun FRP can be! This is so elegant it feels unfair... a time-varying sticker accumulating thing

1. makeStickerFromUrl() takes a string and returns Cell<Maybe<Sticker>> (not shown here because under the hood it loads the graphics etc. - but basically it sends either a Nothing or a Just to its Cell)
2. sStickerAddUrl gets sent the url request and accumulates the makeStickerUrl() calls into a list, resulting in a new Cell of type Cell<Array<Cell<Maybe<Sticker>>>>
3. Since Cells are fantasy-land compatible, we can map that Cell with S.sequence(Cell) to turn that into Cell<Cell<Array<Maybe<Sticker>>>>
4. We can then flatten it via Cell.switchC to get Cell<Array<Maybe<Sticker>>> - in other words a time-varying list of all the (maybe) stickers!

Unbelievable that all of this is simply:

const cStickers =
    Cell.switchC(
        sStickerAddUrl.accum([], (url, list) =>
            list.concat(makeStickerFromUrl(url))
        )
        .map(S.sequence(Cell))
    );

!!!

[jhegedus42]

Thank you for the replies, sorry for coming back to your answers so late... I got a bit distracted.

Good nows though is, that there seems to be some interest now in using FRP (monix) in Scala.js for
doing SPAs. However, instead of monix - I am trying to advocate Sodium to be used with Scala.js -
especially because of the FRP book and because of Sodium's minimalism. FRP is not easy to learn,
so a good learning source and a minimalistic library might help the (slowly but steadily growing)
Scala.js community to adopt FRP into their SPAs.

Cheers,

Jozsef

[the-real-blackh]

Jozsef, I'm really grateful. I put everything I had into Sodium and writing the book, and it knocked the stuffing out of me and I haven't had anything like the same energy level since. I put all my energy into making it the best it could be, and didn't have much left to promote it afterwards. I really need people to pick the baton up at this point, and you guys have been great.

[jhegedus42]

The things, if something is good, it is good. Sooner or later good things will be discovered.

I, personally, start to suffer from React, and it might be that Sodium could be a super minimalistic
way for the Scala.js community to start to use FRP on the SPA side of their web-apps. I think it is
Scala.js where Sodium could get traction (I don't know about the TS community, that might work too).

In any case, I keep hateing React more and more... and maybe the reason is that I have a feeling that
there is a better way. I am trying to put that better way into real action, out of suffering and hate. It is
insane how crap React is. I simply cannot comprehend how people can put up with it.

But, of course, we need to know that the intended audience of React was not haskell users but
javascript coders - so, by definition, their dayjob is to put up with javascript.. and compared to
writing SPA in pure JS instead of writing it in crappy React, as already a step forward, for JS folks.
So when they look at React they see that lot of their suffering is gone, so, React was a sweet spot
for JS folks - but JS is JS and will stay JS ... and TS is ... JS but J is changed to T.

So, the only serious FP community, for the web, IMHO, is the Scala.js community. Where production
meets FP. I have seen some attempts in the Scala.js community to do "FRP" but they won't really
get traction because they are isolated... from React.

There is a very mature library that wraps React into Scala.js, I am using that, it works and it gives
access to the whole React ecosystem because it is a React wrapper.

The problem with React is the unidirectional dataflow. That is where Sodium can come in. If I combine
React with Sodium in Scala.js, then I can keep the best parts from all. React is a good "drawing library",
Sodium takes care of modelling the state-machine in an FRP way, Scala.js makes it possible to use Sodium
in a functional setting (since Scala can be anything... it is really powerful), nowadays Scala is going towards
Haskell very rapidly, when it comes to "real" FP (see cats).

The thing is. FRP is new, not familiar, but the other options are just so bad, in comparison, that hate will
win over unfamiliarity... once people see a few examples...

with me, the unfamiliarity part is not so "problematic" and I know that there is a better way than React, so
I do hate React - lot of people don't hate React because they think that it is the best thing ever invented for
SPA and it will never get better.

Anyway... I think I can figure out how to use Sodium in some real world project (even if it is a "toy" project),
combined with React, because the more I use React the more I hate it.

Current "solutions" to this hate are ... let's not even go there.

The problem is, people do not know that they are using crap and the solution to that crap is also crap.

Fantastic.

So, in essence, some people, like me, are driven towards FRP, when making SPAs. I will use Sodium to
try to not go insane.

The nice thing is, that Sodium is dead simple. Once one reads the book.

So, hate of React drives me towards Sodium... and it's simplicity and the learning resources.

If people see that Sodium works in Scala.js, and they start to hate React's unidirectional dataflow and
the crappy "solutions" to that. Then they have only one option to learn FRP.

Well, I try to do everything as painlessly as possible, and I am super lazy... so I will try my best to
figure out how to put Sodium into my toy project because React is simply torture, for people who
know that there is a better way.

In any case... I will give it a try because React is such a suffering that I think it is worth to figure out
a way to take out the pain from React using FRP, and the only way to do that is to use Sodium because
that is the only FRP library for which an understandable learning source exist.

I guess sooner or later people will be driven to FRP because they don't want to suffer anymore... even
with React...

anyway, I got something working now with Scala.js + React + Sodium and it already seems like a dream, compared to the same code in React:

  object FRP {
    val sbutton = SodiumWidgets.SodiumButtom()

    val cell: Cell[String] =
      sbutton.sClickedSink.map(x => "bello").hold("hello")

    val label: SodiumWidgets.SodiumLabel =SodiumWidgets.SodiumLabel(cell)

    val vdom= <.div(
      sbutton.getVDOM(),
      <.br,
      label.comp()
    )

  }

It's here http://github.com/jhegedus42/irie/blob/ba128daf4c24e61b155ab2ca28b7164c17dae3e1/modules/client/src/main/scala/app/client/ui/components/mainPages/userHandling/userList/UserListComp.scala#L35-L35

and it works.

I mean, it is possible to create "components", and mix Sodium with React.

React is good for doing VDOM diffing, Sodium is good for describing State handling.

I will use Sodium with React for prototyping. I don't want it to be super fast or anything...
but I refuse to use crap... and current State handling solutions for React are crap.

Sodium starts to give me a bit of hope that I don't have to put up with React's crappy state
handling "revolutions".

I think I am an early adopter in things... but there are two ways how people's attitude towards
FRP can change:

1) some people will keep using crap and will be happy with doing crap for the rest of the life

2) some people will see that there are some other people who are not using crap
and they will become jealous and angry and that will drive them to learn to use FRP.

I cannot tell how much people like / hate doing crap. I hate it a lot, so a go a long way to
avoid it.

I don't think I am the only one...

Anyway... let's see how far I get with my SPA project ... but the lack of compositionality in React
makes React a huge pain to use... which I will not accept.

I have a feeling that Sodium will save me from this pain.

Long rant... but the code works and runs.

It looks like this after I pressed the button :

So, I would say, thanks @the-real-blackh , Sodium might just save me from pain.

I can write 3 lines of code, instead of 50 to do something simple.

I can write 20 lines of code to do something more complex instead of 2000.

Anyway... time will tell, and I am not the only one who is hating React, one solution
seems to be Sodium, in Scala.js.

Which I start to explore at this very moment, and it seems to work...

I need to write some wrapper code for the Sodium components, like this :

  case class ReRenderTriggerer(f: Option[() => Unit]) {

    def trigger(): Unit = {
      if (f.isDefined) {
        val r: () => Unit = f.get
        r()
      }
    }
  }

  case class SodiumLabel(val c: Cell[String]) {

    def sampledValue = c.sample()

    var state = "initial_state"

    var stateSetter: ReRenderTriggerer = ReRenderTriggerer(None)

    val f = c.listen(x => {
      println(s"sodum label's cell is $x");
      state = x
      stateSetter.trigger()
    })


    val comp = ScalaComponent
      .builder[Unit]("SodiumLabel")
      .initialState("label")
      .renderBackend[Backend]
      .componentWillMount(f => {
        val g = () => f.setState("bla").runNow()
        Callback {
          val s = ReRenderTriggerer(Some(g))
          stateSetter = s
        }
      })
      .build

    class Backend($ : BackendScope[Unit, String]) {
      def render(s: String) = {
        <.div(
          state
        )
      }
    }
  }

and then, hopefully, I can figure out how to use Sodium to get rid of the pain, even this simple example :

object FRP {
    val sbutton = SodiumWidgets.SodiumButtom()

    val cell: Cell[String] =
      sbutton.sClickedSink.map(x => "bello").hold("hello")

    val label: SodiumWidgets.SodiumLabel =SodiumWidgets.SodiumLabel(cell)

    val vdom= <.div(
      sbutton.getVDOM(),
      <.br,
      label.comp()
    )

  }

is so disgusting when one writes it in React that I simply don't understand why FRP has not yet
taken over React.

Anyway, so far, it looks good to me and I don't want to suffer if I don't have to.

Bottom line, thanks for writing the Book, @the-real-blackh, and the code, Sodium.

Suffering and hate will drive people to learn how to use Sodium - it's the simplest and
cleanest way to actually learn/understand/put FRP into real world production use.

Sodium is simple, pure FRP. There is actually no other choice. No book that actually
teaches FRP and gives a library to use it in production.

Suffering will drive people to FRP, and the book will make it possible for them to actually
learn FRP and Sodium lib will make it possible for them to actually use FRP.

I think it will happen because pain is a strong driving force. It drove me to start to use
Sodium in a React project... to take out the painful part from React.. and it does not take
much to combine Sodium with React, apparently.

This is what I will explore now, because React on its own is a huge pain. I think Sodium
will help there. Other solutions like redux cause me reflux, so maybe in my next life.

Anyway... enough ranting... pain of React drove me this far... and Sodium seems to be working
with React ... so... I don't think I will go back to event handler stupidness.

Cheers,

Jozsef