spotify / reactochart

:chart_with_upwards_trend: React chart component library :chart_with_downwards_trend:

Reactochart

Overview

Reactochart is a library of React components for creating data visualization charts and graphs. Components include line chart, bar chart, area chart, heat maps, scatterplot, histogram, pie chart, sankey diagram, and tree map.

Getting started

1. Install reactochart using npm.

npm i reactochart --save

2. Then you can import an individual Reactochart component:

import LineChart from 'reactochart/LineChart';

3. If you prefer, you can import all of Reactochart at once, though this may hinder some optimizations, such as webpack tree-shaking:

import { XYPlot, XAxis, YAxis, LineChart } from 'reactochart';

or

import * as Reactochart from 'reactochart';

4. Import reactochart's base styles

import 'reactochart/styles.css';

5. Build your first chart and see it rendered! For example, the following code snippet:

import XYPlot from 'reactochart/XYPlot';
import XAxis from 'reactochart/XAxis';
import YAxis from 'reactochart/YAxis';
import LineChart from 'reactochart/LineChart';
import 'reactochart/styles.css';

const MyFirstLineChart = props => (
  <XYPlot>
    <XAxis title="Phase" />
    <YAxis title="Intensity" />
    <LineChart
      data={Array(100)
        .fill()
        .map((e, i) => i + 1)}
      x={d => d}
      y={d => Math.sin(d * 0.1)}
    />
  </XYPlot>
);

results in this:

Live Examples

The examples contain more details about each component and the prop-types it accepts. To run the examples locally and play with the different types of charts in a live code editor:

1. Clone this repo and cd to the newly-created directory
2. Run npm run serve in your terminal (note: if you're running Python in v3 or higher you'll need to run python -m http.server)
3. Go to http://localhost:8000

Reactochart Components

Chart Foundations

XY Plot

• XYPlot

XY Axis Components

• XAxis, YAxis
• XAxisTitle, YAxisTitle
• XAxisLabels, YAxisLabels
• XTicks, YTicks
• XGrid, YGrid

Chart Types

Non-XY charts

• PieChart
• TreeMap
• SankeyDiagram

XY charts

• AreaBarChart
• AreaChart
• AreaHeatmap
• BarChart
• ColorHeatmap
• FunnelChart
• Histogram
• LineChart
• MarkerLineChart
• RangeBarChart
• ScatterPlot

XY datum components (used by charts/axes)

• Bar
• RangeRect
• XLine, YLine

Other

• ZoomContainer

Development

If you'd like to contribute to the development this project, first fork & clone this repo, and then follow these steps:

Global dependencies

• This project uses NPM to manage dependencies and run scripts. Run npm -v to check if you already have it installed. If you don't have it, NPM is packaged with Node.js - download and run the install package located on nodejs.org to install.
• Babel is used to transpile ES6+ code to ES5 syntax. Install by running npm install --global babel
• Webpack is used to bundle the JS & styles for the examples. Install by running npm install --global webpack

Project dependencies

• Run npm install in the project root directory. This will install all of the project dependencies into the node_modules directory.

Development process

• Run npm run dev to run the development server (webpack-dev-server), which will serve a live development version of the examples at localhost:9876.
• Make changes to the library code in the src directory, and/or changes to the examples in the examples/src directory.
• If you'd like to make changes or add further component documentation, follow the example on react-docgen.
• Once you're happy with your library and/or documentation changes, run npm run docs. This allows the documentation build to run with your updated src code. git add and git commit the updated build.
• git push to your forked version of the repo.
• Open a Github pull request with your changes against master. 🎉

NPM Link

If you have an app that depends on reactochart and you want to develop locally, follow the following steps:

1. In the folder for this repo, run npm build and then npm link
2. In your app folder, run npm link reactochart. If you're using webpack, then you also may need the following config:

{
  "resolve": {
    "symlinks": true,
    "alias": {
      "react": path.resolve("./node_modules/react"),
      "react-dom": path.resolve("./node_modules/react-dom")
    }
  }
}

Notes

• Do not make any changes in the lib or examples/build directories, as these directories are destroyed and regenerated on each build.
• The development server uses react-hot-loader to automatically "hot reload" changes to React components, so refreshing your web browser is not necessary.

Code of Conduct

