Exploring Recharts: different ways of accessing data

In Recharts, you provide data to the top level container, and on appropriate children you specify the key from which that particular child should get its data, using the prop named dataKey. This is only applicable for components that actually make use of this data, like Line or XAxis, YAxis, but does not make sense for components that do not need this whole data. For example, ReferenceArea, ReferenceLine etc only need some slice of this data, which does not require the same mechanism as dataKey. For these components that data is passed on or handled by Recharts internally.

Accessing data using dataKey:

Passing data in dataKey helps with some level of customization to allow accessing data or nested data directly using object keys.

Accessing nested data using dataKey

Accessing data using accessor function

You can also access the data using an accessor function, in case you want to run any transformations on the data, just for displaying in the chart.

(As an aside, you can also transform how data is displayed on the axes by providing custom ticks).

Other hack-ish workarounds

The accessor function might not look helpful on its own, but in some situations it can make consuming data more convenient. These usages come with their own set of caveats though.

Let’s consider a scenario where you need to show multiple line series. If you go by the default method of property access on object using dataKey it would mean that you need to create a single object and pass it on to the top level container and access this data using different keys on the child. Semantically, this is usually alright, because all the children share the same axes and hence all their data could come from the same place, in this case the same object. You might find it easier to keep this data separate in different objects and bind those objects somehow to the different children, while still expecting Recharts to handle everything else correctly. Accessor functions provide the capability to do so.

The above example is a bit fragile. The XAxis and YAxis are calculated based on the data passed to the top level container, and if the second line series has values outside of this already calculated values, the axes and other components may behave erratically, any automatic calculations might break as they would only happen based on the data passed in to the top level container. But if you can make sure that everything else remains the same, and the data that you are passing externally is derived from the data that you pass to the top level container, you can get some benefits from this approach, mostly in terms of developer convenience. In my usages, i haven’t seen a use case where this breaks, but do keep this in mind.

A similar workaround is discussed here, although it suffers from the same issues as our workaround.


A list of all other posts in this series: