[HN Gopher] Show HN: React Flow - library for creating node base...
___________________________________________________________________
Show HN: React Flow - library for creating node based editors and
apps
Author : moklick
Score : 189 points
Date : 2021-04-19 08:46 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hpen wrote:
| Ah shit I just spent the weekend building a d3 node editor for my
| project... smh..
| tenaciousDaniel wrote:
| Never thought that animation would help the readability of
| sequence diagrams, but it totally makes sense. I love this.
| misnome wrote:
| 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.
| pdaddyo wrote:
| 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!
|
| https://dl.dropbox.com/s/kxlzlqypn0nz8bw/Screenshot%202021-0...
| tomduncalf wrote:
| This looks great, please share more if/when you can!
| moklick wrote:
| wow this looks really cool! Is it on Github?
| unixhero wrote:
| Bret Victor ought to be cheering here.
| ertucetin wrote:
| 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.
| moklick wrote:
| 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/
| robertlagrant wrote:
| That's cool. It's a little like Apache Airflow's UI.
|
| (Edit: is it Airflow?)
| victorbojica wrote:
| Looks cool. Looks similar to dynamo. https://dynamobim.org/
|
| I'm curious if that's your inspiration.
| technicolorwhat wrote:
| 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?
| erwinh wrote:
| 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.
| jcadam wrote:
| Nice. Wish I'd known about this months ago :)
| janaagaard wrote:
| Pretty amazing that https://reactflow.dev/examples/ works so well
| on phone.
| jfbaro wrote:
| Looks amazing! Any plans on supporting React Native (RNW)? I
| couldn't find any mention of React Native on the github page.
| emteycz wrote:
| If you're using React Native Web you can import and use this
| normally, though of course it will be web only.
| tracardi wrote:
| Does React flow support ports?
| moklick wrote:
| yes. We call them handles.
| tracardi wrote:
| 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.
| girriPal wrote:
| Been using this for a while and have found it a good fit. The
| documentation and examples are spot-on. One feature I wish it had
| would be the ability to more easily convert the flowchart to a
| png.
| robertlagrant wrote:
| Oh, wow. I remember when I was looking for something like this...
|
| ...last week. Hooray for HN!
| bradtheappguy wrote:
| I remember when I was looking for something like this... 2009.
| Oh well....
| normanrz wrote:
| 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.
| larzang wrote:
| 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.
| xavierlint wrote:
| > React Flow enables you to build node-based applications
|
| Also "node-based" doesn't mean the usual run-javascript-in-
| backend node, but the diagram nodes.
| chrisweekly wrote:
| 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.
| shakow wrote:
| > and "node"
|
| "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.).
| danlugo92 wrote:
| Let flow die already.
| sosuke wrote:
| React Pathfinder!
| jakelazaroff wrote:
| Is anyone even still using Flow? Almost every React project I
| see is in either vanilla JS or TypeScript.
| bpierre wrote:
| React is :) https://github.com/facebook/react/
| ybbond wrote:
| some company with overflowing features from products that
| needs to have typecheck but very limited in time, and/or
| already complicated repository(es).
|
| yes
| [deleted]
| TechBro8615 wrote:
| 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.
| inbx0 wrote:
| 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.
| qudat wrote:
| > 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.
| inbx0 wrote:
| > [citation needed]
|
| 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
|
| [1] https://medium.com/flow-type/types-first-a-scalable-
| new-arch...
|
| [2] https://github.com/tutao/tutanota
| adpirz wrote:
| 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.
| inbx0 wrote:
| 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).
| tekstar wrote:
| Perfect in at least 3 separate places for my current project, a
| multiplayer audio sequencing/synthesis environment. Thank you
| moklick wrote:
| Nice! Someone built a synth with React Flow:
| https://github.com/SubZtep/synth
| h1fra wrote:
| Amazing, I was just looking at a library like that, good timing
| fouric wrote:
| 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.
| moklick wrote:
| no magic involved ;)
| andretti1977 wrote:
| Beautiful library
| moklick wrote:
| thanks!
| [deleted]
| [deleted]
| allanmacgregor wrote:
| this is awesome and it has been a "blocker" on app I been wanting
| to build for a while
| pabe wrote:
| Does anyone know about something like this for Vue and Svelte? :)
| lf-non wrote:
| Butterfly [1] by alibaba has a vue wrapper (along with a React
| one) over a framework independent core.
|
| It is not as well documented though.
|
| [1] https://github.com/alibaba/butterfly
| leodriesch wrote:
| 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?
___________________________________________________________________
(page generated 2021-04-19 23:01 UTC)