Data viz for regular horses. I’m not a designer. I’m a JavaScript developer. When I write CSS it takes me longer than it should, and often ends with someone more talented indulgently explaining how I could have avoided making such a mess of things. So, while I can literally do the thing, I can’t claim to have design chops. I’m sure there are designers reading this post who feel similarly about writing JS. Of course there are those scarce and sought after few who feel equally comfortable with design and code, but most of us are not unicorns.
Most of us are just regular horses, and that’s mostly just fine. We specialize, we collaborate with people whose skills compliment our own, and everything runs smoothly. Until we try to write some data viz. Visualizing data effectively requires an extremely precise and dynamic relationship between data and visual representation. When logic and styling don’t work together seamlessly, the resulting visualization are often ugly or worse- misleading! This tight coupling of concerns can make collaboration problematic. Until recently, my data viz projects almost always involved [d3](https://d3js.org/). The resulting workflow had me context switching between JS, CSS, and d3’s terse api, and slowed me down quite a bit. Whenever I had to make changes to some visualization I’d worked on, I needed to load all that context back into my brain. That meant reminding myself of d3’s oddities, and getting back into my shallow, somewhat bumbling CSS groove. Then all of my colleagues started using React, and JSX, and inline styles, and I got to load up a bunch of new context! I won’t pretend like getting started with a whole new set of tools wasn’t difficult and a little demoralizing, but as I got more comfortable, I found I really liked it. Since I was writing in JSX, and using [Radium](https://github.com/FormidableLabs/radium) for inline styles, I no longer had to switch between several files to work on a single feature. Instead, I could write a feature as an independent, self-contained component, with all the logic and style information it needed, and nothing more. This pattern was great for my everyday workflow, and it sounded ideal for data viz projects. Unfortunately, using d3 and React together turned out to be… less than ideal. The two technologies interact with the DOM in wildly different, and incompatible ways. There are several clever hacks to make the two play nicely together, but knowing when, and how to employ these tricks is not a trivial task. After trying to fit square pegs into round holes for a while, we decided to write our own data viz components especially for React. Once we got started, we realized we wanted to do a lot more than just wrap d3. So we started writing a library called Victory. Victory is an ecosystem of composable data viz components for React. It relies on d3 for its powerful underlying math, Radium for inline style management, and React for most everything else. We thought a lot about how to create an intuitive, flexible API, and I’d like to think it really shows. If you don’t want to take my word for it (and you shouldn’t, I’m incredibly biased), you can play with Victory components here in our [interactive docs](https://formidable.com/open-source/victory/). Or check out this video where I explain in more detail how the pain points in our old workflow motivated us to build Victory, and show off some examples of Victory in action. Code: [https://github.com/FormidableLabs/victory\](https://github.com/FormidableLabs/victory) Thanks to Alex Lande, Per Nilsson, and Eric Baer.
