React w/ Sodium?

[dakom]

By pushing all state changes to the react leafs, React will also update much more efficiently, because the Cells that are passed as props do not change, only their content changes.

I don't understand this - React must be aware of when the content changes in order to render. Therefore you have two options:

1. Override React's diffing to wait for the results of a listen() and then always pass on all the contents (I believe this is both messy and inefficient)

2. Pass on the Cell contents to the diffing - which is no different than having all the props spread out

Am I missing something?

By the way - if you're on the DOM then this is a great approach, lifting things up into higher order components or passing functions as children to the React-DOM renderer, but if you're not on the DOM, e.g. you're WebGL-based, you could get a little closer to the metal with a custom renderer

[Ziriax]

@dakom: That's why I lift all React components so that these convert each Cell in the React props to the "latest value" in the React state. This state is then passed as the props to the inner component.

I added a tiny library on github to bridge Sodium and FRP, plus a demo.

Both are work in progress, and I really should add some easy to use controls like checkbox, button, etc...

Nevertheless, it's a start. I never really used Sodium before, so I'm not sure if this is the "right" approach.

[dakom]

Nice, and clean code too

It's probably super fun to drive the React view via Sodium streams. Enjoy!

[dakom]

FYI - Dan Abramov (on the core React team) tweeted about an issue I opened on the react repo: https://twitter.com/dan_abramov/status/953281110062125058

Above and below that specific comment, there's lots of interesting discussion about React and animation and the JS event system

I find it interesting that in Sodium, you handle these things on the app side, for example by sampling different cells at different frequencies or whatever. You have more freedom (and responsibility!) to control the flow of what's async and what's not. Of course they're different approaches altogether, but it's food for thought.

Also - I'm having some success using Sodium for core app, and React for UI, and driving React with Sodium. This seems to be a really wonderful combo so far (though it's early)

One little gotcha is that setState is not async. So for example, listening to a stream, calling setState, and sending a stream in componentDidUpdate requires offsetting that send via setTimeout or whatever. Not a big deal, but worth mentioning. Even though it's a little bit ugly to do what amounts to a listen+send, it's really for a side-effect and I'm finding that to be preferable in this case, as opposed to making React organically part of the core FRP.

[jam40jeff]

@dakom As to your last comment about setState not being async...I have implemented something in a C# library (which I plan on eventually releasing publicly once I'm happy with it) which deals with this same issue generically. Basically, it provides a ListenAsync method (as well as a MapAsync method) for streams which under the hood simply runs the code with Transaction.Post. This would avoid the need for setTimeout in your case and IMO is technically "correct" since it ensures that things related to the transaction happen immediately after the transaction ends and before any other externally triggered transactions.

[Ziriax]

I don't think both are tightly coupled, the FRP circuit doesn't know anything about the React views. The views does require cells and sinks that are compatible as props, but that can be anything you want, it doesn't need to be the FRP circuit. So IMO view and circuit are decoupled in my library. Or at least, they should be

[Ziriax]

Are you sure setState is not async? I recall it actually was async, in the sense that after setState your state is not yet updated.

[jam40jeff]

@Ziriax Agreed...similarly to how in WPF INotifyPropertyChanged should be decoupled from FRP and "connectors" should be used to bridge the gap.

[dakom]

Are you sure setState is not async? I recall it actually was async, in the sense that after setState your state is not yet updated.

Yep - you get an error with sodium of you listen->setState->componentDidUpdate->send

Also see the comments at the end of that issue where Dan layed out the exact mechanics

[Ziriax]

