Swiper Configuration and Client-Side State Management Limits

Swiper Behavior

The documented limit on active Swiper instances per page load is not specified; the practical limit is determined by browser memory and DOM size.

Confirmed facts

• Swiper core does not expose a maximum number of instances.
• Each instance is bound to its own container element; instances do not share state.
• Swiper does not retain slide index, breakpoints, or configuration across component re‑renders unless explicitly saved.

Likely explanation

When the element that hosts a Swiper instance is removed or recreated (e.g., during a framework re‑render), the existing Swiper instance is destroyed and its state is lost. To preserve state you must call swiper.update() or re‑initialize the instance after the DOM change, or use a framework wrapper that handles re‑initialization.

Steps to verify

1. Create a test page with three uniquely named Swiper containers and confirm all initialize without instance‑limit errors.
2. Mount a Swiper in a React component, change the slide index, force a re‑render that unmounts the slider element, then remount and verify that swiper.activeIndex is not retained unless you call swiper.slideTo or re‑initialize.
3. Inspect the Swiper instance object before and after the re‑render to see whether state is lost.
4. Search the installed Swiper package documentation for “instance limit” or “max instances” to confirm no documented cap.

Missing diagnostic detail

Are you using a framework‑specific wrapper (e.g., @swiper/react or @swiper/vue) that automatically recreates the Swiper instance when the underlying element changes?