rc-component slider: a package rename that left the class prefix behind

The package renamed, the class prefix did not

The package installs as @rc-component/slider and both documented examples import it by that name, but the default value of prefixCls is still 'rc-slider'. Nothing in the docs renames that value, so a selector written against the new package name matches nothing while the shipped stylesheet keeps working. That mismatch is the first thing to check in devtools when a migrated slider looks unstyled, before assuming a build step dropped your CSS.

npm install @rc-component/slider

The entry points follow the usual dual build: main resolves to ./lib/index, module to ./es/index, and types to ./es/index.d.ts, with lib, es, and assets/*.css as the only published files. The stylesheet is produced separately from assets/index.less by the lessc step inside the compile script, which is why every example imports '@rc-component/slider/assets/index.css' right next to the component import. A toolchain that drops CSS imports gets a functioning slider with no visible track or handle. The root element also takes id, className, and style for cases where the control has to sit inside someone else's form layout.

Six deprecated props, each with a named replacement

The API table marks six props as deprecated and every one of them points at its successor, so the migration is mechanical if you read the table instead of guessing. The count prop is replaced by range.minCount or range.maxCount. Three styling props collapse into the styles object: handleStyle becomes styles.handle, railStyle becomes styles.rail, and trackStyle becomes styles.track. The two lifecycle callbacks split along the same lines as the current pair, with onBeforeChange superseded by onChange and onAfterChange by onChangeComplete.

```tsx pure import Slider from '@rc-component/slider'; import '@rc-component/slider/assets/index.css';

export default () => ( <Slider range={{ draggableTrack: true }} marks={{ 0: '0', 50: '50', 100: '100' }} defaultValue={[20, 60]} /> ); ```

The same table is where the semantic slots are defined. Both classNames and styles accept a partial record keyed by 'tracks', 'track', 'rail', and 'handle', and the plural and singular keys sit next to each other without being interchangeable: styles.tracks targets the container that holds the segments while styles.track styles an individual segment. For anyone moving off the older style props, that record is the only place the mapping is written down.

range.editable turns two handles into an add and remove control

The range prop accepts a boolean or a RangeConfig object, and the object holds the behaviour worth planning around. draggableTrack defaults to false and lets the selected interval be dragged as one piece rather than only by its handles. editable defaults to false and turns on adding and removing handles while the user interacts, with maxCount and minCount bounding how many handles may exist. Both counts are unset by default, so no bound applies until you give one, and the deprecated count prop is the older spelling of the same pair.

Two neighbouring props decide what a range does at its own edges. allowCross defaults to true, which lets the two handles pass each other. pushable defaults to false and takes either a boolean or a number, and pushing adjacent handles keeps a minimum distance between them so a range cannot collapse onto a single point. Both only mean anything in range mode, since a single-value slider has nothing to push apart. One more rendering prop, included, defaults to true and controls whether the track is drawn as one continuous selected interval, so switching it to false produces two separate segments instead.

Accessibility is configured per handle, one string or one array

The accessibility surface here is a family of props rather than a single switch, and each of them accepts a lone value or an array sized to the number of handles. ariaLabelForHandle sets aria-label, ariaLabelledByForHandle sets aria-labelledby, and ariaDescribedByForHandle sets aria-describedby. ariaValueTextFormatterForHandle takes a function or a list of functions, so each handle can announce a value in its own words when the raw number means little to a screen reader user. ariaRequired maps to aria-required on the handle elements, and tabIndex, defaulting to 0, follows the same single-or-array shape.

Keyboard interaction arrives without opt-in, since the keyboard prop defaults to true, and autoFocus focuses the slider on mount when the first keystroke has to land on it. The imperative ref exposes exactly two methods, focus and blur, which is enough to drive the control from a form reset or a dialog that steals focus on open. onFocus and onBlur hand you the raw event, so external state can mirror the handle without re-rendering the slider itself. A range with editable handles is where this pays off, because a handle that appears mid-interaction needs a label of its own.

step null hands the grid over to your marks

step defaults to 1, and setting it to null changes what the value grid is built from, because the marks become the steps. The marks prop takes a record keyed by string or number where each value is a ReactNode or a mark object, so a label can be plain text or an element. The second documented example keys three marks at 0, 50, and 100 with matching labels, and pairing that with a null step turns a hundred-position control into a three-position one.

Two display props decide how that grid is drawn. dots defaults to false and, when enabled, puts a dot at every valid step position. activeDotStyle takes either a style object or a function of the dot value, so the active position can look different as it moves, and dotStyle does the same job for the rest. Direction and framing sit alongside them: reverse flips the direction, vertical switches the layout, and startPoint, defaulting to min, sets the origin for a single-value track, which is how a slider that fills from the right instead of the left is built.

onChange fires while dragging, onChangeComplete fires after

There are two change callbacks, and the difference is when they run rather than what they return. onChange is triggered while the value changes, so a single drag fires it many times. onChangeComplete is triggered when the interaction completes, which makes it the one to use for anything expensive, because it fires once per gesture. The deprecated pair of onBeforeChange and onAfterChange maps onto exactly those two, which tells you the split is a rename that finally admitted two phases always existed rather than new behaviour added later.

Control follows the ordinary React pattern on top of that. value and defaultValue both accept a number or a number array, so the same two props cover single-value and range mode without reaching for a second component. disabled follows suit, taking a boolean or a boolean array, which is how you freeze one handle of a range and leave its partner movable. Nothing in the API forces a choice between the two styles of control: defaultValue serves the uncontrolled case, value serves the controlled one, and the component treats an array exactly like a number everywhere else it takes a value.

Releases run father, lessc, then rc-np

The toolchain is the standard react-component setup, and reading package.json describes the release path more precisely than the prose does. compile runs father build and then lessc assets/index.less assets/index.css, so the CommonJS output, the ES module output, and the stylesheet all come out of one command. build is compile plus docs:build, which is dumi build, and the docs reach GitHub Pages through a gh-pages script that publishes a docs-dist directory. test is rc-test, coverage is that runner with --coverage, tsc is tsc --noEmit, and lint runs eslint across src for ts, tsx, jsx, js, and md files. husky hooks in through the prepare script.

npm install
npm start
npm test
npm run tsc
npm run compile
npm run build

That block is the whole development section, and it is not the whole script list: lint, coverage, and the gh-pages bundle exist in package.json without a line in the docs. Publishing runs npm run prepublishOnly, which is compile followed by rc-np, with the flow itself handled by @rc-component/np. On upkeep, the repository is not archived, the last push is dated 2026-09-21, and the recent tags are @rc-component/[email protected] on 2026-09-16, 1.2.0 on 2026-08-27, and 1.1.1 on 2026-05-15. The default branch is master, and the package ships with a dumi documentation site plus a hosted online preview.

Editorial conclusion

Reach for this component when you need a range slider whose handles can be added, dragged, and labelled individually, and when you are willing to write against the rc-slider class names rather than the package name. Check two things before adopting it: whether your stylesheet targets the old prefix, and whether you rely on any of the six deprecated props, since each one already has a named replacement. Teams that only need a number input should keep using the native control.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-component/slider on GitHub
4. README
5. Releases