Ah yes, I see, so setState is neither really async nor synchronous (since its effect doesn't take place immediately after calling it)

Very interesting discussion BTW, thanks for sharing that!

I don't think React and Sodium are a good fit anymore. I don't think one really needs a virtual DOM when using Sodium, since Sodium can be used to wire together all the components into view-model-cells that can mutate the DOM directly, efficiently, and incrementally when they change, maybe debounced with requestAnimationFrame, as you suggested. It's basically what Stephan does in his book, for Java widgets. What is nice about React IMHO is JSX, but that actually has nothing to do with React itself, it is just a shortcoming of Javascript that it doesn't allow nice compact syntax for building hierarchical documents, like XML.

[dakom]

What is nice about React IMHO is JSX, but that actually has nothing to do with React itself, it is just a shortcoming of Javascript that it doesn't allow nice compact syntax for building hierarchical documents, like XML.

I actually went on this whirlwind adventure where I used JSX to create custom vanilla objects so I can work with it like a hierarchy... I think I wrote about that somewhat here in a different thread, but some relevant code:

JSX tree: https://github.com/DriftJS/drift-example-state-scenegraph/blob/master/src/app/state/State.tsx#L25
Updating it with lenses: https://github.com/DriftJS/drift-example-state-scenegraph/blob/master/src/app/App-Main.ts
Crawling it: https://github.com/DriftJS/drift-utils/blob/master/src/lib/state/State-Tree-Mapper.ts#L45

Conclusion? Really cool technique for small apps and for the sake of learning - but I started building something bigger and it got weird (needing to store ephemeral indexes in the state tree, and needing to make lenses for everything and store those in the state, etc.)

Not saying it's exactly what you're talking about - just that I went pretty deep down a related rabbit hole along that direction

I don't think React and Sodium are a good fit anymore. I don't think one really needs a virtual DOM when using Sodium, since Sodium can be used to wire together all the components into view-model-cells that can mutate the DOM directly

I hear that. I think React offers some convenience and community-contributions that can be a timesaver, and the fact that they focus specifically on DOM stuff with ReactDOM is super efficient - but a clever sodium architecture can probably do everything React itself does in a dozen or so lines, and then it's all about the UI optimizations that can be adjusted more directly when you're focused on something specific.

I'm going to keep going with this approach of Sodium core + React UI, where they communicate via Sodium streams - but I'm not sure if that's the right approach for every project and I'll know more as I go down this road

[benkolera]

Hahaha. I just went down this rabbit hole for the purposes of a meetup talk and learning typescript sodium. I also came to the conclusion that it was a bad idea, but didn't quite know how to step forward without React or a core library of DOM building stuff like reflex has.

https://github.com/benkolera/salty-deadlands

[huanhulan]

It just occurs to me these days, I think since we have the business logic in the FRP graph, what we need is really only a renderer like:

Cell<A>->DOM

and of course getting the action from the user input:

Evt<domEvt>->Stream<A>

For the for first part, many solution get better chance than the React(or Vue2.0, any front-end framework using diff), for example: the lit-html, the reason for these IMHO, is just like you said in the presentation, in addition to the performance (like the question of If a tree falls in a forest if we ignore the lifecycle hooks of the React).

The real question is the second one, how to get the user input in a denotational way like JSX, which I can't answer, but I think the Incremental λ-Calculus could be a candidate for this.

[clinuxrulz]

If you find the right category you can write code that looks just like we are calculating everything each time declaratively. But under the hood its done incrementally. Just need to find the right category for it. This can be messy in typescript, but quite clean in Haskell.

I've been experimenting in typescript. And something I found is that sodium is actually already does incremental lambda calculus well, but it only does it for atomic types (without having to write a lot of code). It feels like we are so close, but just have to push a little further. (By atomic types I mean the value fully changes int, float rather than partly changes list, treemap.)

Without sodium here is the category I propose.

data IncF a b = IncF (a -> (b, IncF2 a b))
data IncF2 a b = IncF2 (Δa -> (Δb, IncF2 a b))

With sodium here is the category I propose.

data IncF a b = IncF (Cell a, Stream Δa) -> (Cell b, Stream Δb)

If all primitive functions are written in the given category, then using those in just FP style gives you incremental computation for free... well almost... Lots of primitives to rewrite.

[clinuxrulz]

As a matter of fact elmlang can do without a virtual dom. They can make a change to their compiler and zero change to your source code, and everything can be calculated incrementally. They'd just need to compile the lambda calculus to a suitable Cartesian category for incremental computational. Conal Elliott's paper on compiling to categories proves it can be done.

There is also a downside to incremental computation. You consume more ram from the extra caching. But this is more of a problem for incremental databases than incremental UI.

[clinuxrulz]

Concerning user input, the value you declaratively calculate for your event part of the dom properties just needs the type signature event -> Δmodel. When the event occurs the code will know how to update model. You'll be able to develope a single Stream Δmodel at the bottom, then feed in into the top (StreamLoop).

[clinuxrulz]

One last thing.
If we were only interested in atomic incremental values, then our incremental category becomes IncF a b = IncF (Cell a) -> (Cell b). This is the function pattern we hit all the time when using sodium. This means sodium itself on its own is great for incremental computational until collections get involved. After that the programmer needs to work harder.

[Ziriax]

Is this paper of interest?

https://limo.libis.be/primo-explore/fulldisplay?docid=LIRIAS1586071&context=L&vid=Lirias&search_scope=Lirias&tab=default_tab&lang=en_US&fromSitemap=1

I have been using Redux, React and Reselect for our recent single page apps, and I am not satisfied at all. Although it has its benefits, I feel I was more productive with ReactiveUI.

Normalized state gives you identifiers and lookup tables, and these give many of the problems you have with dangling C pointers... And it is very clumsy to work with, since the Redux state must be a simple JSON object, so has no prototype, forcing one to abandon encapsulation of state.

My main problem is efficiently converting normalized state into denormalized view models in such a way that the amount of updates in the view only depend on the number of changes done to the state. Reselect can help, but is akward to work with. I usually end up with custom WeakMaps for caching.

When using highly optimized immutable structures like a trie for the normalized state, I find it hard to map this to view models (aka props in React land) so that only those view models are updated that are dependent on the changed state... The naive way of doing this results in full re-renders, or at least full virtual dom comparisons... The optimized way of doing this resulted in brittle case specific code, loosing many of the advantages that functional programming brings.

I didn't have these issues with my Sodium - React experiments, since I already introduced splices to describe the changes done to a collection, and I directly wired Sodium cells to React internal state, but both of these approaches didn't feel general enough, React felt like overkill (I might try Lit-html with Typescript and Sodium), and only using patches (deltas) for collections felt to specific.

The paper I refers to seems to propose a more general incremental FRP system, with collections build on top of that.

But I don't understand the paper in full yet...

I just have the feeling that it must be possible to write web frontend code more efficiently and be more productive

A friend of mine finds all of this silly, he just wrote his own GPU accelerated renderer and draws the whole visible UI again for every change, because when something as complex as a modern video game can do this, surely a bunch of rectangles and text should be doable in 2019 no?

Maybe he has a point, it certainly would make live of a frontend developer soooo much easier

[clinuxrulz]

I wonder if this hacky combinator can help:

https://gist.github.com/clinuxrulz/90620be09cb7e367c302fe6b448a3c71#file-cell_arrayed_keyed-ts

Given a Cell<A[]> and a A->B, then it will give you a Cell<B[]>, but it will not recalculate any B if its corresponding A did not change. (The actual is not 100% as per that description as it also involves a key extract from A, but hopefully it provides the gist of it.)

Also MobX can offer some inspiration: https://mobx.js.org/getting-started.html

Its sort of a mixed RP/FRP exposed by annotations.

[jhegedus42]

I think I start to figure it out how to do it :

jhegedus42/irie/blob/ba128daf4c24e61b155ab2ca28b7164c17dae3e1/modules/client/src/main/scala/app/client/ui/components/mainPages/userHandling/userList/UserListComp.scala#L34-L34

  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 looks promising.