19 comments

[ 2.7 ms ] story [ 44.0 ms ] thread
This is great, and I was just now preparing to sit down to slog through implementing something like along these lines. You just saved me a lot of time.
I'm in a similar position -- This is great, nice work! Looking forward to experimenting with the library.

There are a lot of similarly great React libraries that focus on just one high-level component. A few of my favorites that have saved me tons of time:

- react-grid-layout (https://github.com/STRML/react-grid-layout) for draggable / resizable grids with an easily-serializable layout.

- react-mosaic (https://github.com/nomcopter/react-mosaic) for tiling / movable window layouts.

- react-table (https://react-table.js.org/) for a very powerful, expandable table implementation.

Would this be appropriate to layer on top of a tornado app toN provide realtime insight into the event loop?
Can somebody explain to me how/what this tool is used for? I have an idea but im not quite sure
It's a library that could help you to build an UML editor or a node-based compositor for example.
You could build a WebAudio synth / node chain with this, it's much better than looking at code.

Or set up CI pipeline with this.

Or in cases when you want end users to set up flows, but they can't code.

I really like the idea that the library doesn't try to do automatic layout, and you need to specify a nodes X/Y coords.

There are a few similar libraries where their layout algorithm is super frustarting and its implementation's so hard coupled it's really hard to change or use your own.

There are few similar libraries. I think most feature reach is https://github.com/projectstorm/react-diagrams , but there is also https://github.com/DrummerHead/react-flow-diagram https://github.com/alibaba/GGEditor , actually I’ve found about 15 different js open source react and non-react editors for node-based UI. But unfortunately most of them is not very extensible. One of the reason is that the authors prefer to store state inside component, so it’s impossible to create non-trivial behaviour.
That's why we tried to make this library as simple as possible. It doesn't do any state updates besides the positions. You can easily store state inside nodes and change it as seen in the custom node example https://react-flow.netlify.app/custom-node
One thing that seems to be missing though is slot names.

For example if the nodes are objects in C++ and the edges are relations, you want to know the names of the members that point to the other nodes.

Labels on the edges would also be nice.

What sort of non-trivial behaviour would you be interested in?
For example: can I connect one port of node to other port of node and how this connection needs to be drawn.
I made a react-based visual tree demo a couple of weeks ago.

https://ldd.github.io/react-tech-tree/

It imitates a long X-Men family tree and slay the spire's room selection.

But this seems pretty cool, and a natural next-step to what I wanted to make.

This looks great but unfortunate naming means SEO will always compete against the flow type checking library even if you google "react-flow".