react flow

[Paul Tarvydas]

https://reactflow.dev/

[Raoul Duke]

nice!

On Mon, Apr 19, 2021 at 9:06 AM Paul Tarvydas <paulta...@gmail.com> wrote:
>
> https://reactflow.dev/
>
> --
> You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/841b720d-375f-419d-9bc0-b4e77b0ec582n%40googlegroups.com.

[ern0]

Wow, it's impressing.

It's been a while I posted to this list, just a quick reminder: with a
friend, I've written a dataflow system for home automation purposes,
prototype-hobby state. Also I've made a concept for GUI:
http://linkbroker.hu/ihome/editor/
I code C/C++ for embedded devices for food.

A friend of mine is writing a DAW-like application, for browsers, in
JavaScipt, I was surprised, it's not a toy, it's working (not yet
released, I can't show you). He made a dataflow system, routing one
audio module to another, and I started thinking on the GUI he made:
the modules are stacked, which means connection, the upper one sends
stuff to lower one. Also, there're multiple columns, and modules in
different columns can be connected somehow.

My problem is: even best box-like UI seems uncomfortable, beyond a complexity.

Do we have better representations of this kind of graph?

--
ern0
dataflow evangelist

[Raoul Duke]

personally i don't thing there is any single "rendering" of the
underlying program that is the Best Right Answer. i think the entire
programming experience needs to offer multimedia interaction. of
course personally i also think everything should support
commandline+emacs+makefile as the fallback, i don't like it if some
language cannot be used at all w/out its gui.

https://baychi.org/bof/future/20030325c/
(vaporware)

[Paul Morrison]

Hi guys!  How does react.js differ from NoFlo and/or NodeRED?

Thanks,

Paul M.

[daudi mungah]

Paul 

React.js is a "frontend" end framework used in building spa(basically HTML in JavaScript) , noflo is a flow based framework for nodejs that has both an editor and a runtime while nodered is a flow based editor that involves making flows mostly used in IOT.

Usecases 

1)want to build a good website with great user experience use reactjs 

2)want to use fbp style building a website still using reactjs use noflo browser runtime and add reactjs as "frontend" framework

3)want to send data from an Arduino device to backend use nodered 

--

You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/b0d7b779-6ab3-40b4-8b93-576411db23e7n%40googlegroups.com.

[Paul Morrison]

Thanks!  I was a bit confused as Matt Carkci has a book out called " Dataflow and Reactive Programming Systems "...

Have you looked at https://github.com/jpaulm/javafbp-websockets ?  It uses Java-WebSocket, indirectly... so a) is it a SPA?  and b) can React.js talk to WebSockets? 

BTW Currently it only works with Chrome, but I'm sure someone who understands security can get it working under Firefox again!

Thanks,

Paul

[Ged Byrne]

Hi Paul,

The flow within React is mostly hidden from the developer.   It is an alternative to the flow you describe in your chapter on online applications: Flow-Based Programming: On-Line Application Design (jpaulmorrison.com)

The user interaction is implemented using a single loop that applies content templates to the application data in order to render a DOM. 

The clever part is that it does not replace the current displayed DOM with the newly rendered one.  Instead it compares the two to generate a list of changes necessary to update the currently displayed DOM into the latest version of the rendered DOM.  The whole page does not need to be redrawn, just the parts that have changed.

User actions then update the Application Data, and the templates are once again applied to render a new DOM.  This gives us a flow graph that looks something like this:

However, React developers work on the templates and do not work with the rendering pipeline, although it is possible to customise it using middleware: Middlewares with react context and hooks - DEV Community

This pattern isn't unique to React, it's also used in TiddlyWiki and ELM.  

So this is the key difference between React and FBP.  React is a defined pipeline that supports component development.  FBP provides a framework for defining flow graphs.  A pipeline is limited for of Flow Graph with all components having the same ports ( usually something like IN, OUT and ERR ).

Regards, 

Ged

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/ec838070-2b7f-48d0-8b7d-dc35f58b8a01n%40googlegroups.com.

[Paul Morrison]

