Hey. I am the maintainer of React Flow. Thanks for the kind words here :) We built it as a foundation for our node-based data wrangling tool datablocks https://datablocks.pro/
Wow I really like it! Can you maybe break down some of the design decisions you've made building this? I'm especially interested in choosing full svg, svg for just the lines and the rest with divs or using canvas.
Also I see you depend on d3, where do you use it for?
I did a lot of data visualizations and I am big fan of d3. It's very robust software that works in all browsers. We are using d3-zoom for panning and zooming the pan but I am actually looking for an alternative to decrease the size of react flow. Maybe we will use this in the future https://github.com/anvaka/panzoom
I've been using this the last few weeks on a synthesizer side project and it's been absolutely fantastic. A well designed API and easy to customise, excellent docs and sane defaults. Bravo!
Does it support auto positioning like in MindMaps? e.g. everytime I hit `tab` I get sub node then I hit several times let's say I have 10 sub nodes now, auto positioned.
So cool to see these kinds of in my mind pretty advanced interactive interfaces become easily reusable modules to integrate with any kind of application.
This is a great library. We have used it for a workflow report tool for our in-house Machine Learning pipeline (https://voxelytics.com). Rendering a DAG with some interactivity works very well.
Looks awesome, have you thought about making it an actual React renderer (like react-three-fiber) instead of passing an array of elements to the component?
This is really, really impressive. Nice clear, and good looking examples, looks to have clear documentation, and nice informative README. I've been tossing some ideas around about using node-based editor flows for some of our work, will definitely be giving this a try.
Mortiz does some awesome stuff. I built a similar project called reaflow ( https://reaflow.dev/ ) which handles some more complicated cases around nesting and layout.
Super. Could you point me to an example how to use ports in react flow. I used some other library that had this implemented but it was a terrible experience.
Neat project, awful name. Overloading Flow, an already important part of the React ecosystem, just makes it harder to both find information about your project and find information about Flow.
Yes, there's an active albeit small community there.
I don't think I'd recommend it over TS for a new project by default, unless the person has some specific pain points with TS that Flow would fix. But Flow does still have some neat features - exact types, nominal types, explicit strict variance rules etc. - and performance benefits in large projects that could make one choose it over TS. And they have been streadily improving stuff like editor support, even though admittedly it's still a long long way behind TS.
Our team just migrated (3 mil+ LOC) from Flow to TS in large part due to performance issues with Flow, especially in local development. Our fans have been running a lot quieter since the migration, happy to share more.
Please do if it's not too much trouble. We have gone back and forth with this idea but never did make the jump.
A few random questions off of the top of my head...
Did you use a tool like flow-to-ts to help with some of the rewrites? What version of Flow were you using before? Did you take some special steps to get the TS perform well in the project or was it just better out of the box?
How's the experience been apart from the performance improvement - is there Flow features that you miss and have you done something to accommodate?
Namely, I'm personally a bit sad to loose local function parameter inference, exact types and explcit type assertion syntax.
I'm a bit afraid of bugs coming from excess properties or misspelled optional properties, or from the abuse of TS "as" keyword (which is not the same as Flow's `(foo: Foo)` assertion syntax).
> and performance benefits in large projects that could make one choose it over TS
[citation needed]
A medium size app using Flow would take 10 seconds to type check in an IDE. It's possible we had some issues with circular dependencies but Flow was such a burden to deal with. Not to mention issues where the flow server would chew CPU resources on a dev machine.
Typescript on a much much larger project has had zero issues with performance.
I don't have anything but own anecdotial evidence to provide. Would be cool if there were some good, recent benchmarks between the two, but I wasn't able to find any.
Maybe I've just configured something wrong, but I keep facing this issue where autocomplete stops to think suggestions and might just freeze the whole VSCode for a second. This is in a small project that has some fairly large library definition files (namely, aws-sdk).
If you search for "TypeScript performance", you'll find a bunch of issues and posts discussing the subject, so I don't think I'm totally alone in calling it out.
Granted, Flow gets it's share of similar search results and I have also experienced similar issues where a recheck sometimes takes long and CPU usage jumps very high. This side of Flow has been consistently improving between almost every release, though. Most recently, a couple months back, their switch to this new "types-first" architecture [1] is supposedly unlocking something like 50%-90% perf improvements compared to what they vere before.
My point with this isn't to question your experience with Flow, I've sometimes faced similar issues. I'm just saying that, depending on the Flow version you were using, things may have changed a lot for the better.
Just so that I'm not talking _completely_ out of my ass here, as a quick very unscientific test I cloned the Tutanota project's repo [2]. SCC says there's 967 JS files, consisting of 205433 lines of code in there. Flow version is 0.136, which is a little behind, but they are using the new types first mode.
time node_modules/.bin/flow check
Found 0 errors
node_modules/.bin/flow check 1,00s user 0,11s system 9% cpu 11,905 total
AFAICT at this point it's basically just Facebook projects (since they use it internally) and some older libraries that pre-date TypeScript popularity. I'm not sure there is much reason to choose Flow over TypeScript for a new project in 2021.
Yikes; alternate uses for _two_ already-overloaded terms ("flow" and "node") in the tagline? Naming things isn't _that_ hard. Less of a nitpick and more of a red flag wrt wisdom and experience of the lib's authors.
“Node-based interface” is common for that kind of UI though, the author didn't invent it. It's a shame that NodeJS chose such a common word as its name, but “node” can't be erased from CS just because NodeJS exists (one would have to remove graph theory, cluster grapes, many UIs concepts [tree UI, nodes UI, ...], many 3D jargon, etc.).
As a non-JavaScript developer, I'm curious as to where the "magic" (things that aren't intuitive to implement) is.
The algorithm for drawing an edge between nodes, for instance, doesn't seem magical (just a spline or beizer curve) - but only because the library doesn't care about routing edges around nodes. Layout isn't magical because you're doing it manually - unlike graphviz/xdot, for instance.
Does this library have magic, or is it, instead, the product of a lot of elbow-grease?
If it was the latter, I'm not going to complain - I'll take a pre-written library over doing it myself in a heartbeat - but, as I'm not a web developer, I wonder if I'm missing something, and it's interesting for me to taxonomize things.
