especially composed components like chart with animating children

Would be nice to have an abstract format and an example for each.

1. What is this?
2. Why should I use it?
3. How do I use it?

update current boilerplate to incorporate new react decisions
https://github.com/FormidableLabs/formidable-react-component-boilerplate

replace as many lodash methods as we can with es5 / es6 methods
rely on methods we cant replace (like _.merge) individually with https://www.npmjs.com/browse/keyword/lodash-modularized?offset=0

July 30 - 31

• victory-chart
• victory-axis
• victory-bar
• victory-scatter
• victory-line
• victory-pie
• victory-label
• main victory repo

Since the static build step has proved finicky, we should automatically check it as part of every PR.

Ross has been working on this component, and will probably continue. I'm assigning it to myself since he has le full time other job.

Begin testing components now that the api is more settled

Currently we are conflating / enforcing the convention of the independent variable being represented in the x-coordinate space, and the dependent variable in y coordinate space. This assumption breaks down for things like horizontal bar graphs. How should this relationship be configured? Does this change our x / y data format?

create a radium boilerplate repo. Update generator to include a radium option

Maybe modify this:
https://github.com/kangax/fabric.js/blob/master/src/parser.js

svg performance is a problem with a large number of nodes. Giving a canvas option would help. Canvas option might also facilitate server-side rendering.

Should include tasks related to docs and static page builds

example

style={{
  data: {
    fill: (x, y) => x < 50  && y < 10 ? "blue" : "red"
  }
}}

Chart is too monolithic. Styles applied to child components are especially problematic. Make the child-parent relationship explicit by giving the user direct compositional control over the children i.e.

<VictoryChart props...>
  <VictoryAxis props... /> // optional, chart has a default
  <VictoryAxis props... /> // optional, chart has a default
  <VictoryLine props... />
</VictoryChart>

Here chart just acts as a coordinator between child components, synching up the domain / range / tickValues etc. based on the data and other props of the children

as requested by @eastridge

• file structure
• boilerplate
• docs boilerplate

Depends on FormidableLabs/builder#7 and #49

• animation model
• design philosophy
• advantages
• comonetization
• DOM model
• component lifecycle

Context, default styling, override with props... we need a tight system for how all of those merges and overrides are going to work.

So I think perhaps maybe I would like to be involved in this project. But I think maybe also that I don't know SH about D3's nuts and bolts.

Perhaps someone can hold my hand as I ask some silly questions and pose some silly prollems.

One thing I think I know about what makes D3 special is that it is meticulously designed to deal with a ton of interlinking data and any associations that come along with it, and what I have heard on the street is they utilize the DOM to accomplish this with amazing efficiency. This is said to be achieved because the DOM is structurally perfectly suited for this task.

That said, I intuit that the nature of deeply nested data structures that the DOM is so suited for, can be replaced with a plain old JS built data structure that models the desired DOM behaviors without all the cruft that comes along with it.

As I understand it, the above mentioned model has already been implemented in what is called the "Virtual DOM" which react employs in order to accomplish the very same goal. Do we (you) already know for fact that the VDOM encompasses everything necessary to implement D3's DOM dependent functionality? I assume so...

1.) If this is so, how difficult would it be to adapt D3's infrastructure to utilize the VDOM in the same way it would the DOM? I assume (probably incorrectly) that this wouldn't be such a big deal per se.

2.) I assume from the bits I read in DESIGN.MD that this project intends to keep SVG as the core rendering technology. If so, does SVG not also utilize the DOM, which would make cutting the DOM out an impossibility?

Perhaps I misunderstood and SVG is not the intended rendering tech for this proj. Please clarify this point so I don't continue down a train of thought which is misguided (and useless to all).

I would be very intrigued by a project that cuts out the DOM and is render agnostic. Leaving the option open for those who need/want to use SVG.

3.) Do most browsers utilize hardware acceleration in the SVG render chain?

Of the ~25,000 or so projects I have reviewed over the past couple years, I have not run into many as capable or performant as D3. I actually only recall one project that seemed to encompass the core of what D3 accomplishes, and if I recall correctly it was render agnostic and modular. I can't seem to remember the name of it at the moment, but I will hunt it down and get back to you on that. It seemed very robust, and the rendering was definitely much higher in performance than what I have experienced with similar D3 charts. The author of this charting library was a very young (early 20's) MIT student (I think) - he had a definite focus on performance and provided a detailed benchmark comparison of all the top charting libs providing similar functionality.

It should:

• check for version updates to the package.json either with something like npm-check-updates or by matching to the top-level victory repo package.json
• bump and commit each component version, and publish the new version to the npm registry
• top level victory repo should depend on other victory components at "latest"
• run from one place and update all the components

definitely include:
axis
scatter
line
area
legend (http://d3-legend.susielu.com/)
bar chart / histogram / box plot

others (maybe 2nd milestone):
pie / donut
tree
chord

capstone:
cool visualization of formidable labs github data
component playground of every component

as stand alone npm modules in their own repos.

tried to send a quick pull request to fix this but didn't let me.

in ecology with playgrounds

components will have default styling with radium
ask Paula or Angela to create a style guide

This is in support of the lander launch.

Generate ecology component with links to subcomponents at projects.formidablelabs.com/victory-*

http://www.highcharts.com/demo
http://www.datavizcatalogue.com/
https://www.rstudio.com/wp-content/uploads/2015/03/ggplot2-cheatsheet.pdf

• consider rescaling svg when gets to certain size
• either the visualization should resize or stay the same with scroll / drag / panning

should contain:

• list of components
• links to what we have
• rough status
• what is planned

format, code style, api compliance, visual style, documentation, npm module, concurrent PR into component playground source

make sure there is a tag for every version