Known limits
- A loop copy renders the slide's children again. Their state is their
own, effects and refs in them run once per copy, and an
id inside a slide
repeats three times. Avoid ids in looping slides, or make them unique
outside the slide. Deck.useSlide() tells content whether it is in a copy.
- Presses beyond the reachable copies are dropped. A step goes at most a
set of copies past either end. When presses come faster than the deck
moves, the deck passes fewer slides than were pressed, rather than moving
against a press or jumping mid-motion. At rest, a press always moves it one
snap point.
- Fade ignores slide geometry. Slide width, alignment and pages do not
apply to a fade deck.
- Curve draws on the slides' children, not the slide box. A slide's own
background and border stay flat.
- Server HTML can only start at a slide. With several slides per snap
point, or pages, the first paint at a
defaultIndex may correct after
hydration, and Dots and Counter recount.
- The first paint estimates progress from the slide's index. Server HTML
gives each slide its distance in slides from the starting slide. With
slides of different sizes, pages that start past the first, or a start the
scroll range keeps from the focal position, as at the end of a centred deck
with no padding, an effect or CSS on progress can move slightly at
hydration, when the engine measures.
- A controlled index counts pages. A breakpoint that changes the page
size points the same index at different slides.
- A long task can let Chromium undo a wheel. When a long task holds the
main thread just after a wheel during a move, Chromium can carry the move
on to its slide, against the wheel. The deck still rests on a snap point.
- No automated test covers touch flicks across a loop's seam. The
maintainer checks them by hand on a phone and a trackpad.