Embla-carousel: VOTE: Opinion wanted before release of v.3!

[davidcetinkaya]

Question: Should Embla Carousel be responsible for toggling classnames out of the box or should this be up to the user to implement?

WIth Embla v.3 this is easily achieved like so:

const embla = EmblaCarousel(emblaNode, { loop:false })

const selectedClass = 'is-selected'
const draggableClass = 'is-draggable'
const draggingClass = 'is-dragging'

function applyDraggableClasses() {
  emblaNode.classList.add(draggableClass)
  embla.on('pointerDown', () => emblaNode.classList.add(draggingClass))
  embla.on('pointerUp', () => emblaNode.classList.remove(draggingClass))
}

function applySelectedClasses() {
  const slidesInView = embla.slidesInView(true)
  const slidesNotInView = embla.slidesNotInView(true)
  slidesNotInView.forEach(i => slides[i].classList.remove(selectedClass))
  slidesInView.forEach(i => slides[i].classList.add(selectedClass))
}

applyDraggableClasses()
embla.on('select', applySelectedClasses)
embla.on('pointerUp', applySelectedClasses)
embla.on('init', applySelectedClasses)

Basically, this suggestion is about deprecating the following options:

• draggableClass
• draggingClass
• selectedClass

Voting closed! Embla v.3 will still support all these options.

👍 = Keep these options

👎 = Remove these options

I'm going to throw out random pings to get this started. I hope you don't mind.

@gunnarx2, @xiel, @olushchik, @nikrowell, @yocmen, @LaksCastro, @bitttttten, @mrksmts, @jakubreron, @iamkevingreen, @niubsta, @michaelrambeau, @omarkhatibco, @readeral, @allen-garvey, @ontrigger.

[omarkhatibco]

@davidcetinkaya I would like to keep the classNames since I using it every time to style my slider.

I know I can easily implement it but it's overhead to do the same code every time you need to use the slider.

[davidcetinkaya]

Thank you very much for sharing your opinion @omarkhatibco 👍. This is why I wanted to ask this before doing something 🙂. If you have any colleagues/friends using Embla, please consider asking them to vote.

Cheers!
David

[ontrigger]

I thought the whole point of the carousel was to be very simple and customizable, hence having to manually write the the css and html for the basic setup. Having the styling be applied by the carousel itself rather than the user kind of defeats that purpose. As this functionality does not affect the behavior of the carousel itself and is there for mostly styling purposes, I think it should be removed.

[davidcetinkaya]

Thanks a lot for your thoughts @ontrigger 👍. While I personally agree that this should be up to the user with regards to Emblas purpose to be a bare bones carousel lib, I don't think it's always crystal clear where to draw the line. This is why I felt I shouldn't just decide this on my own without listening to opinions from Embla users, like your opinion 🙂.

[nikrowell]

I'd vote for keeping at least the selected class as I see that being the most useful for styling. Draggable and dragging classes are nice, but on non-touch devices, I'd typically include dots or prev / next navigation and don't need the drag feedback. I know there are other uses for those classes, but they seem secondary to me - just sharing my use case 😀

Upvoted to keep selectedClass but potentially leave draggable and dragging to the user.

[davidcetinkaya]

Hello Nik (@nikrowell),

Thanks a bunch for sharing your use case. And of course, as you suggest the dragging classes aren’t necessarily tied to the selected class. Didn’t think about that 🙂. Keeping one and removing the other is an option too 👍🏻.

[gerhard-lechner]

Personally I'm not making use of these pre-defined classes as my use cases are rather straight forward. So for me it would be fine to not have them out of the box.

However, I think it's kind of a pain to remove features that existed before as it makes updating cumbersome for everybody relying on these classes. So I'd suggest keeping them for the sake of compatibility.

Are there any other breaking changes planned for v.3?

[davidcetinkaya]

Hello Gerhard (@niubsta),

Thank you for sharing your opinion ⭐. I agree, it can be cumbersome to do so yes. But I think we should all expect some breaking changes when major version releases happen. Otherwise we're dooming software to be what it was in earlier stages and preventing progression. This could be anything from reducing the bundle size to changing unfortunate naming of API methods or similar. Now when it comes to this specific case regarding the class name toggling, it seems like keeping these options is winning.

The answer to your question:
Yes, there are some breaking changes and I'm working on the migration guide right now. I will share it when it's finished, and don't think the migration will be cumbersome. This is because the vast majority of the changes made are new features.

[davidcetinkaya]

Thank you all for voting! Embla will still support the class name toggling in v.3 with one addition: The possibility to opt-out by passing empty strings as classnames for all these options.

Stay tuned for Embla Carousel version 3!

Hit the watch button to get notified about the release 📣.

[davidcetinkaya]

Hello Gerhard (@niubsta) and all others,

Here's the migration guide (in progress!). The documentation may take some time to update so bare with me. Please let me know if you want to help out. Feel free to open pull requests to update the documentation.

Best,
David

[gerhard-lechner]

Awesome @davidcetinkaya , really appreciate the effort! Thank you!