This project adheres to the Open Code of Conduct. By participating, you are expected to honor this code.

reactochart's Issues

Proposed API changes for v0.4.x

I've picked up work on Reactochart again and am working towards a new release with more features & improved docs & tests. As a part of this release, there are some rough parts of the API that I'd like to propose changing. Please comment here if you have any thoughts or objections.

1. Rename all getThing ("getter") props to just thing; update them to accept either a constant value or accessor function (when possible).

Currently there are a number of special "getter" props which start with get (eg. getX/getY, getClassName) which tell the chart how to access a data value & determine a prop for each thing in a series (eg. a bunch of bars in a bar chart). However, many of these currently need two separate props - a "getter" prop for when the user wants it to be dynamic, and a regular prop if the user wants just a single static value. For example, BarChart has a getClass prop (a function which dynamically assigns a class to each bar), and a barClassName prop (a string className, which would be applied to all bars).

Instead, I propose that we combine them into a single prop, without get in the prop name. Such props would allow either a simple individual value to be passed, or (whenever possible) a function which would be called with each datum. Examples:

OLD: <BarChart getClass={(d) => d.name} /> OR <BarChart barClassName="my-bar" />
NEW: <BarChart barClassName={(d) => d.name} /> OR <BarChart barClassName="my-bar" />

The main advantages here are consistency, reducing the number of props, and allowing as many props as possible to take either static or dynamic (function) values.

Affected props: getX --> x, getY --> y, getClass --> className (or barClassName, etc.), getArea --> area, getValue --> value, etc.

2. Deprecate string/number/null shorthand for "getter" props.

Closely related to #1 above. Currently "getter" props like getX/getY accept functions, but they also accept a "shorthand" string/number which is transformed into a key/index accessor function. For example, if you render <BarChart getX={'foo'} />, this is internally turned into the function (d) => d.foo which is called on each datum to get the bar's X value. See the docs for more info on this behavior.

This can be convenient sometimes, but adds complexity to Reactochart code and requires a lot of explanation in the docs. More importantly, it conflicts with #1 above: If we deprecated getClass in favor of className but did not deprecate these shorthand accessors, something like <... className="foo" /> would become ambiguous - does it mean "use the string 'foo' for my className" or "use the function d => d.foo to determine className"? For this reason, we must do BOTH #1 and #2, or neither.

The only downside I see here is that users will probably replace a lot of their shorthand getX and getYs with arrow functions, eg.:

OLD: <BarChart getX={0} ... />
NEW: <BarChart x={(d) => x[0]} ... />
OLD: <BarChart getX="x" ... />
NEW: <BarChart x={(d) => d.x} ... />

This is fine for charts which aren't re-rendered, but can cause performance issues for those which are interactive or need to be re-rendered often - because by creating a new arrow function on each render, the user would cause oldProps.x !== newProps.x, causing the entire chart to re-render every time. The performant solution is for the user to create the accessor function once, outside of their render function, so that it ===s itself on every new render. This is definitely a bit less convenient, but is already an issue with any props which pass an arrow function, so React developers should already be familiar with it.

Affected props: x (getX), y (getY), and any other props which use shorthand string/number getters.

3. Deprecate combined thing={{x:..., y:...}} props in favor of separate xThing and yThing props

Currently there are several combined "X/Y" axis-related props that accept either an {x, y}-shaped object, or a single value to be applied to both X and Y axes. I want to replace these with separate xThing and yThing props, for example:

OLD: <BarChart domain={{x: xDomain, y: yDomain}} /> or <... domain={commonDomain} />
NEW: <BarChart xDomain={xDomain} yDomain={yDomain} />

The old way is potentially confusing (since there are two different behaviors) and it adds some unnecessary complexity in our components. Furthermore, it's problematic for PureComponent performance optimization: we expect that when a user re-renders a chart, any props which have not changed since the last render will === their old values. However, when users render charts using object literals, a new object literal is created on every render, so old props !== the new ones, making it harder to avoid unnecessary re-renders.

Affected props: domain --> xDomain/yDomain, scaleType --> xScaleType/yScaleType, nice --> xNice/yNice, invertScale --> invertXScale/invertYScale.

4. Deprecate combined thing={{top:..., bottom:..., left:..., right:...}} props in favor of separate thingTop, thingBottom, thingLeft, thingRight props.

