ranui
Version:
A framework-agnostic Web Components UI library built on native custom elements, with TypeScript types, light/dark theming, SSR and PWA support.
87 lines (86 loc) • 4.03 kB
TypeScript
import { EventManager, RanElement } from '../../utils';
export declare class Progress extends RanElement {
_progress: HTMLDivElement;
_progressWrap: HTMLDivElement;
_progressWrapValue: HTMLDivElement;
_progressDot: HTMLDivElement;
_shadowDom: ShadowRoot;
_events: EventManager;
_dragEvents: EventManager;
moveProgress: {
mouseDown: boolean;
};
private _tabIndexOwnedByComponent;
static get observedAttributes(): string[];
constructor();
get percent(): string;
set percent(value: string);
get total(): string;
set total(value: string);
get type(): string;
set type(value: string);
get dot(): string;
set dot(value: string);
get sheet(): string;
set sheet(value: string);
handlerExternalCss: () => void;
progressClick: (e: MouseEvent) => void;
/**
* `document` pointermove/pointerup(/pointercancel) are attached here (drag
* start) and removed in `progressDotMouseUp`/`disconnectedCallback` (drag
* end) — NOT bound for the component's whole connected lifetime. A page can
* reasonably have many `<r-progress>`, most never dragged (e.g. a list of
* upload rows); a document-level listener per instance would run its no-op
* `moveProgress.mouseDown` check on every single pointermove for the entire
* page for as long as any of them exist. Scoping it to "only while a drag on
* *this* instance is actually happening" keeps that cost at the number of
* drags in flight (normally 0 or 1), not the number of progress bars on the
* page.
*
* Pointer Events (not mouse-only) so dragging the dot works with touch —
* matches `touch-action: none` on `.ran-progress-dot` in index.less, and the
* `r-player`/`r-colorpicker` pointer-drag idiom documented in CLAUDE.md.
*/
progressDotMouseDown: (e: PointerEvent) => void;
progressDotMouseMove: (e: PointerEvent) => void;
progressDotMouseUp: () => void;
/**
* Arrow-key seeking for `type="drag"` — the mouse/touch drag path had no
* keyboard equivalent, so a `role="slider"` with no way to actually operate
* it from the keyboard. Left/Down and Right/Up step by 1% of `total`
* (Shift for a 10%-of-total coarse step); Home/End jump to the ends,
* matching native `<input type="range">`. Key mapping is shared with
* r-colorpicker's hue/alpha sliders via `sliderStepFromKeydown`.
*/
progressKeydown: (e: KeyboardEvent) => void;
/**
* role + aria-value* live on the host (the focusable element) rather than
* the shadow-internal `.ran-progress` div — a screen reader needs both on
* the same accessible node. `progressbar` is read-only semantics; `drag`
* is operable, so it gets `slider` plus the tab stop that makes the
* existing keyboard/mouse handlers reachable in the first place.
*/
syncA11y: () => void;
updateUI: (percentage: number) => void;
_preSerialize(): void;
change: () => void;
appendProgressDot: () => void;
updateCurrentProgress: () => void;
/**
* Bound once, unconditionally, from `connectedCallback` — NOT re-run when
* `type` changes later. Gating the *binding* on `this.type === 'drag'` (as
* this used to) meant a `<r-progress>` created as `primary` and switched to
* `drag` afterwards got `syncA11y`'s role="slider"/tabIndex (which does
* re-run on attribute change) without ever getting click/drag/keyboard
* listeners — a slider that claims to be operable and silently isn't. Each
* handler below already re-checks `this.type` itself, so binding
* unconditionally here is safe and keeps behavior in sync with the type
* actually in effect at interaction time, not at connect time.
*/
dragEvent: () => void;
private resize;
connectedCallback(): void;
disconnectedCallback(): void;
attributeChangedCallback(name: string, oldValue: string, newValue: string): void;
}
export default Progress;