Hi Ged, nice to hear from you!  I guess my understanding of the DOM isn't good enough, but this looks like an FBP diagram - in fact the diagram looks a lot like the diagram in https://github.com/jpaulm/javafbp-websockets/blob/master/README.md (near the bottom)...  except that your diagram has the compare and "apply updates" loop in addition.  I can see how that would be more efficient than redrawing the whole screen - if I understood correctly.

OTOH the script files in my JavaFBP-WebSockets example have the advantage of being fairly understandable, e.g. https://github.com/jpaulm/javafbp-websockets/blob/master/src/main/resources/scripts/chat1.html , esp. the onmessage function, but I assume react.js has to access a lower level API, so maybe a bit more complex to specify...?  

Regards,

Paul

[Ged Byrne]

Hi Paul,

The diagram was deliberately made to show an FBP style flow.  The real thing is more complex, as shown in this diagram:

This diagram is taken from this tutorial, which is a good explanation of the React internals: React Components Lifecycle | Props and States in React | Edureka

There has been talk about what a client FBP framework will look like, and I think React is nearly there.  The way it does components is very powerful but the rendering pipeline, which the developer can hook into using hooks, is rather obscure.  If the flow graph was made explicit so that developers could then add their own stages it would be very powerful.

I don't think adding FBP to REACT would work, because it is built from the ground up on Functional principles.  It would be interesting to consider what a similar component framework would look like if built in jsFBP.

Regards, 

Ged

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/33cca607-6a43-47b7-8c7b-46090baa4e23n%40googlegroups.com.

[Paul Morrison]

You're right, that's pretty complex!  Based on what you said before, I would expect to see a compare function... unless the orange blobs represent this...?

As I tried to suggest in my previous post, the scripts in https://github.com/jpaulm/javafbp-websockets/tree/master/src/main/resources/scripts basically create html, which is then passed to the browser's html parser.  React must interact with the browser at a lower level...?

I am also keen on getting rid of the JavaScript - WASM looks promising!    Anyone working on that out there?!

Cheers,

Paul

 

[Ged Byrne]

Hi Paul,

I think the scripts for web-sockets is a good starting point.

The question is what would a component framework for HTML look like?  The page is described as a tree of components each of which is rendered to produce html.  The basic format is:

IN: ESX Template, Javascript code, Data
OUT: HTML Fragment

The root calls it's branches so that they can render themselves.

Where your code renders the HTML page REACT renders a VDOM and it then compares to see what components have actually changed.  Only those components then render HTML.

It doesn't use any lower level feature, it just wraps every component in a DIV and updates the DIV's InnerHTML.

WASM is looking very promising, especially now that threading is being added: WebAssembly Threads ready to try in Chrome 70  |  Google Developers

I say it's best to wait a little while for the threading model to be standardised.

Regards, 

Ged

--

You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/5f4dc607-7ca1-499a-8e0f-a6fcb5be56dcn%40googlegroups.com.

[paul tarvydas]

Can FBP components share mutable data between them?

pt

 

On May 14, 2021, at 6:32 AM, Ged Byrne <ged....@gmail.com> wrote:

Hi Paul,

I think the scripts for web-sockets is a good starting point.

The question is what would a component framework for HTML look like?  The page is described as a tree of components each of which is rendered to produce html.  The basic format is:

IN: ESX Template, Javascript code, Data
OUT: HTML Fragment

The root calls it's branches so that they can render themselves.

Where your code renders the HTML page REACT renders a VDOM and it then compares to see what components have actually changed.  Only those components then render HTML.

It doesn't use any lower level feature, it just wraps every component in a DIV and updates the DIV's InnerHTML.

I say it's best to wait a little while for the threading model to be standardised.

Regards, 

Ged

On Tue, 11 May 2021 at 15:50, Paul Morrison <paul.m...@rogers.com> wrote:

You're right, that's pretty complex!  Based on what you said before, I would expect to see a compare function... unless the orange blobs represent this...?

As I tried to suggest in my previous post, the scripts in https://github.com/jpaulm/javafbp-websockets/tree/master/src/main/resources/scripts basically create html, which is then passed to the browser's html parser.  React must interact with the browser at a lower level...?