Essentially the same thing as #3 except with top/bottom/left/right instead of x/y, & same rationale.

OLD: <XYPlot margin={{top: 12, right: 50}} ... />
NEW: <XYPlot marginTop={12} marginRight={50} ... />

If we wanted, we could still have a general margin prop that accepts a number that would be applied to all top/bottom/left/right, for more convenience when you want to pass the same number for all 4 values, but I'm not sure how common a use case that is.

Affected props: padding --> paddingTop/paddingBottom/paddingLeft/paddingRight, margin --> marginTop/marginBottom/marginLeft/marginRight, spacing --> spacingTop/spacingBottom/spacingLeft/spacingRight

0.2.x roadmap

Work has begun on v0.2.0 and will be tracked in the 0.2.x branch. Main objectives are:

• Improved label layout features and speed due to better pre-emptive label measuring.
• More modularization of component structure - export parts of charts, not just entire charts, so the parts can be composed individually.
• Encapsulation of reusable and extractable Component features using higher-order components. Not just for DRY-ness, but to make the Components themselves as simple as possible.

The feature roadmap will be tracked in this checklist, which we'll add to and edit as we go along:

• Refactor mouse events on new XYPlot component
• Production build of examples sandbox, for performance testing
• Port existing charts to new XYPlot format (see below)
• Bar component
• RangeRect component
• Use class-type components instead of createClass
• resolveXYScales HOC to resolve scale prop from domain/range/data/size/etc.
• resolveObjectProps HOC to handle setting default props for {x,y} and {top, bottom, left, right} shaped props
• Use measure-text to pre-measure labels
• XAxis and YAxis components
• Unit test which renders the examples
• Update lodash to 4.5.x
• Add babel plugin for ESNext class properties
• Axis label placement - see AUDINP-232

measure-text's dependencies are declared as dev-dependencies

Right now if there is a conflict of Reactochart's dependency measure-text's dependencies. measure-text's dev-dependencies are declared as regular dependencies. This can cause an error of Cannot read property 'context' of undefined if there are conflicts of version.

Override barClassName prop in BarChart to allow for functions returning dynamic classNames

reactochart 0.1.0 had a getClass function prop in the BarChart component that would allow the individual bars to dynamically generate their classnames. This prop is not present in the 0.2.1 version.

To replace this funcitonality, the barClassName prop of BarChart should be overridden to allow a string or a function, and the optional evaluation of that function will occur in the RangeBarChart component. Props passed to that function should be the datum, index, and potentially some of the scale information.

Specifying ticks prop on XAxis or YAxis throws error

the error is in /src/utils/Scale.js

Scale.js:104 Uncaught ReferenceError: combineDomains is not defined

It seems that that function should be imported from lib/utils/Data.js but it isn't included in the Scale module.

Links in navigation bar timeout

both the "AV UI" and "Reactochart" links seem to be blocked by a firewall.

An in-range update of d3 is breaking the build 🚨

The dependency d3 was updated from 5.14.2 to 5.15.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

d3 is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

Commits

The new version differs by 3 commits.

• 7c711ba 5.15.0
• 4223190 Update dependencies.
• 1126611 Squelch Rollup warnings.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Allow support for scaleUtc for xScaleType and yScaleType

In our app, we had previously used scaleUtc, in our charts. This allowed for tests run on CI to not care about time zones when parsing/reading dates. Reactochart doesn't have an option to use this scale type, only scaleTime, which is set to your local time zone.

It's be great to have a different scaleType we can pass in the generate scales using UTC dates

Namespace default classNames

Currently by default we render (& style) elements with very general classNames eg. chart-bar or xy-plot which could accidentally collide with classNames that users would use in their apps. Per suggestion from @ekh64 we should prefix these with a namespace eg rc-chart-bar. rc- seems best, but I want to check out rc-slider (common slider library) and similar to make sure we don't use the same prefix they do.

v4.17 of lodash causes slowness in XYPlot

