Building Charts in Victory Native XL

20/02/2026

react-native charts open-source maintenance

Helping out with chart feature work and OSS maintenance in Victory Native XL.

I've worked on victory-native-xl for a while now, but have recently more-or-less paused my involvement just due to time constraints. It is a great open source charting project with a real user base (around 1.1k stars and roughly 180k weekly downloads on npm).

Chart architecture at a glance

This is the simplified model I keep in my head while working in the codebase: data and props enter the chart container, transform and scale logic normalize it into chart state, rendering primitives draw to Skia, and gesture/reanimated state feeds interaction updates back into the loop.

Diagram of Victory Native XL chart architecture showing input data and chart props flowing through transformInputData and makeScale into chart state, then into rendering primitives and Skia canvas, with gesture and reanimated interaction feedback. — A practical architecture snapshot: input and transform layers feeding Skia rendering, with interaction state in the loop.

Two chart examples from the example app

These are two of a couple of concrete chart patterns I helped ship in Victory Native XL: a dashed-axis area chart (with nice gradients!) and a donut-style pie chart configuration (the gif is a bit artifacty) (among others).

Mobile screenshot showing a Victory Native XL area chart with dashed X and Y axes and month labels on the horizontal axis. — Area chart example: smooth area shape plus dashed axes for a lighter visual treatment.

Animated mobile recording of a donut chart in Victory Native XL where values are shuffled and slice proportions animate. — Donut chart example: pie configuration using an inner radius to create the donut shape.

What I actually worked on

A big part of my work was supporting different chart styles and improving the implementation details around them so they are flexible without being fragile. The goal was always to keep the API usable while making behavior predictable for real product workloads and trying to maintain compatibility with the existing API.

That means thinking beyond visuals. A chart that looks good in a screenshot but breaks in one layout edge case is not done. The finishing work is usually in interaction behavior, data-shape tolerance, and clear defaults.

Maintenance is part of the job

I also spent a lot of time on maintenance: triaging issues, reproducing bugs, reviewing and responding to pull requests, and following through on edge-case reports. This is less visible than feature work, but it is a big part of keeping the library pleasant to use.

In practice, that maintenance loop shortens time-to-clarity when something breaks, reduces duplicate confusion across issues, and turns one-off bug reports into durable fixes.

A few lessons from maintaining OSS

1. Clear problem statements help more than clever fixes. The best issue threads define expected behavior first, provide examples to reproduce the issue, and then discuss implementation.

2. Review quality compounds. Consistent PR feedback usually leads to better follow-on contributions from the community.

3. Backward compatibility is a feature. Preserving stable behavior across releases often matters as much as shipping new chart capabilities.

Why I enjoy this work

I like building practical things people use in OSS. Working on victory-native-xl has been a nice mix of shipping chart improvements and doing the quieter maintenance work that keeps the project moving.

If you want to check out the package directly, it is on npm.