I am also keen on getting rid of the JavaScript - WASM looks promising!    Anyone working on that out there?!

Cheers,

Paul

 

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/5f4dc607-7ca1-499a-8e0f-a6fcb5be56dcn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/CACtVJg9L%2BtC6Y8X1QKqQReYWxSU%2B3opOjCUbYx_X_12DKMsBkw%40mail.gmail.com.

[Ged Byrne]

Hi Paul,

Good question.

Let's consider how this works in React. 

The Components themselves will be IPs.  The data would be held in two IPs: Properties and State.

Within React these IPs are passed as parameters to the functions.

Here...

and here:

Within FBP we could receive the state, update it and then send it.  The IP is mutable.

In React we cannot change the state, it has to be replaced with a new instance.  The IP is immutable.

ONe big advantage to this for React is that it allows time travel: https://reactjs.org/tutorial/tutorial.html#adding-time-travel

Regards, 

Ged

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/4C4CF177-D315-4244-A7B4-D52B552B7E64%40gmail.com.

[paul tarvydas]

From WebAssembly Threads ready to try in Chrome 70  |  Google Developers

“… Browsers have supported parallelism via Web Workers since 2012 in Chrome 4; in fact it's normal to hear terms like 'on the main thread' etc. However, Web Workers do not share mutable data between them, instead relying on message-passing for communication. …”

What does the phrase “share mutable data between them” mean?

pt

On May 14, 2021, at 8:10 AM, Ged Byrne <ged....@gmail.com> wrote:

Hi Paul,

Good question.

Let's consider how this works in React. 

The Components themselves will be IPs.  The data would be held in two IPs: Properties and State.

Within React these IPs are passed as parameters to the functions.

Here...

<image.png>

and here:

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/CACtVJg_87X3Ge5NzxZAj0HLFbtnPk6CBq%2Bs1mdFMu%2BG_1Wz0Vw%40mail.gmail.com.

[Ged Byrne]

Hi Paul,

Mutable state means state that can be changed.  Immutable state cannot be changed. If we have Components C1 and C2 and all state is immutable then that means that the two components can only create and read data.  If you want different data then you need to create something new. 

Shared mutable state means that the data can also be changed or deleted.  With mutable state both C1 and C2 can make changes or delete the data.  This introduces problems like C2 deletes the data and then C1 tries to use it. 

Web workers have mutable state that can be altered and deleted but it cannot be shared.  The components can only communicate by sending each other messages. 

FBP has synchronised mutable state.   Both C1 and C2 can change the data, but not at the same time.  The ownership of the object has be transferred first. 

Regards,

Ged

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/8FCDC7C6-44F9-442C-ADC2-5267F9FB7F44%40gmail.com.

[Paul Morrison]

Interesting discussion, and thanks for the feedback on react, Ged! 

Question for Paul T.: how does Alex Kelley fit in with this discussion?   I couldn't find him in the conversation...

I assume someone talks about "sharing mutable data" - of course, this is very dangerous given full asynchronism,  but probably manageable to some extent with the more synchonous, "FBP-like" approaches...

Cheers,

Paul M.

[Paul Tarvydas]

> 

> On May 11, 2021, at 10:50 AM, Paul Morrison ... wrote:

...

> I am also keen on getting rid of the JavaScript - WASM looks promising!    Anyone working on that out there?!

I built a small pseudo-code-to-wasm transpiler using Ohm-JS and my own tool (called 'glue').

If you are looking to code WASM (WAT) directly, then I might be able to help, since I've jumped through the hoops, and I ain't no stranger to lisp-like syntax.  I probably can't help if you want to use wasm from an existing language (I don't see the point).

pt

ps. https://guitarvydas.github.io/2021/05/15/WASM-Arithmetic-Transpiler.html

[Niclas Hedhman]

On Tue, May 11, 2021 at 4:50 PM Paul Morrison <paul.m...@rogers.com> wrote:

I am also keen on getting rid of the JavaScript - WASM looks promising!    Anyone working on that out there?!

I did a test in 2018 with a small Rust program, to see how large the minimum program would become; ~180kB IIRC.

