# react-component/progress: the SVG progress primitives behind the Ant Design ecosystem

> @rc-component/progress is a small React package that renders line and circle progress indicators as SVG, with segmented values, gradients, indeterminate loading and semantic style slots. It ships no visual theme of its own, which makes it a building block rather than a drop-in component.

**react-component/progress** — 📊 Lightweight React line and circle progress indicators with SVG rendering.

- Repository: https://github.com/react-component/progress
- Website: https://react-component.github.io/progress
- Stars: 706 · Forks: 162
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/react-component-progress

## A geometry library, not a styled component

The package publishes itself as a lightweight React component set for line and circle progress indicators rendered with SVG, and it describes itself as part of the Ant Design ecosystem. That framing sets expectations correctly. There is no theme file, no CSS bundle and no opinion about how a progress bar should look. The default track color is '#2db7f5' and the default rail color is '#D9D9D9', and both are simply the fallback values you get if you pass nothing.

Two components are exported, Line and Circle, and they share the same base props. That shared surface is the reason the package stays small: one props table covers a linear bar, a circular gauge, a segmented multi track bar and a spinner style indeterminate state. The class prefix is 'rc-progress', and standard SVG attributes are forwarded to the root SVG element.

Who is this for? Engineers who already own a component layer and want progress rendering that matches their own design tokens, rather than a finished widget that would need to be overridden. If you need a progress bar that looks finished on day one and ships with its own visual language, this package hands you raw SVG geometry and asks you to supply the styling decisions yourself.

## One percent prop drives four very different renderings

The interesting part of the API is that a single percent prop, typed as number or number[], combined with a few others, covers most of the shapes people draw. A plain number draws one track. An array of numbers draws multiple tracks, one per entry, which is how the segmented bar in the documentation is built, with strokeColor given as an array of the same length.

```tsx
import { Circle, Line } from '@rc-component/progress';
export default () => (
  <>
    <Line percent={42} strokeWidth={4} strokeColor="#1677ff" />
    <Circle percent={75} strokeWidth={6} strokeColor="#52c41a" />
  </>
);

```

The segmented form passes an array of percents and an array of colors:

```tsx
import { Circle } from '@rc-component/progress';
export default () => (
  <Circle
    percent={[30, 20, 10]}
    strokeWidth={6}
    strokeColor={['#1677ff', '#52c41a', '#faad14']}
    railWidth={6}
  />
);
```

Two more modes sit alongside the numeric ones. A steps prop, accepting either a number or an object with count and gap, renders progress as discrete steps rather than a continuous sweep. A loading prop renders an indeterminate loading animation, which is the state to reach for when the total amount of work is unknown and a percentage would be a lie.

A gradient is expressed through the same strokeColor prop, which accepts a string, a Record of colors keyed by something, or an array of either. The type signature is wide on purpose, but the documentation does not spell out the semantics of the Record form, so treat that shape as something to confirm against the source in your own code rather than assume.

## Circle specific geometry: gapDegree and gapPosition

Only Circle carries the two gap props. gapDegree takes a number and gapPosition takes 'top', 'right', 'bottom' or 'left', with 'bottom' as the default. These two together control the notch cut out of the circular track, the detail that makes a circular gauge read as a gauge rather than as a filled donut.

They are circle only. Passing them to Line has no documented effect, which is the kind of thing a shared props table can hide: the props are listed as shared base props, but gapDegree and gapPosition are described as circle progress specific in the API table. If you are building a wrapper component that forwards every prop to both variants, you need to filter those two yourself.

The rest of the shared surface is straightforward. strokeWidth sets the track stroke width and defaults to 1, railWidth sets the rail stroke width and also defaults to 1, strokeLinecap accepts 'round', 'butt' or 'square' and defaults to 'round', and transition takes a CSS transition string used for track updates. That last prop is worth knowing about, because it is the documented way to animate a changing percent without writing a keyframe.

## The rendered SVG is decorative unless you say otherwise

This is the sharpest constraint in the package, and it is stated plainly: the SVG is decorative by default. When you use it as the progress indicator itself, you are expected to provide progress semantics and an accessible name with standard SVG and ARIA props.

```tsx
<Line
  percent={42}
  role="progressbar"
  aria-label="Upload progress"
  aria-valuemin={0}
  aria-valuemax={100}
  aria-valuenow={42}
/>
```

Because the package forwards standard SVG attributes, including role and aria-*, to the root SVG, the accessibility wiring is possible without patching the component. But it is not automatic, and there is no built in ARIA layer, no label prop and no implicit value announcement. Whoever owns the feature is responsible for keeping aria-valuenow in sync with the percent it passes in. For a library team that means the decision of who supplies these attributes has to be made before the component is wrapped, not after.