the v4.17 lodash release yesterday causes some major slowness in reactochart (https://github.com/lodash/lodash/wiki/Changelog). Since it’s a ‘non-breaking’ release it can creep in when you npm install from scratch (or deploy to dev which builds on server). This problem occurs with the _.omit on line 92 of XYPlot (https://github.com/spotify/reactochart/blob/master/src/XYPlot.js#L92). Since the latest lodash version adds deep path support to _.omit the child tree of every XYPlot gets traversed and cloned for different comparison functions.

Deprecate Moment.js

Moment is big and bloats bundles, would be nice to deprecate that use in favor of d3-time-format or d3-time

Some of this functionality might be bundled into the standard d3 import by default.

Deprecate numeral.js

Numeral.js is no longer maintained. Would recommend switching to d3 format. This would be a breaking change as we allow users to send a format array, where each string in the format array maps to numeral's way of formatting.

This would also reduce our bundle size and allow us to leverage more packages already imported by our use of d3.

Changelog

Reactochart should have a Changelog file. Should retroactively include API changes for 0.4.x (see #47 )

An in-range update of enzyme is breaking the build 🚨

There have been updates to the enzyme monorepo:

• • The devDependency enzyme was updated from 3.10.0 to 3.11.0.

• The devDependency enzyme-adapter-react-16 was updated from 1.15.1 to 1.15.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the enzyme group definition.

enzyme is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

cannot set CSS classes for labels, titles

Label and title styles must be set through the labelStyle and titleStyle props respectively.

Labels have inline styles by default, that must be overridden by a labelStyle prop to be changed (because inline styles override CSS stylesheet styles, a stylesheet selector cannot be used without the !important flag, which is hacky),
Titles have this issue as well, as well as having no class associated with them, so it isn't possible to select them with a CSS child selector.

This makes it very difficult to have a centralized style sheet that manages styles for all charts.

I'm adding this issue so it can be addressed in the refactor.

Specifying only x or only y domain in XYPlot breaks resolveXYScales in some cases

This problem only occurs when either x or y is set in the domain prop of XYPlot, but not when both are set, nor when the domain prop is not specified.

The error occurs in /src/utils/resolveXYScales.js. I only see the error in the built code, but after trying to parse it out of the unbuilt code I believe it's line 360-361. It's possible to resolve this issue by explicitly specifying both x and y in the scaleType prop on XYPlot.

As a way to reproduce, the example on the following line will generate the error if the scaleType="linear" prop is removed:
https://github.com/spotify/reactochart/blob/0.2.1/examples/src/Examples.jsx#L111

An in-range update of css-loader is breaking the build 🚨

The devDependency css-loader was updated from 3.2.1 to 3.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

css-loader is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

Release Notes for v3.3.0

3.3.0 (2019-12-09)

Features

• support pure css modules (#1008) (6177af5)

Bug Fixes

• do not crash when an assert return null or undefined (#1006) (6769783)
• reduce count of require (#1004) (80e9662)

Commits

The new version differs by 5 commits.

• 889807a chore(release): 3.3.0
• 6177af5 feat: support pure css modules (#1008)
• 6769783 fix: do not crash when an assert return null or undefined (#1006)
• 80e9662 fix: reduce count of require (#1004)
• e662b61 refactor: code (#1003)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Use d3 modules instead of full d3 import

now that d3 is on 5.x, it would be great to switch over to the modular imports to reduce bundle size for consumers of the library.

Related to #9

Upgrade to d3 4.x

As of v4, d3 has been broken up into many modules (e.g. d3-scale, d3-selection, etc). There are also some API changes.

Not only is it a good idea to stay on the current major version, but the final size would drop quite a bit if reactochart only imports the d3 packages it needs.

I've ported a few examples and projects from 3.x to 4.x and it's relatively simple. Changing import d3 from "d3" to import * as d3 from 'd3' then doing a search-and-replace for the new methods names (old: d3.scale.ordinal new: d3.scaleOrdinal, etc) will get you pretty far. Converting to statements like import { scaleLinear, scaleOrdinal } from 'd3-scale' should be the ultimate goal, but I typically save that for a second pass after things are converted and working.

The changes to selections are probably the most substantial but, in my experience, don't take much effort to convert.

Reactochart Breaks with Fragments as Children

It'd be amazing if Reactochart could handle Fragments in some way. Currently if you pass in a component with Fragments, it doesn't render properly and the entire visualization breaks.

why can't bind `stateful` and `controlled` together with the ZoomContainer component

what I mean is that when pass controlled to the component, d3-zoom then has no effect at all。

I understand the snyc of zoom props and zoom state is not an easy thing，but the current sulution is not the best。

so do you have plan to improve this？

Thoughts on implementing semantic versioning

Hello!

Reactochart doesn't have any official release & versioning procedures and I wanted to propose the official adoption of semantic versioning going forward. Per semver this would mean

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Goals

• Provide Reactochart users with a more meaningful idea of what each version upgrade entails. Major version upgrades relate to breaking API changes. Minor version upgrades relate to newly added or updated API changes with backward compatibility. Patch versions are for bugs and refactors that don't affect the API.
• Removes subjectivity and human emotion from versioning through rules that are easy to reason with

What this doesn't solve

• Documentation: Reactochart is for developers (not machines) and as maintainers we are responsible for documenting the changes of each release. This means being descriptive with our changes via the changelog, and updating our docs on gh-pages with each release.

[Infra] Explore renovate or greenkeeper for auto dependency management

Explore greenkeeper, renovate, or some other tool to help with automated dependency updates

Migrate to spotify/web-scripts

Spotify open sourced a whole load of configs, spotify/web-scripts, maybe we could use them to keep our code tidy?

YAxisLabels should calculate margin top and margin bottom using alignmentBaseline

Currently YAxisLabels calculates its margin top and margin bottom with textAnchor attribute. That doesn't make sense since textAnchor determines <text> alignment on the horizontal plane.

YAxisLabels should be taking into account alignmentBaseline to determine any vertical overhang.

Issue in screenshot below

The margin bottom should be adjusted to account for alignmentBaseline: hanging.

resolvers in `resolveXYScale` should recursively traverse `children` tree

The new code in 0.2.1 is improving but has a significant regression - All of the resolvers in resolveXYScales used to recursively check the component's children to find the necessary props. However @thehindenburg 's new mapOverChildren, while being a nicer abstraction, does not do recursion - it only maps over an element's direct children.

Recursion is necessary IMHO because we want to support the use case of the user having intermediate layer components between XYPlot and their charts, eg.:

<XYPlot>
  <CustomChartWrapper>
    <LineChart />
    <AreaChart />
    <BarChart />
  </CustomChartWrapper>
</XYPlot>

Without recursion, this would never try to resolve anything on the actual chart components, it would stop at CustomChartWrapper. We should improve the general resolution functions in resolveXYScales to handle this case

An in-range update of style-loader is breaking the build 🚨

---

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

---

The devDependency style-loader was updated from 1.1.3 to 1.1.4.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

style-loader is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

Release Notes for v1.1.4

1.1.4 (2020-04-15)

Chore

• update deps

Commits

The new version differs by 3 commits.

• 171a747 chore(release): 1.1.4
• af1b4a9 chore(deps): update
• a003f05 docs: add links for the options table (#460)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Prop for XLine and YLine to have a prop to set height and width

Currently XLine/YLine span the full height/width of the chart. Would be nice to declare a stopping point for height/width based on a value in the xaxis/yaxis domain. This can set up visualizations such as intersection points on a LineChart.

Modularize lodash

Lodash can be modularized, but the results can look gross. I took a stab on my fork, but the result was pretty gnarly (and not 100% functional)

Maybe there's a way to do this without explicit imports? Maybe something in the bundling?

An in-range update of eslint-plugin-react is breaking the build 🚨

The devDependency eslint-plugin-react was updated from 7.16.0 to 7.17.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-react is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

Release Notes for v7.17.0

Added

• jsx-no-target-blank: add allowReferrer option (#2478 @eps1lon)
• jsx-handler-names: add checkLocalVariables option (#2470 @aub)
• prop-types: Support Flow Type spread (#2446 @moroine)
• jsx-props-no-spreading: add explicitSpread option to allow explicit spread of props (#2449 @pawelnvk)
• jsx-no-target-blank: warn on target={'_blank'} expressions (#2451 @timkraut)

Fixed

• sort-prop-types, jsx-sort-default-props: disable broken autofix (#2505 @webOS101)
• no-typos: improve report location (#2468 @golopot)
• jsx-no-literals: trim whitespace for allowedStrings check (#2436 @cainlevy)
• jsx-curly-brace-presence: Fix filter of undefined error with whitespace inside jsx attr curlies (#2460 @dustinyoste)
• no-render-return-value: should warn when used in assignment expression ([#2462][] @jichu4n)
• jsx-curly-brace-presence: allow trailing spaces in literal (#2448 @doochik)

Changed

• [Deps] update jsx-ast-utils, object.fromentries, resolve
• [eslint] fix func-names and change object-shorthand to 'always' (#2483 @golopot)
• [Docs] jsx-first-prop-new-line: Fix documentation formatting (#2489 @pjg)
• [Docs] prop-types: Update 'skipUndeclared' in rule options (#2504 @cjnickel)
• [Docs] jsx-first-prop-new-line: fix wrong rule name (#2500 @zgayjjf)
• [eslint] enable eslint-plugin-eslint-plugin (#2469 @golopot)
• [Docs] jsx-props-no-multi-spaces: suggest using core rule instead (#2463 @golopot)
• [Docs] jsx-first-prop-new-line: add rule options (#2465 @SerdarMustafa1)
• [Docs] jsx-no-target-blank: Add section about overriding for trusted links (#2438 @aschriner)
• [Docs] fix typo (#2453 @cainwatson)
• [Docs] no-unused-prop-types: clean up prose (#2273 @coryhouse)
• [Docs] jsx-no-bind: add section about React Hooks (#2443 @kdex)

Commits

The new version differs by 26 commits.

• 027ebd9 Update CHANGELOG and bump version
• 89911de [Deps] update jsx-ast-utils, object.fromentries, resolve
• cfef664 [Dev Deps] update @types/eslint, @types/estree, @types/node, coveralls, typescript
• d3b5d71 [New] jsx-no-target-blank: add allowReferrer option
• 83ac4c0 [eslint] fix func-names and change object-shorthand to 'always'
• 225b433 [Docs] jsx-first-prop-new-line: Fix documentation formatting
• 62df1dd [Docs] prop-types: Update 'skipUndeclared' in rule options
• 87d4cab [Docs] jsx-first-prop-new-line: fix wrong rule name
• 55b605f [Fix] sort-prop-types, jsx-sort-default-props: disable broken autofix
• 71c7d01 [Tests] temporarily pin eslint 6 tests to v6.6
• 8093565 [New] jsx-handler-names: add checkLocalVariables option
• 5be539b [Fix] no-typos: improve report location
• d9d2193 [eslint] enable eslint-plugin-eslint-plugin
• 39e4396 [Docs] jsx-props-no-multi-spaces: suggest using core rule instead
• 9e4ad21 [Docs] jsx-first-prop-new-line: add rule options

There are 26 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

[Infra] Integrate cross-env into scripts using ENV variables

Our build and test scripts set env variables that fail for developers on Windows OS.
We should leverage cross-env on scripts that require an env variable.

BarChart mouse events need to be added to 0.2.1

onMouseEnterBar, onMouseMoveBar, and onMouseLeaveBar event handlers need to be added to BarChart for backwards compatibility.

Console Warnings When Using React 16.9

With the release of React 16.9, they added warnings for soon to be deprecated lifecycle methods. Reactochart leverages a couple of the methods and causes a lot of console warnings.

A fast fix is to rename the functions UNSAFE_<lifecyclemethod>, a better, but more time consuming fix is to refactor the code to use deriveStateFromProps and componentDidX

Upgrade to d3 5.x

To enable resolving multiple d3 imports in my project, reactochart should be upgraded to the latest d3 version.

Closing #140 as this makes it harder to prevent multiple imports of d3 in a project.

Minify output

Hey, you should minify your css and js, check out the config here on how its done.

Love <3

Decorate XYPlot onMouseEnter and onMouseLeave events

We decorate onMouseMove, onMouseDown, onMouseUp, onClick with helpful information like xScale, yScale, xValue and yValue. We should decorate onMouseEnter and onMouseLeave for consistency.

Not able to change layout in Histogram.js and Histogram.js.example accurately.

Hi,

I am new to open source and I am trying to solve an issue I have been getting.

To do

So I am trying to add a button in Histogram.js.example which changes the layout between vertical and Horizontal Histogram.

Output

It does change the sizes of the layout but it is not adjusting the graph exactly.

Here is what I am getting -

I just need help on how i can solve this.

Cheers,

Upgrade to react & react-dom 16.x

My projects are relying on React 16.4.x, and while Reactochart functions as expected, I do get a incorrect peer dependency warning on the react and react-dom modules. Reactochart appears to be working as expected, but it would be nice to have these versions of React officially supported.

Allow users to override text anchor for XAxisLabels and YAxisLabels

Work was done in #138 but haven't had time to investigate why it's strictly enforced to be middle and end for X and Y AxisLabels.

Convert test suite from mocha to jest

Our tests currently leverage mocha, chai and sinon. We should migrate our test suite to use jest.

• It's Spotify's preferred Javascript test framework and aligns web-scripts out of the box eslint configuration. See here.
• Jest is a kitchen sink that works out of the box, removing the need to manage multiple dependencies.
• Jest is overtaking mocha in community adoption (as of 10/29/19 5.1 million vs 3.3 million weekly downloads). Adopting the tools used more frequently by our community can reduce barrier to contribution.

Add precommit hooks from spotify web-scripts

We've migrated our eslint and prettier configs to pull from Spotify's.
I don't think we necessarily need to add all the scripts they're using but we should take advantage of husky precommit hooks.

{
  "scripts": {
    "test": "web-scripts test",
    "lint": "web-scripts lint",
    "build": "web-scripts build",
    "commit": "web-scripts commit",
    "release": "web-scripts release"
  },
  "husky": {
    "hooks": {
      "commit-msg": "web-scripts commitmsg",
      "pre-commit": "web-scripts precommit"
    }
  }
}

See here for more documentation https://github.com/spotify/web-scripts

Component props marked as required should not have defaults

There are component props listed as required within the component's PropTypes and docs but are given a default. This is misleading. In an effort to clean up this confusion, I've outlined the component and the props below that should change by either removing the isRequired or the default.

I'm also proposing that going forward we don't mark data as required and supply either a default empty array or return null in render if data is undefined. Would like some feedback on this though @spotify/reactochart-dev!

AreaChart

• remove isRequired from data prop
• set data: [] in defaultProps
• set pathStyle to default to {} and remove || {} on lines 189, 190 and 221

AreaHeatmap

• remove isRequired from data prop
• set data: [] in defaultProps

ColorHeatmap

• remove isRequired from data prop
• set data: [] in defaultProps

FunnelChart

• remove isRequired from data prop
• set data: [] in defaultProps
• set pathStyle default to {}
• set style = pathStyle on line 129

Histogram

• remove isRequired from data prop
• set data: [] in defaultProps
• remove isRequired from thresholds prop
• set barClassName: '' in defaultProps
• set barStyle: {} in defaultProps

KernelDensityEstimation

• remove isRequired from data prop
• set data: [] in defaultProps
• set lineStyle: {} in defaultProps
• set lineClassName: '' in defaultProps

LineChart

• remove isRequired from data prop
• set data: [] in defaultProps

MarkerLineChart

• remove isRequired from data prop
• set data: [] in defaultProps

PieChart

• remove isRequired from data prop
• set data: [] in defaultProps

SankeyDiagram

• remove isRequired from nodes prop
• set nodes: [] in defaultProps
• remove isRequired from links prop
• set links: [] in defaultProps
• remove isRequired from width prop
• remove isRequired from height prop

ScatterPlot

• remove isRequired from data prop
• set data: [] in defaultProps

TreeMap

• remove isRequired from data prop
• set data: {} in defaultProps

An in-range update of webpack is breaking the build 🚨

The devDependency webpack was updated from 4.41.2 to 4.41.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

Release Notes for v4.41.3

Security

• force upgrade terser-webpack-plugin dependency for security fix (not affecting webpack)

Funding

• add npm funding field to package.json

Commits

The new version differs by 5 commits.

• df9f3eb 4.41.3
• fe71d68 Merge pull request #10010 from webpack/funding
• b396d96 Merge pull request #10123 from pustovalov/webpack-4-serialize
• 29b2bdd Update terser-webpack-plugin to ^1.4.3
• bedb566 chore: funding field

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Add Style prop to XYPlot component

• Adding a style or plotStyle prop would allow a user to pass in styles to the XYPlot (a component used by most almost users).
• For reference, SankeyDiagram has a style prop, so this would provide similar parity.
• A benefit would be that a user wouldn't have to use classname-based styling in their entire implementation and stick to one methodology.