I am currently building a custom slider Gutenberg block using SwiperJS. My slider block has a custom Slide block set as an InnerBlock template, and each slide has its own InnerBlocks component. I have it 90% working, but I need help with some UX improvements in the Gutenberg editor.

I have built a feature that allows Swiper to update its active slide based on the currently selected block. If a slide or an InnerBlock of a slide is selected, Swiper’s instance is updated so that the selected slide comes into view (with transition disabled so it happens instantly). This also updates the slider navigation/pagination, and then I can edit the contents. However, in certain instances this conflicts with whatever feature the Gutenberg editor leverages to bring elements into view when they are selected/focused. So the end result is: Swiper slides the selected slide into view while the editor pans to where the slide is, resulting in my active slide moving twice as much as it needs to and throwing off my slider navigation.

As far as how I am thinking about approaching this issue, I’d like to disable whatever handles the editor’s panning/focusing functionality only for my custom block. I am struggling to find what actually handles the panning/focusing of selected blocks in the Gutenberg editor. Can anyone point me in the right direction? Am I able to disable this functionality on a block-by-block basis?

Thanks in advance for any advice or help you can provide.

  • how have you done this? I've tried multiple times to get swiper JS working in the block editor when trying to answer questions about it here and the conclusion I came to was that SwiperJS' method of locating the DOM objects it needed was fundamentally incompatible and that its React implementation was just a wrapper around that and it didn't support Higher order components such as those used for inner block wrappers
    – Tom J Nowell
    Jun 15, 2023 at 19:58
  • @TomJNowell after reading through the documentation for the React implementation of Swiper I determined it probably wouldn't be feasible with Gutenberg (at least right now), so my implementation does not use it. Less than ideal, I know, but I simply use useRef/useEffect to initialize/reinitialize swiper depending on what parameters change. Some parameters don't work, but I was able to get most of them functioning. I can even nest instances inside one another... 😂
    – Ethan May
    Jun 15, 2023 at 21:06
  • I would reconsider using Swiper itself in the editor. You don’t need the edit component to have the full functionality of a slider, you just need a simple UI for navigating slides so that you can add content. The full interactivity with swiping and such can then just be added on the front end. Jun 16, 2023 at 3:09
  • @JacobPeattie that's definitely the safest option, but it's very nice to be able to tweak swiper's parameters in the editor & preview the changes. I haven't been able to find anything out there that does this with full support for any GB block. Thankfully I was able to find a solution.
    – Ethan May
    Jun 16, 2023 at 4:06

1 Answer 1


I was able to achieve the functionality I desired by simply using the scrollIntoView API documented here to scroll the selected slide into view after my slider adjusted its position.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.