The docs site is at https://react-component.github.io/progress, and the Chinese README is kept alongside the English one.

## Semantic classNames and styles for root, rail and track

Customization happens through two parallel props. classNames accepts a partial record keyed by 'root', 'rail' and 'track', and styles accepts a partial record of the same three slots with CSS properties. A plain className still applies to the root node, and style applies to the root as well.

The value of the slot model here is that the internal structure is stable enough to name. A rail is the background track, a track is the filled portion. With those three slots you can restyle a progress bar from the outside without reaching for descendant selectors that break when the internal markup changes.

What the package does not do is let you change the geometry. There is no radius prop, no custom renderer and no way to swap the SVG for a different element, so if your design calls for a rounded bar with a specific height and cap treatment that does not match the built in stroke model, you end up overriding rather than configuring. That is the point where this package stops being enough and you write your own component.

## Installation, running the docs site and the release path

The install step is a single npm command, published under the scoped name @rc-component/progress:

```bash
npm install @rc-component/progress
```

To work on the package itself, install dependencies and start the dumi docs site, which serves on port 8000:

```bash
npm install
npm start
```

Then open `http://localhost:8000`. The scripts listed in package.json cover the rest of the workflow: npm test runs the test suite through rc-test, npm run tsc runs tsc --noEmit for type checking, npm run compile runs father build, and npm run build produces the docs site. The published package exposes two entry points, ./lib/index as main and ./es/index as module, and the files field lists only lib and es, so consumers get compiled output rather than source.

Releases go through @rc-component/np. The prepublishOnly script compiles the package and then invokes rc-np, and the README describes that as the release flow being handled after the package build. The repository uses husky, which the prepare script runs alongside dumi setup, so local commit hooks are part of the checkout rather than something each contributor installs by hand.

## MIT licence, a slow release cadence and a mature minor version line

The package is released under the MIT licence, which is the permissive end of open source licensing and does not impose copyleft on code that uses it. The LICENSE and LICENSE.md files are both present at the repository root. MIT requires that the copyright notice and permission text travel with copies or substantial portions of the software, so if you vendor the compiled output into a shipped bundle, keeping the notice is on you. That is a note about the obligation, not legal advice.

On upkeep, the version line tells a quieter story than the ecosystem around it. The releases are @rc-component/progress 1.0.1 on 2025-04-17, 1.0.2 on 2025-11-28 and 1.0.3 on 2026-08-27, and the last push was on 2026-09-07. The repository is not archived. The version number has stayed in the 1.0 range across three releases, which is what you would expect from a component whose API surface is a single shared props table rather than a package that keeps growing new features.

That also sets the upgrade expectation. There is no 2.0 line to plan for and no major version migration to rehearse in the recent history, and the repository keeps a CHANGELOG.md for the details. The dependency list is short: @rc-component/util at ^1.11.1 and clsx at ^2.1.1, so the package adds very little to a bundle. The realistic upgrade cost for a consumer is checking that your usage still matches the props table, since the API is small enough to read in full.

## Conclusion

Adopt @rc-component/progress when you are building a design system layer on React and want the geometry of a progress indicator under your control, including multi segment values and per track colors. Do not adopt it expecting a styled component, since every color, including the default track blue and the grey rail, has to be supplied or accepted from your own theme. Before wiring it into a product, check that your build accepts a package exposing only lib and es entry points, decide who owns the ARIA attributes, since the rendered SVG is decorative by default, and confirm that your percent source can be expressed as a number or an array of numbers rather than an animated continuous value.

## FAQ

### How do I install @rc-component/progress and render a basic progress bar?

Install it with npm install @rc-component/progress, then import Line or Circle and pass a percent prop, for example <Line percent={42} strokeWidth={4} strokeColor="#1677ff" />. The component is exported from the package root and renders an SVG.

### How do I show several segments in one progress bar with @rc-component/progress?

Pass an array of numbers to percent, which renders multiple tracks, and supply an array of matching colors through strokeColor. The documentation shows percent={[30, 20, 10]} with strokeColor={['#1677ff', '#52c41a', '#faad14']}.

### Is @rc-component/progress accessible by default?

No. The rendered SVG is decorative by default, so you need to add progress semantics yourself, such as role="progressbar" together with aria-label, aria-valuemin, aria-valuemax and aria-valuenow. Standard SVG attributes including role and aria-* are forwarded to the root SVG.

## Sources

- [License: MIT](https://github.com/react-component/progress/blob/master/LICENSE)
- [Project website](https://react-component.github.io/progress)
- [react-component/progress on GitHub](https://github.com/react-component/progress)
- [README](https://github.com/react-component/progress/blob/master/README.md)
- [Releases](https://github.com/react-component/progress/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/react-component-progress