React w/ Sodium?

[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