There is a very good reason to look at Rust when it comes to WASM, in one word; Mozilla. They are heavily involved in both.

But one can use C++ for that matter. The crypto/blockchain of EOS (https://github.com/EOSIO) uses WASM as the on-chain language and runtime, and blockchain contracts are written in C++ and compiled to WASM. Those WASM executables are really small foot print (memory is VERY valuable on EOS). For those who don't know, EOS produces two blocks per second and has piqued at 7840 transactions per second.

Cheers

Niclas

[Ged Byrne]

Hi Niclas,

Rust compiles to WASM?

That's interesting because there is an FBP implementation in Rust which was created by Stewart Mackenzie.

The RustFBP crate is here: https://lib.rs/crates/rustfbp

The source code can be found here, a module within the Fractalide project: https://github.com/fractalide/fractalide/tree/master/modules/rs/rustfbp

I'm not sure if Stewart is still on this group.  Fractalide is still showing as coming soon and the last pull request was in 2019.

There is also a video from FOSDEM 2019 where Claes Wallin delivers a talk with the title: Fractalide and Cantor A Racket application built with Flow-Based Programming:

Here's a slide from that presentation:

Could RustFBP provide the foundation for a general purpose FBP framework for FBP, with JS interop allowing the definition of JS components? https://www.youtube.com/watch?v=mqP1z7FaSQs

Regards, 

Ged

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/CADmm%2BKeKn%2B4ddqyMzaqd5MgjiAtyj7hsNmr007E6MiH4bFhgGA%40mail.gmail.com.

[Ged Byrne]

Sorry accidental Alt-Enter sent that message mid edit.  Here is the correct version.

Hi Niclas,

Rust compiles to WASM?

That's interesting because there is an FBP implementation in Rust which was created by Stewart Mackenzie.

The RustFBP crate is here: https://lib.rs/crates/rustfbp

The source code can be found here, a module within the Fractalide project: https://github.com/fractalide/fractalide/tree/master/modules/rs/rustfbp

I'm not sure if Stewart is still on this group.  Fractalide is still showing as coming soon and the last pull request was in 2019.

There is also a video from FOSDEM 2019 where Claes Wallin delivers a talk with the title: Fractalide and Cantor A Racket application built with Flow-Based Programming: https://www.youtube.com/watch?v=mqP1z7FaSQs

Here's a slide from that presentation:

 

Could RustFBP provide the foundation for a general purpose multi-threaded FBP framework for FBP, with JS interop allowing the definition of JS components?

I can see FBP and Rust being excellent complements.  Rust is great, but it's uncompromising approach to safety and tight resource management can drag down productivity.  Definining safe, tight components in Rust to be composed using as FBP IDE for high velocity delivery looks to be an ideal partnership, especially if you can then deploy to both the server and the browser.

Regards, 

Ged

[Paul Morrison]

Hi Ged,  I agree - this looks pretty exciting - I look forward to watching the video!  I had heard of Fractalide, but know nothing about it... it predates Rust, though, doesn't it?!

Cheer,

Paul

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/CACtVJg9UWELRswFRJfW04aHZAVsQsDOfpWAKDmfs9PMVmf8qTA%40mail.gmail.com.

[Niclas Hedhman]

Ged,

I compiled Rust and tested for deployment on EOS blockchain (pre-launch) in 2018 and got that working (but not feasible because min 200kB will be too costly).

But a quick search; https://rustwasm.github.io/book/ and I am sure there are a lot more information out there.

Niclas

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/CACtVJg9UWELRswFRJfW04aHZAVsQsDOfpWAKDmfs9PMVmf8qTA%40mail.gmail.com.

[Paul Morrison]

More reactions to Ged's remark, where he said,

"I can see FBP and Rust being excellent complements.  Rust is great, but it's uncompromising approach to safety and tight resource management can drag down productivity.  Defining safe, tight components in Rust to be composed using as FBP IDE for high velocity delivery looks to be an ideal partnership,"

I'm afraid my initial enthusiasm has waned - I am just about ready to give up on Rust for the FBP environment!  I wouldn't have come to this conclusion if I hadn't tried to get something working...

I have spent (wasted?) the last week trying to get a simple FBP proof of concept going in Rust - I know someone else has put a similar idea up on GitHub, called RustFBP, but I prefer to implement my own!  My attempt still does not compile, so I can't even begin testing! FYI, the URL is https://github.com/jpaulm/rust-test/blob/master/src/main.rs .

A nice chap in Germany has modified my code so that it does run, but he is cloning connections (and maybe also closures?), which IMHO doesn't make much sense, and seems unnecessary,  just to get around Rust's paranoia (!), so I am trying to use pointers, which feel more in keeping with real FBP... !   This in turn seems to lead to a lot of weird "lifetime" stuff...  Getting some simple code working shouldn't be this hard!

Andrew Cherry on the Slack group made some changes earlier, which worked and which I have kept - thnaks Andrew! - but I needed more function, hence my current situation...  I would like to move on, but can't get past this point!  Help!

I also need a mechanism for storing individual components in separate source files ("crates"?) - I can't even start that until I get the present version running...

Preliminary reactions:

a) my code is a dog's breakfast (with apologies to dogs) -  a lot of the declarative stuff is unnecessarily repeated - at any rate, when I leave it out, the test ('cargo run') tells me to put it back!  Why could Rust not just use a simple system of declaring variables, and then using them without having to repeat all the declarative info?

b) I don't like not being able to look at a variable and see what type it is - Rust claims to be type-safe, so why not just write in the types, instead of having it be deduced?!

c) all this "lifetime" garbage - FBP has a nice clear lifetime concept, so there should be a way in Rust to say "trust me - I know what I'm doing"!  Instead I get the impression that the Rust folks think they're smarter than anyone else!  However, apparently they are not familiar with FBP, so FBP and Rust are very much working at cross-purposes!  This won't be the first time that I've experienced this feeling of frustration!  By comparison, when something works well with FBP, it feel great!  :-)

d) There doesn't seem an easy equivalent of Java 'null' - that's weird!  That should be in all languages!

e) The only tool I've found that gives half-way useful diagnostics is 'cargo run', but it gives too many, and often its recommendations don't work when I try them out!  Basically, same problem as before - it doesn't understand FBP, and doesn't understand why one might want to pass IPs from one process to another via connections!

e.g. thread::spawn(move || {
    |         ^^^^^^^^^^^^^ `(dyn FnMut() -> bool + 'static)` cannot be shared between threads safely

what the h*** does that even mean?  I never said I wanted to share it...

So, if any of you are FBP and Rust enthusiasts, and feel they can work together, please take a look at my chunk of code, and tell me how to get things rolling again!  There are probably tools that would help, but so far I have not run across them!

Thanks in advance, and

<End of rant!>

[Paul Morrison]

Oh, forgot to mention this mutability nonsense!  I know some people like immutability in FBP, but you don't have to mention it on every construct!  It's almost as if Rust is stuck in a pre-FBP world, where you had huge, monolithic programs!  FBP on the other hand has a very simple storage utilization model - virtually zero globals, and all data is either in method-local working storage, or in IPs.  That's it!  Code of course is read-only - so why do you have say whether functions are mutable or not...?  If FnMut means something different, then that's totally misleading!  :-(

[Ged Byrne]

Hi Paul,

I feel your pain because I’ve found Rust to be difficult to learn as well.  

I really hope some Rust experts are able to help. 

Regards,

Ged

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/6774521d-51ae-4105-ba32-d56bcf25fd97n%40googlegroups.com.

[Paul Morrison]

Thanks, Ged!  I'll give that wish a thumbs-up!

Cheers,

Paul

[Paul Tarvydas]

My rules of thumb for implementing languages:

There are 2 types of languages:

1. human readable / human writable

2. machine readable / machine writable.

It is very painful to write a language compiler/interpreter AND target a human writable language (declaration-before-use, funky formatting conventions, etc., etc.).

It is MUCH easier to write a language compiler/interpreter AND target a machine writable language.

I can think of only several machine-writable languages:

1. Assembler

2. Bash

3. Common Lisp

JavaScript comes close, but someone chose to give it syntax (e.g. pesky "return